When using Pagespeed Insights, Google gives you very useful suggestions. But unless you have a technical background, it’s not always easy to know how to make these work.
This article gives you actionable tips to help you improve page speed. As an SEO, you can use this to create bite-sized pieces of work for developers.
We've added the estimated impact (how much positive impact does this change have on your page speed) and effort (how long does it take to fix this). Keep in mind that these are general estimates based on our experience, and they may vary from website to website. Use them as a general indication.
Enable text compression
Effort: Low
Impact: High
Text compression is like a zip-file for your website: it reduced the size of HTML, CSS and Javascript by up to 90%. This results in faster download times. Normally it's relatively easy to enable either Gzip or Brotli compression. This needs to be done by a developer with access to server settings, but it's just a few lines of code.
More about text compression.
Leverage browser caching
Effort: Low
Impact: High
Browser caching means assets like images, javascript files, and stylesheets are saved in the visitor's browser cache. This means fewer files need to be downloaded for subsequent page views, making the experience a lot faster. You can normally set the so-called Time to Live (TTL) to 30 days, meaning browsers will save those assets up to 30 days before checking if there's a newer file available. Good candidates for browser caching are images, javascript, CSS, and font files. Setting up browser caching settings needs to be done in the server settings and is quite easy.
More about browser cache.
Properly size images
Effort: Medium
Impact: High
It makes no sense to download a 3000 by 2000 pixels image if you only show it as a thumbnail on the page. And because images are often using up a lot of bytes, this can seriously hurt your page performance.
To avoid this, always try to make the original image about the size of the space it gets on your website. Change the dimensions of your image to the size it is shown on the page. In the above example, you would reduce it to 300 x 200 pixels, save about 90% bandwidth, without losing any image quality.
One challenge here is the variation in screen sizes: a full-size header image on desktop will be much larger than on mobile. This is solved by using responsive images, which lets you select the right image for every screen size.
More about responsive images
Optimize images / Efficiently encode images
Effort: Medium
Impact: High
This suggestion is a bit cryptic. It means you can reduce the quality of images and by doing so, reducing the file size. Normally reducing the image of a JPEG image to about 75% of the original quality is almost invisible. Yet by doing so, the size of that image can be close to only 15% of the original. That's 85% smaller!
You can use image editing tools to reduce the quality and size or use online image management tools like Imgix to handle this. Kraken.io is also a great online tool where you can upload your image and get it in a much smaller filesize.
Preload key requests
Effort: Low
Impact: Medium
Preloading key request refers to setting the priority of files that need to be downloaded by the browser. By loading required assets (like fonts) as soon as possible, the visitor experiences the loading process as much faster. Similarly, DNS-prefetching external connections can also help speed up the loading process. Although the impact on page speed is likely not huge, it's low-hanging fruit: implementing preloading takes just a few lines of code to work.
More about preloading and prefetching.
Defer offscreen images
Effort: Low
Impact: Medium
The more common term is lazy-loading images, which means not loading an image until it needs to be shown in the browser (or right before that). Say you have a large page, with lots of images shown below the fold: not directly visible on the visitor's screen, but only after scrolling. Lazy-loading lets the visitor only download the images that are shown directly, and while scrolling down, more images will be loaded.
Until recently this could be quite challenging for the technical team and required external javascript libraries. With the introduction of the loading attribute, this has become a lot easier. More and more browsers support this.Add the loading="lazy" attribute to images that aren't directly visible when loading the page, and you'll see a big performance improvement.
Avoid serving legacy JavaScript to modern browsers
Effort: Medium
Impact: Medium
Good developers try to make websites accessible to large audiences, including people who use old browsers. They'll use polyfills for this: code that servers as a fallback for old browsers to do things that would otherwise not be possible. Although this is a good idea, it may lead to lots of unnecessary javascript being downloaded for people using modern browsers.
To fix this, make sure the polyfills are only offered for people using old browsers. Or, consider if those are still required, by reviewing how many people visit your site using legacy browsers.
Remove duplicate modules in JavaScript bundles
Effort: Medium
Impact: Medium
Developers often use third-party Javascript libraries. That's great because it means they can benefit from existing code and don't need to reinvent the wheel. Each external module may come with its own dependencies, and that could lead to duplicate modules being loaded. This causes larger files to download, and that translates into a slower page. Removing these duplicate modules fixes the issue, and developer tools like Webpack stats duplicates can help.
Serve images in next-gen formats
Effort: Medium
Impact: Medium
There are various image file types: JPEG, GIF, PNG, SVG, and WEBP are common. How do you decide which one to use? All formats are very different, and which one to use depends on the image. The common ones are:
- JPEG allows for good compression, but cannot have transparency, and you can't use it for animations. Normally used for photos
- PNG allows for lossless compression, which means you don't lose any quality when compressing the file. PNGs also allow transparency. Use PNG for screenshots and graphics. PNG can't be animated.
- GIF is relatively inefficient but allows for animation and transparency. Due to its inefficiency, the only real use case is animated GIFs. Even then, you might want to consider video instead of GIFs, as that's much more efficient.
- SVG is very different from the other formats, as it's more code-based. Icons and simple logos in SVG can be extremely efficient, but SVG is not suited for complex images.
- WEBP is a new format that has great compression, allows for transparency, and can be animated. Not all browsers support it. So even though Google Pagespeed Insights may encourage you to use WEBP, we're a bit more conservative: at this point, its support is insufficient to use WEBP. That may change soon though.
Use video formats for animated content
Effort: Medium
Impact: Medium
GIFs are often used for short anima tions. Although GIF supports that, it's not very efficient. Longer animated GIFs should ideally be loaded as a video instead. This saves bandwidth and makes the page faster.
FFMPEG is a great tool that can convert animated GIFS into a much more efficient MPEG format. WEBM is also a great format that's even more efficient, but currently has limited browser support.
Prioritize visible content
Effort: High
Impact: Medium
Visible content refers to the part of the page that is directly visible without scrolling: the Above the Fold part of the page. Normally the part on top is also in the top part of the HTML source, and will therefore load first. If that's the case, for instance when moving elements around after loading, the above-the-fold part may not load first. As a result, people are looking at a blank screen for longer than needed. To fix this, evaluate which content is above the fold, and make sure that is also loaded first in the source of the page.
Reduce initial server response time (TTFB)
Effort: High
Impact: Medium
This is a tricky one. Most of the suggestions relate to the front-end of the site, but this one refers to the back-end. It takes too long for the server to send the initial response. Your technical team needs to find out why that is. Some things that could help: upgrading to a faster server, optimizing database performance by adding indexes, and using modern backend languages. Talk to your developers to see what they can do. Also, keep in mind that a temporary server hiccup may cause this message. Try again a few minutes later to see if it persists.
Eliminate render-blocking resources
Effort: High
Impact: Medium
We see this suggestion a lot, and it's not always easy to fix. Render-blocking resources are any files that need to be loaded before the page can be properly displayed (rendered), specifically the part of the page that is directly visible (above the fold). Render-blocking resources can either be javascript files or stylesheets.
The best way to solve this problem is by placing any code that is required to display the above-the-fold part of the page inline. That means putting it in the HTML source instead of separate stylesheets or javascript files. As a result, the directly visible part of a page can be rendered quickly, while the remaining resources that are needed to display the rest of the page are still loaded in separate files.
This sounds easy, but it's quite complicated. First, you need to identify which HTML and CSS is needed to display the first part of the page, and will be placed inline. But more importantly, it's difficult to maintain. Any changes to the CSS or javascript need to be checked, to see if it requires inline changes or not. There are some tools to automate this, but it's not easy
Instead, some easier ways to achieve improvements in this area are:
- Preload the render-blocking resources
- Minimize the render-blocking resource
- Remove any redundant CSS or javascript
Minify JavaScript
Effort: Low
Impact: Low
Minifying javascript refers to making the javascript files smaller by removing spaces and making naming more efficient. This helps to make the javascript file smaller, so it takes less time to download it. There are various developer tools available to minimize javascript files as part of the development process, as well as online tools to minify Javascript online. Don't expect a huge improvement in page speed, but it does make a difference and it's quite easy, so why wouldn't you implement it.
Minify HTML
Effort: Low
Impact: Low
This message will often occur if your HTML source code includes inline CSS and Javascript that's not minimized, or if you have a lot of spaces in the HTML. Removing the redundant spaces saves bytes, so makes the page a bit faster.
Minify CSS
Effort: Low
Impact: Low
Minifying stylesheets refers to making the CSS files smaller by removing spaces, making naming more efficient, and sometimes also combining media queries. This helps to make the CSS file smaller, resulting in faster downloads. Similar to minimizing Javascript, developers can set up automatic minimizing of CSS as part of their workflow. The effort is normally small, so we suggest doing this.
Avoid landing page redirects / avoid multiple page redirects
Effort: Low
Impact: Low
Redirects slow down the loading of a page. However, if you see this message, it could also be that you entered the wrong URL in the Pagespeed Insights page. Common examples are entering example.com. which then redirects to https://www.example.com. As long as the latter is used across the web and indexed by Google, just run the Pagespeed check again with the full URL, and this issue will be fixed.
Remove unused JavaScript
Effort: High
Impact: Low
Every line of javascript needs to be downloaded and parsed by the browser, so the fewer javascript, the faster the page will load. If there's javascript on a page that's not used on that page, it might be a good idea to remove that.
There's one challenge to this suggestion. It's often more efficient to have just one javascript file for the site that includes everything, even if not every line is required for this page. That makes life a lot easier for developers (no need to figure out which page requires which piece of javascript). This also leverages browser caching, because that one javascript file only needs to be downloaded once.
Therefore, take this suggestion with a grain of salt. It's useful in the two cases:
- If a piece of javascript is loaded that's not used on any page, remove it
- If a very large piece of javascript is loaded, that's only used on a few specific pages, make sure the javascript is only loaded on those pages
Remove unused CSS
Effort: High
Impact: Low
This is very similar to the item above, but for stylesheets. Any line of CSS that is loaded on a page but not used, is a waste of bytes. Therefore it's a good idea to remove redundant CSS. Yet again, it's often easier for developers to have just one CSS file for all the pages on the site. Creating separate stylesheets for different pages is not sustainable.
This suggestion makes sense if you have a lot of CSS that isn't used on any of the pages: get rid of that. Or, if you have large bits of CSS that are only used on specific pages, see if you can load that CSS just on those pages, making all the other pages a lot smaller.
