Google PageSpeed Insights: How to improve your score

PageSpeed Insights

Webmasters understand the importance of page speed in delivering a good user experience. For publishers on the open Web who monetize with advertising, improving page speed is one of the most direct levers to increase search traffic, reduce bounce rate, and drive revenue lift.

The first step in optimizing page speed is measuring it and identifying where the bottlenecks are. There are a lot of tools for measuring page speed, but Google’s PageSpeed Insights is perhaps the most exhaustive in terms of providing actionable recommendations.

In this guide, we’ll provide an introduction to the PageSpeed Insights tool, how the score impacts search rankings and explain why you shouldn’t be chasing a 100/100 score, and then take a deeper dive into 5 common bottlenecks to page speed, what they mean, and how to fix them.

Introduction to Google PageSpeed Insights

Google PageSpeed Insights helps publishers measure the load time of their webpages on desktop and mobile, identify bottlenecks, and use that information to optimize the page load speed of the site. You can enter any URL and run the test.

Following the test, Google assigns a PageSpeed Score out of 100 for the site you’ve tested, based on several page load performance best practices. You also get a list of recommendations to improve your score, and consequently, the overall page load speed of your site.

This is where it gets a little tricky though. A lot of the recommendations wouldn’t make sense to non-developers. But that’s okay! If you use a CMS like WordPress, it’s possible to implement a lot of these recommendations without any knowledge of coding (more on this later).

Why you shouldn’t chase a 100/100 score

Once your site achieves a reasonably good PageSpeed score, let’s say anything north of 90/100—your users are probably experiencing all the benefits associated with fast page load speed. Trying to achieve a perfect 100/100 score is neither easy nor necessarily useful.

What matters more is how well you’ve executed the PageSpeed recommendations rather than hitting a certain number. Over-optimizing can also mean having to strip down essential design and usability elements that are crucial to delivering a good overall user experience. It is therefore important that webmasters take a broad view of how users experience the site in a real-world setting and not compromise form or function for the sake of speeding up the site.

It’s also important to note that as useful as PageSpeed Insights can be, it is not the final word in page speed optimization. It is what Google thinks matters the most. For instance, a site may have a page load time of under 500ms but still receive a bad score on PageSpeed Insights.

Try testing with other page speed tools like Pingdom, YSlow, and GTMetrix, some of which also test the site’s loading speed from various locations. You’ll notice that the numbers from different tools don’t match precisely, which goes to show how arbitrary these tests can be.

How Google uses PageSpeed Insights

Of course, in addition to providing tools like PageSpeed Insights, Google also runs the world’s largest search engine. So the natural conclusion to draw is that your PageSpeed score might also affect search rankings. And yes—Google does use page speed as a ranking signal.

Since 2018, Google has been using mobile page speed as a ranking factor for search results.  In June 2021, Google updated its search algorithm to include Core Web Vitals as a ranking signal for desktop results. You can read more about the CWV update in our previous blog post.

The bottom line is that PageSpeed Insights scores are more than just a vanity metric. Google really believes their page testing methodology, and consequently, rewards sites that have a good PageSpeed score with better rankings on and more traffic via its search engine.

How to improve PageSpeed score

Eliminate render-blocking resources

What it means: Render blocking resources are static files, such as JS, CSS, HTML, and fonts that are vital to the rendering of the webpage. The visitor’s browser has to download and process these files before rendering the rest of the page, creating a bottleneck.

How to fix: If the webpage doesn’t have a lot of JS or CSS, you can get rid of this warning by inlining them, i.e., incorporating the JS/CSS code into the HTML file. If you use WordPress, you can use a plugin like Autoptimize to do this. Inlining only works for really small sites. For larger sites, you should use the async and defer attributes to make the scripts non-render-blocking. Both of these attributes instruct the browser to download the script in the background, so it doesn’t block the rendering of the webpage. While async scripts will execute as soon as they are finished downloading, defer scripts will respect the document order. Finally, to reduce the render-blocking aspect of custom fonts, load them locally instead of a CDN like Google Fonts.

Optimizing the size and delivery of images

What it means: Page latency added due to unoptimized images can quickly add up. Serving images in the proper size, format, and at the right time can significantly improve both overall page load times and the PageSpeed Score.

How to fix: Obviously, the best time to optimize images is before they are uploaded to the website. This means setting standards for format and maximum resolution that all the site’s users adhere to. Apart from serving images in the proper size, it’s also important to serve next-gen images such as WebP, JPEG 2000, or JPEG XR, and only loading below-the-fold images when they first hit the user’s viewport (this is also known as lazy loading). Most commonly used CMS like WordPress, Drupal, Magento, etc, provide third-party extensions and plugins to covert images to next-gen formats, lazyload them, and bulk optimize them.

Avoid chaining critical requests

What it means: This is linked to the concept of the critical rendering path, which refers to the sequence of steps that the browser takes to convert JS, CSS, and HTML to pixels on the screen. Critical request chains are a series of dependent network requests important for page rendering. The length of chain and download sizes both affect the PageSpeed score.

How to fix: The resource tree presented in the results highlights the size and loading time associated with every single dependent request in the chain. From here, you can identify and target the ones that are contributing the most to page latency by deferring them, marking them async, and shortening the critical path by downloading critical assets as early as possible. You’ll notice that Google does not assign a pass or fail on this test, as it is a resource for optimization.

Keep request count low and transfer sizes small

What it means: The greater the number of requests browsers have to make to load your site, and the greater the size of each request, the longer your site will take to load. Much like chaining critical requests, Google does not assign a pass or fail to rate for this test but provides a tally of the total number of requests generated and associated download sizes.

How to fix: The report categorizes requests under distinct asset types like Script, Image, Font, Stylesheet, Media, Third-party, and more. One quick glance can reveal which category of assets is generating the most requests and has the highest transfer sizes. While there is no standard for the ideal number of requests, Google recommends creating a performance budget. Having a budget gives webmasters a standard to hold themselves accountable to. When you go over budget, you can make a decision about making optimizations or eliminating redundant assets.

Reduce unused JavaScript and CSS

What it means: Shipping unused code is a common problem in web development. Let’s say you need to add a navigation bar to your site from the Bootstrap library, so you add a link to the Bootstrap stylesheet in your HTML. The stylesheet doesn’t just contain the navbar though, it contains all of Bootstrap’s components. All that unused code contributes to page latency.

How to fix: Publishers using WordPress should consider reducing the number of plugins that are adding extraneous JS/CSS code to the web pages. You can use code coverage in Chrome DevTools to identify the URL of problematic scripts or stylesheets. Watch out for theme components or plugins that have a lot of red in code coverage. Also consider minifying your JS, CSS, and HTML code—which is the process of removing syntax and extra space to compress the code to further reduce load time and bandwidth usage. You can use Autoptimize or WP Rocket to automatically minify code in WordPress. Publishers using another CMS or a custom-built website can use a third-party JavaScript Minifier and CSS Minifier to minify their code manually.

Of course, that’s not all

The PageSpeed Insights report is pretty exhaustive. This article only suggests optimizations for the most common issues that contribute to the bulk of page latency. Here are some resources that should help you track and resolve some of the other issues identified by the report:

Leave a Reply

Your email address will not be published. Required fields are marked *