SEO Guide to Improve Page Speed and Loading Times

Page speed has long been a ranking factor for Google. Starting with the first announcement in 2010, followed by a further update in 2018, and finally the introduction of Core Web Vitals in 2020, it’s now clear that website loading time is a top priority for search engines. In this article, we will explore what page speed means today, how to measure it, and most importantly, how to improve page speed scores for your website.

Understanding Google’s Core Web Vitals

For a long time, Google itself struggled to measure page speed. What are the right metrics? Field data or lab data? Measuring the entire page or just the top part? There are dozens of metrics that come into play in page speed, and it has been a long road to figure out which of them are truly important to the user.

Ultimately, Google settled on a set of three metrics considered most important for page speed: Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS). Collectively known as Core Web Vitals, these metrics are designed to measure perceived speed rather than actual speed.

Largest Contentful Paint (LCP)

Largest Contentful Paint is the time it takes for the largest element within the viewport to fully load. The benchmarks for this metric are as follows:

• Good: less than 2.5 seconds
• Needs Improvement: 2.5 to 4 seconds
• Poor: more than 4 seconds

As it’s common for the largest element to be an image, optimizing images is the primary contributor to this metric. Additionally, LCP depends on server response times, render-blocking code, and client-side rendering.

First Input Delay (FID)

First Input Delay is the delay between the time an interactive element is painted and the time it becomes functional. For example, a button is painted on the page, you click it, but it’s not yet responsive. The benchmarks for this metric are as follows:

• Good: less than 100 milliseconds
• Needs Improvement: 100 to 300 milliseconds
• Poor: more than 300 milliseconds

FID can be optimized with code splitting and using less JavaScript.

Cumulative Layout Shift (CLS)

Cumulative Layout Shift measures whether page elements shift during loading. For instance, a page seems ready to use, but then a new image appears at the top and the rest of the content is pushed down – this is a layout shift. The benchmarks for this metric are as follows:

• Good: less than 0.1
• Needs Improvement: 0.1 to 0.25
• Poor: more than 0.25

CLS depends on properly set element dimensions and loading resources in a specified sequence, from top to bottom.

Tools to Measure Page Speed

There are many tools provided by Google that offer Core Web Vitals as part of their page check:

• Google Page Speed Insights
• Google Search Console
• Chrome Lighthouse
• GTmetrix

However, some of these tools use lab data instead of field data, while Google ranks your pages exclusively based on field data. Furthermore, most tools can only evaluate one page at a time, which is not a practical approach for optimizing your entire website.

Among Google’s tools, the best one to use is likely Google Search Console. There, you can go to Experience > Core Web Vitals and see the report for all your pages at once. Although the high-level report is provided in bulk, identifying which pages are affected by which issues can be a tedious process.

A better way to measure page speed might be to use WebSite Auditor. There you can go to Site Audit > Website Audit and get a page speed report for your entire website, as well as see all affected pages, all from a single dashboard. Or you can navigate to Site Audit > Pages > Page Speed and see a list of pages with the speed issues affecting them. By clicking on any page, you will also get a list of elements on the page that can be optimized for better performance.

Optimizing Page Speed

Now that you have a list of affected pages, it’s time to work on improving your page speed. Below are some of the most common optimization opportunities and tips on how to leverage them.

Set Image Dimensions

When you omit image dimensions from your code, it can take time for the browser to resize them properly. This means your page content will jump around, negatively impacting your CLS score.

To avoid this, always set the width and height properties for your images, like so:

<img src="pillow.jpg" width="640" Height="360" alt="purple pillow with floral pattern" />

Use Modern Image Formats

Not all image formats are created equal. Our trusted JPEG and PNG formats now have worse compression and quality features compared to AVIF, JPEG 2000, JPEG XR, and WebP.

Among the listed formats, WebP is probably the one to consider first. It supports both lossless and lossy compression, as well as allowing transparency and animation. Additionally, WebP files are generally 25% to 35% lighter than PNG and JPEG of similar quality. And while it was once a common concern that WebP was not supported by some browsers, Safari recently added WebP support in version 14, so total browser support for the format is now over 90%.

Compress Images

Regardless of whether you’re using next-gen image formats or not, compressing your images is still a valid way to reduce overall page size. Again, if your website is built on WordPress, you can batch-compress your images with image optimization plugins like WP Smush. You can also use online compressors if you don’t want to install too many plugins and risk slowing down your site. As a last resort, use graphics editors to compress images before uploading them to your website.

Implement Lazy Loading for Images

Offscreen images are those that appear below the fold, meaning the user wouldn’t see them until they scrolled past the initial screen. And this will be a recurring theme for the rest of the article: loading anything below the fold should be deferred until the elements above the fold are fully loaded. The above-the-fold area is what Google uses to measure your page speed, so that’s where most optimization effort should be focused.

The technique for handling offscreen images is called lazy loading. Basically, images above the fold load first, and offscreen images only load as the user scrolls down the page.

Convert GIFs to Videos

It might seem counterintuitive, but GIFs will often have a larger file size than videos. I don’t know how that came to be, but converting a large GIF into a video will result in file size reduction by up to 500% or even more. So if your page speed report tells you to use video formats for animated content, you should take it seriously.

To convert GIFs to videos, you can use any online converter or download a tool like FFmpeg. Google actually recommends creating two video formats: WebM and mp4. WebM is similar to WebP in that it’s lighter but not yet supported by all browsers. So when you add your video to the page, you should list the WebM version first and then the mp4 version as a fallback.

<video autoplay loop muted playsinline>
<source src="animation.webm" type="video/webm">
<source src="animation.mp4" type="video/mp4">
</video>

Note that the video element also has four additional attributes: autoplay, loop, muted, and playsinline. These attributes make your video behave like a GIF – it starts playing automatically, loops, has no sound, and plays inline.

Remove Unused CSS

Unused CSS can slow down the browser’s rendering tree construction. The fact is that a browser has to go through the entire DOM tree and check which CSS rules apply to each node. Therefore, the more unused CSS there is, the longer a browser will take to calculate styles for each node.

The goal here is to identify pieces of CSS that are unused or non-critical and either remove them entirely or change the order in which they load. Check out this guide on deferring unused CSS.

Minify CSS, JS, and HTML

JS and CSS files can often contain comments, spaces, line breaks, and unnecessary pieces of code. Removing them might make your files up to 50% lighter, although the average minification is much lower. Still, it’s a marginal contribution to your page speed and worth a try.

If you have a small website, you can minify code using online minifiers, like CSS Minifier, JavaScript Minifier, and HTML Compressor. Or, if your website is built on a CMS platform like WordPress, there are certainly plugins that can do the job for you. For a custom website, check out this guide on minifying CSS and this one on minifying JS.

Extract Critical CSS

By default, CSS is a render-blocking resource. Your page won’t render until the browser has fetched and parsed the CSS files, which can take a long time.

To fix this, you can extract only the styles needed for the above-the-fold area of your page and inject them into your HTML document’s head. The rest of your CSS files can then be loaded asynchronously. This will significantly improve your LCP scores and make your pages faster for users.

Optimize Server Response

The most unpleasant thing about server response delays is that there’s a vast selection of reasons that can cause them. For example, it could be slow routing, slow application logic, CPU resource exhaustion, slow database queries, memory exhaustion, slow frameworks, etc.

An easy non-technical fix for these issues is to switch to better hosting, which in many cases means from shared hosting to managed hosting. Managed hosting usually includes CDNs and other content delivery tricks that will positively impact page speed. But if you want to get your hands dirty, here’s a more in-depth guide to troubleshooting an overloaded server.

For those seeking a quick improvement without diving into technical details, upgrading to a high-quality hosting provider can make a significant difference. SiteGround, for example, offers fast and secure hosting tailored for small to medium-sized websites and businesses. Their services include a free CDN, advanced caching, and optimized PHP implementation, all contributing to faster loading times and a more responsive site overall.

Efficiently Handle Third-Party Resources

Third-party resources, such as social sharing buttons and video player embeds, tend to be resource-hungry. Furthermore, every time the browser encounters a piece of JS, it will pause HTML parsing until it has handled it. All of this tends to contribute to a measurable drop in page speed.

If any of your third-party resources are non-essential, meaning they don’t count towards the appearance or functionality of the above-the-fold portion, you should remove them from the critical rendering path. To load third-party resources more efficiently, you can use the async or defer attribute. The async attribute is looser: it allows HTML and JS to be downloaded concurrently, but it will still pause HTML to execute JS. The defer attribute is stricter: it won’t pause HTML to execute JS, which will only be executed at the end.

Use Pre-connect for Connections

Establishing connections, especially secure ones, takes a considerable amount of time. The fact is that it requires DNS lookups, SSL handshakes, secret key exchanges, and a few round-trips to the end server responsible for the user’s request. Therefore, to save this precious time, you can pre-connect your website to the required origins in advance.

To pre-connect your website to a third-party origin, you simply need to add a link tag to your page.

<link rel="preconnect" href="https://example.com">

Identify and Optimize Long-Running JavaScript Tasks

Anytime there’s a block of JavaScript that takes longer than 50 ms to execute, your page might appear unresponsive to the user. To fix this, it’s advisable to identify these long tasks, break them into smaller chunks, and have them load asynchronously. This way, there will be brief windows of responsiveness built into your page loading process. You can use Chrome DevTools to identify excessively long tasks – they are the ones marked with red flags:

Once you identify long tasks on your pages, you can break them into smaller tasks, defer their execution, or even move them off the main thread via a web worker.

Preload Critical Resources

It’s up to browsers to decide which resources to load first. Therefore, they often try to load the most important resources like CSS before scripts and images, for example. Unfortunately, this isn’t always the best way to proceed. By preloading resources, you can change content loading priority in modern browsers, informing them which resources will be needed as part of the code responsible for rendering the above-the-fold content.

With the help of the tag, you can inform the browser that a resource is needed as part of the code responsible for rendering the above-the-fold content, and have it fetched as early as possible. Here’s an example of how the tag can be used.

<link rel="preload" as="script" href="script.js" />
<link rel="preload" as="style" href="style.css" />
<link rel="preload" as="image" href="img.png" />
<link rel="preload" as="video" href="vid.webm" type="video/webm" />
<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin />

Note that the resource will be loaded with the same priority. The difference is that the download will start earlier as the browser knows about the preload ahead of time. For more detailed instructions, consult this guide on preloading critical resources.

Implement Browser Caching

Without browser caching, every time you visit the same page, the entire page is loaded from scratch. With browser caching, some elements of the page are stored in the browser’s memory, so only a portion of the page needs to be loaded from the server. Naturally, the page loads much faster on subsequent visits, and your page speed scores increase.

Typically, the goal is to cache as many page resources as possible for as long as possible, and ensure that updated resources are re-validated for caching. In reality, you can control all these parameters with special HTTP headers that contain caching instructions. A good starting point for learning about HTTP caching is this guide from Google.

Optimize DOM Structure

A DOM tree that is too large with complex styling rules can negatively impact speed, runtime, and memory performance. The best practice is to have a DOM tree with fewer than 1500 nodes in total, a maximum depth of 32 nodes, and no parent node with more than 60 child nodes.

A very good practice is to remove DOM nodes that you no longer need. To do this, consider removing nodes that are not currently displayed from the loaded document and try to create them only after a user scrolls down a page or presses a button.

Eliminate Unnecessary Redirects

Getting rid of all unnecessary redirects is one of the best things you can do for your site’s speed. Every additional redirect slows down page rendering and adds one or more HTTP request-response round-trips.

The best practice is to avoid redirects altogether. However, if you desperately need them, it’s crucial to choose the right type of redirect. It’s best to use a 301 redirect for permanent redirection. But if, for example, you want to redirect users to short-term promotional pages or device-specific URLs, 302 temporary redirects are the better option.

These listed issues are not all of the problems that can affect page speed, but rather the most common ones and those with the greatest potential for improvement. Be sure to tailor your optimization strategies to the issues reflected in your page speed report. Keep in mind that issues present on many pages of your website can often be resolved in bulk by implementing site-wide changes.