What are SEO Web Vitals?

Matomo enables you to track metrics for SEO Web Vitals. These are things such as your website’s page speed and loading performance, which can help with search engine optimisation. Search engines don’t want to send people to pages that appear jittery and take forever to load and as it reflects on their reputation. Therefore these core web vitals are being used more and more by search engines such as Google to rank websites and ensure a great page experience for users arriving on links from their results.

As a website owner or marketer, monitoring these SEO Web Vitals and optimising your page experience where possible will help improve your position within the search engine results pages. Monitoring your SEO Web Vitals enables you to understand how your site performs in the wild, i.e. with actual users. Once you know how good or bad things are, you can monitor these metrics over time to improve them. This will improve your overall performance scores and, ultimately, your rankings.

Another often missed opportunity is the fact that these metrics are essentially open for anyone to inspect. You can’t hide your website performance; it simply is what it is. Therefore, you can also measure the SEO web vitals of your top competitors to benchmark your site against theirs. This means you can optimise your site to ensure it provides an objectively better experience for your users. With all else being equal, this will enable you to leapfrog your competition in the search results.

What is Required to Measure Your SEO Web Vitals?

There are several prerequisites that you will need if you want to monitor your SEO Web Vitals. The first and most basic is that any page you want to monitor must be fully public, connected to the internet and crawlable by search engines. Typically, this should already be the case if you are aiming to optimise a page for better results in search.

The next less obvious requirement is your page will need to have a valid SSL certificate enabled. The presence of an SSL certificate has also been a search engine ranking factor for a while now, so you should already have SSL enabled across your entire site if you want it to rank well. There are free services like Let’s Encrypt available through most web hosts if you don’t have an SSL certificate and need to set one up, but that is beyond the scope of this guide.

The final prerequisite is that any pages you want to measure must receive at least some regular visitors. This is because the data for your SEO Web Vitals are collected from visits to your website over 28 days. Therefore, you will want somewhat frequent page visits to any pages you’d like to analyse.

For new websites and pages, you may want to use marketing channels other than search to get some initial visits. For example, you could send out some email marketing content, share your link on social media and even run some display advertising for commercial pages.

How to Configure SEO Web Vitals in Matomo

To set up SEO Web Vitals within Matomo, you should start within the relevant reporting area. Within the main navigation menu on the left-hand side of your Matomo instance, click Acquisition to reveal the sub-menu, and then click the SEO Web Vitals menu item.

Acquisition Menu

When you first visit, there is no data, so instead, a link to configure your settings is presented as shown in the screenshot below:

SEO Web Vitals - Initial Screen

The SEO Web Vitals feature within Matomo makes use of the Google PageSpeed Insights API to collect data. If you already have a PageSpeed Insights API key for your site, you can click on the displayed link, which will take you to the settings page where you can enter it. Alternatively, refer to the next section to acquire a free API key from Google.

SEO Web Vitals API Input

How to Get an API Key for SEO Web Vitals from Google

To get your free PageSpeed Insights API Key, you will either need to have an active Google account. Head to the PageSpeed Insights page and click the button to Get a key, as seen in the screenshot below.

Google API Key Screen

If you aren’t logged in, it will prompt you to do so now, and if you don’t have an account then you can click the Create account link to get started. Once logged in, you may be asked to add this key to a project. If you are already using Google Cloud for your site, then select the relevant project. Otherwise, you can click to + Create a new project and give it a name. You can use any name but using the name of your website probably makes sense.

Once you’ve done the above, you’ll be presented with your API key as shown in the screenshot below.

PageSpeed Insights API Key

Click on the copy icon Copy Icon within the API Key box and then reopen the SEO Web Vitals configuration page within your Matomo instance where you should paste it into the API token field and click Save.

How To Set Up SEO Web Vitals for the First Time

After setting up your PageSpeed Insights API Key, you still need to configure which pages you want to track within the SEO Web Vitals Feature. Under the Acquisition section of the main navigation menu, revisit the SEO Web Vitals reporting section, which will now be showing some additional options.

SEO Web Vitals - Configure URLs

Click the link to configure 5 popular URLs to track. By default, Matomo can automatically monitor the top 5 most popular URLs based on their number of visits. However, you can also customise which pages are monitored if there are specific pages that you want to measure. Whichever option you choose, it is always possible to change which URLs you wish to monitor later.

Selecting Which Pages are Monitored for SEO Web Vitals

While Matomo can monitor your top five pages, there are times when you may want to track other pages. For example, if you have a new website without lots of traffic you may want to select specific pages. Or there may be specific pages you want to optimise for faster performance and improved search rankings. Yet another example is if you have both a blog and an ecommerce store on your site, you may want to ensure that you have at least one representative blog post link and one product page.

Using the Matomo website as an example, it might make sense to select the homepage, a single blog post, the pricing page, an FAQ page, and a guide page to monitor. This is a total of five pages and would look a little something like the screenshot below:

SEO Web Vitals - URL Configuration

Ultimately, the goal is to have representative pages for each significant page style on your site. A few examples of page types that you may want to track for your website are:

  • Homepage
  • Blog Page
  • Product Page
  • Pricing Page
  • FAQ Page
  • Archive or Category Page
  • Marketing Landing Page

Once you have identified the various styles of pages on your site, choose one URL for each style and then enter their URLs within the SEO Web Vitals configuration settings. You should still aim to track no more than 5-10 unique URLs because there are limits to the number of API requests you can make within a certain timeframe.

Whether you remain with the default selection or choose your own pages, data for the selected pages will only start to appear up to one day after being added. Once the data arrives it is continuously updated based on a rolling 28-day average.

Changing Which Pages are Monitored for SEO Web Vitals

As your website evolves, you may find that there are new styles of pages on your site that you would like to monitor. Or, you may end up deleting older pages after a redesign. Whatever the reason, you can easily update which pages are tracked within your Matomo configuration settings.

You can access these from the Matomo settings page, which you can access by clicking on the cog icon Settings Cog Icon at the top right of the page. Once there, expand the Websites or Measurables menu represented by this icon Measurables Icon and click on Manage.

Websites - Manage Menu Item

Then simply look for the list of URLs to monitor under SEO Web Vital URLs to monitor and update it to reflect your new selection. When you are happy with your choice, click the Save button.

SEO Web Vitals - URL Configuration

It is worth mentioning that if you change the selected pages at a later date, any newly selected pages will only collect data moving forward from the time they are set up. As before, you will typically need to wait up to 24-hours for the first data to arrive for a new URL and up to 28-days for a combined average that can be fairly compared with any unchanged URLs.

How to Analyse Your SEO Web Vitals

Once you have collected some data for your SEO Web Vitals report, it is time to review how your site is performing. To access the report, within the main navigation menu on the left-hand side of your Matomo instance click on the Acquisition tab and then click on the SEO Web Vitals menu item.

Within this section, the report data is presented in table format and summarises the core metrics which make up your SEO Web Vitals:

One thing to consider when analysing the results from this report is that any segments you are using won’t work. It will always show the average of all users over the past 28-days for your site.

Understanding the SEO Web Vital Metrics

Page Speed Score

The Page Speed Score, also known as a Performance Score, provides a high-level overview of the performance of your website’s SEO Web Vitals. This score is calculated from the rest of the metrics within this section and provides a simple indication of whether your pages are considered fast, average or slow. If you only want to look at a single metric to understand your page performance, it should be this one.

Performance Score Grading:

  • Good – Score of 90 or more.
  • Needs Improvement – Score of 50 to 89.
  • Poor – Score of 0 to 49.

First Contentful Paint (FCP) Metric

The First contentful paint (FCP) metric measures the time until the browser can render the first piece of content after a user has navigated to your page. As the FCP moment is the first time that any content is shown to your visitors, it is an important aspect for making a page feel fast or slow and helps reassure your visitors that the page is actually loading.

First Contentful Paint (FCP) Grading:

  • Good – Any time up to 1.8 seconds.
  • Needs Improvement – Any time between 1.8 and 3 seconds.
  • Poor – Any time longer than 3 seconds.

First Input Delay (FID) Metric

The First input delay (FID) metric measures the time it takes between the first time a visitor interacts with your page and the time for the resulting action to occur within the browser. This includes things like clicking on links and form fields, but not simply scrolling through your page. This is important because certain actions can be blocked while your site is still loading which can make your site feel slow and unresponsive to your visitors.

First Input Delay (FID) Grading:

  • Good – Any time under 100ms
  • Needs Improvement – Any time between 100ms – 300ms
  • Poor – Any time over 300ms

Largest Contentful Paint (LCP) Metric

The Largest contentful paint (LCP) metric is related to the loading performance of your page and is defined as the time at which the largest text or image is painted or rendered on the screen. The reason for tracking the largest element is because it is most likely to be the main focus of your page and the reason a visitor is on the page.

Largest Contentful Paint (LCP) Grading:

  • Good – Any time up to 2.5 seconds.
  • Needs Improvement – Any time between 2.5 and 4 seconds.
  • Poor – Any time longer than 4 seconds.

Cumulative Layout Shift (CLS) Metric

The Cumulative layout shift (CLS) metric measures the visual stability of your page while it is loading. Essentially it tracks the movement of elements that are currently visible on your page while loading. To provide an example, have you ever loaded a page with a button on it and just as you were about to click it, something else loads above and pushes the button further down the page? This experience is frustrating for your website visitors and even more so if it means they end up clicking on the wrong thing.

The CLS metric is based on a formula that calculates the size of any objects that move against the distance they move upon refresh. You certainly don’t need to understand the details of the formula to make use of this metric. All you need to know is that the lower this score is, the better. If you are interested in learning more about the specific calculations, this article explains the CLS formula.

Cumulative Layout Shift (CLS) Grading:

  • Good – Score of 0.1 or less.
  • Needs Improvement – Score between 0.1 and 0.25.
  • Poor – Score of 0.25 or more.

Understanding the Colour Grading of your SEO Web Vitals

Within the SEO Web Vitals report, each of the metrics described above is displayed in a different colour depending on how they are currently performing against target benchmarks. The same colour key is used for all of the metrics within the report:

  • Green – The metric is considered Good.
  • Orange – The metric is considered average and Needs Improvement.
  • Red – The metric is considered Poor and it is highly recommended to improve it.

This simple colour system allows you to quickly assess your performance without needing to remember the specific recommended values for each.

Comparing SEO Web Vitals between Desktop and Mobile

Page performance often varies greatly depending on whether a desktop or mobile device is being used. Generally, you can expect slightly slower scores on mobile devices due to slower network connections and often lower-powered devices with mobile-specific CSS to render. To help you understand performance across both contexts, you will receive both a desktop and mobile score for each of the metrics as seen below.

SEO Web Vitals Table

Even though the metrics are likely to be different between devices, you should still be aiming for a Good result (represented by green text) for both desktop and mobile.

If you are only interested in optimising for one type of traffic, it is possible to filter the SEO Web Vitals report. To do this, click the table icon Table Icon at the bottom left of the table to reveal the option to show Desktop Only, Mobile only, or All Strategies to review both.

SEO Web Vitals Device Type Menu

The Two Types of Data Within the SEO Web Vitals Report

The SEO Web Vitals report section contains two types of data: Field Data and Lab Data.

What is Field Data?

Field Data is shown for each page at the top level of the report for a quick overview of your metrics. This data is most reflective of the reality of your web page experience as it is an average based on 28-days of actual visits by real users loading your website.

What is Lab Data?

Lab Data is the second data type and is shown when you click the plus icon Plus Icon to analyse a specific page in more detail. All data shown within the Audit Lab Data section is taken from a simulated visit generated by a Google bot visiting your website and measuring each of the metrics for that specific visit. Due to the fact this is based on a single lab visit from a single device and location, the metrics and scores may vary wildly from the experience of your actual visitors and even between individual tests from the same tool.

How To Use Each Type of Data

Generally speaking, Field Data is a more reliable account of how your website is performing for your visitors. You’ll want to monitor your field data to ensure that your visitors have a great experience when visiting your site. However, Lab Data also allows you to review your metrics on demand and can help you get quicker feedback while optimising your site.

Troubleshooting Missing Data

When analysing the specific rows with your SEO Web Vitals performance chart, you may notice that several of the metrics have no Field data and only show a dash. If you see a dash, it simply means there isn’t enough data for that metric yet. The most common reasons for this are because the page is brand new, it isn’t receiving enough traffic or is not publicly accessible for some reason.

If all of the metrics are missing for a page you should check that the page is publicly available by opening it in a fresh incognito or private browser window to ensure that it loads without relying on cached files or a login. If the page loads as expected then the report probably just needs more time to collect data.

You can still get some initial lab data by hovering your mouse over the row you are interested in and then clicking the eye icon Eye Icon.

SEO Web Vitals - Row Icons

This will load the page in an external PageSpeed Insights testing tool that tracks the same metrics.

Google PageSpeed Insights

Note: When you run a page speed test on the linked tool, the specific results are likely to differ each time as a new test is conducted every time. That is why the blended 28-day field data is a more reliable indicator of what your users are actually experiencing.

How to Analyse Your Page’s SEO Web Vitals Over Time

If you’d like to look at one of your tracked pages in more detail. You can hover your mouse over its row within the table to reveal two icons. Click on the line chart icon Line Chart Icon which will load a row evolution view graph where you can review all of the metrics over time.

SEO Web Vitals Evolution Graph

When it first loads, the row evolution chart will display your Page Speed Score. However, you can drill down into any of the metrics for a page by clicking on the relevant sparkline summary below to refresh the row evolution chart with the newly selected metric. You can also hold the shift key on your keyboard while clicking on another metric if you’d like to compare more than one. This allows you to identify relationships between the metrics such as First Contentful Paint and Last Contentful Display and also compare the differences between the Desktop and Mobile version of any metric.

You may also notice there are several green icons below the row evolution chart. These allow you to export the data Export Icon into another format, share the chart as an image Image Icon, reveal annotations Annotation Icon within the selected time period and select whether each point represents a day, week, month or year Calendar Icon so you can see how the page scores have evolved over different periods of time.

Tracking The Performance of Specific Metrics Over Time

It is also possible to monitor how each of your specific SEO Web Vitals on a page are performing over time through a similar row evolution graph. This can be especially helpful if you’ve made changes to one of the pages and you want to check they are actually improving the situation.

The first step is to expand the page row within the SEO Web Vitals report by clicking on the plus icon Plus Icon to reveal the Audit Lab Data. From here you need to find the specific measurable that you’d like to focus on and hover your mouse on its row to reveal a line chart icon Line Chart Icon. Clicking that icon will load a row evolution graph that is specific to this measurable.

SEO Web Vitals - Metric Details

Within this view you can see the results for the chosen metric broken down by date so that you can review how it has changed over time. All of your measurables display a Score Percentage which summarises your performance and some measurables will also contain an Information score which is the actual tracked data value for the metric. You can see an example of this in the screenshot above where the number of seconds is shown for the largest contentful paint. Each of these metrics will be provided for both Desktop and Mobile as in the main SEO Web Vitals report.

Comparing SEO Web Vitals Metrics

In some cases, you may want to compare more than one of these metrics. To do this, you can hold down the shift key while clicking on the sparkline summary that you’d like to add to the chart. In the example below you can see that while there have been significant shifts in the score for mobile devices, the score for Desktops has remained fairly consistent and even moved in the opposite direction on a few occasions.

Comparing SEO Web Vitals

In this case, it is possible that the variation is simply down to the variance in resources available on the mobile device. To improve your score, you would aim to increase both the lower and upper band scores for this page so the entire range is at a more acceptable level.

Diagnosing SEO Web Vital Changes with Annotations

If you often make use of Matomo’s annotation feature, then you may also notice annotation icons Annotation Icon along the base of the row evolution graph. Where these icons correlate with an increase or decrease in the score for your metric there is a good chance that the annotated changes have impacted your score. For example, if your first contentful paint score improves on a day where an annotation notes that an image optimisation plugin was installed on your site, it is likely that this was a beneficial change for your site.

How to Improve Your SEO Web Vitals

Once you know what your metrics are, you should aim to improve on any that fall into the “Needs Improvement” (orange) or “Poor” (red) range. If you notice several of the metrics for a page are displayed in red when reviewing the SEO Web Vitals report, that is probably a good page to start with. To see what has contributed to your site’s score and where the opportunity for improvement lies, you should click the plus icon Plus Icon to expand the rows with these values and look for low-performance scores within the Audit Lab Data.

Audit Lab Data

The core SEO Web Vitals metrics are shown in bold text and the supporting diagnostics and potential optimisations are shown in a standard font. Any metrics or optimisations with a score less than 100% mean there is room for improvement. You can find some general instructions on how to improve the top-level SEO Web Vitals metrics and some of the common contributing factors. Below this you’ll find a complete list of audit lab optimisations along with descriptions on how they might help improve your scores.

How to Improve Your Page Speed Score

Your Page Speed Score is a weighted average of your other performance metrics so it can’t be directly optimised. Instead, you will need to focus on improving the underlying metrics to improve your overall score. One strategy you might want to consider is selecting your worst-performing diagnostic or metric from the complete list of Audit Lab Data and then beginning your optimisation journey from there. When your other metrics begin to improve, you should also see that reflected in your Page Speed performance score.

How to Improve your FCP Time

There are many factors that can contribute to a slower FCP value. One of the best things you should do to improve this metric is ensure you are on a high quality web host with an appropriate plan for your level of traffic. Beyond that you’ll find some of the most common issues and optimisations you can make to improve your score.

How to Improve Your LCP Time

The largest contentful paint is dependent on the fact that any content is being rendered on-screen at all. Therefore the faster loading time you can achieve for your First Contentful Paint (FCP) the sooner that your largest content will be able to load. This means it may be worthwhile to complete the recommendations for optimising your FCP first if it is not considered fast.

With that said, there are lots of different things that you can do to improve the time of your largest contentful paint. Apart from simply removing large elements that aren’t required on your page, we have highlighted some of the most common optimisations below.

How to Improve your FID Score

Anything that takes your browser 50ms or more to process could be considered a long task. When testing, it isn’t possible to replicate FID so you should optimise against Total Blocking Time instead as larger scores here are likely to impact your FID score. It is worth noting that there is also an element of chance for this score depending on which elements your users interact with. Some examples of things you can do to optimise your FID score are:

How to Improve Your CLS Score

With an almost unlimited number of layouts a page can have, many things can cause your page to experience layout shifts. Most changes that affect your CLS score will require changes to your website’s code, so you may need to work with a developer if this is outside of your skillset. You can find some examples of things that you can do to improve this score in the section below. There is also a useful online tool that you can use to see which elements on your site are causing layout shifts.

Ensure fallback elements are the same size as dynamic elements

Often websites will dynamically load content after the initial HTML has been received. For example, a JavaScript widget pulling content from a third-party website. In cases like this, it can take some time for the full data to download, however, you often know the size of a widget before it loads. Therefore you should set the element container to take up the same amount of space as the dynamically contained content.

As an example, if you are loading a social media widget that you know will be 768 pixels wide and 500 pixels high, you could use something like the following code to ensure that space is reserved until the div element is dynamically updated.

HTML

<div class="SocialMediaWidget"></div>

CSS

.SocialMediaWidget {
    height: 500px;
    width: 768px;
}

If you don’t specify a height and width for your images this will lead to a layout shift when the images do download which will negatively impact your CLS.

Complete List of Audit Lab Optimisations

Avoid an excessive DOM size

The DOM size is the total size of all objects with your HTML page structure. The more elements you have on your page the bigger this will be. You can reduce this by removing unnecessary elements from your page and consolidating containers into the minimum required.

Avoid multiple page redirects

Redirects add to your page load time, so you should aim to avoid them where possible. This is true for both the page itself and also any assets such as JavaScript and CSS files that are linked on your web page. If redirects are unavoidable, you should aim to use links that are only a single hop away as multiple redirects will slow your loading times even further.

Avoid enormous network payloads

Large payloads can delay the browser from progressing to load subsequent parts of your page. The average file request or payload is between 1,700 and 1,900 KiB and assets. Payloads that are over 5,000 KiB will trigger this warning. Try to split large payloads into smaller logical components if possible and remove any that aren’t necessary.

Avoid serving legacy JavaScript to modern browsers

Often people create code to accommodate people with older browsers that don’t support the latest JavaScript features. However, if this code is served to all users without consideration it can add unnecessary loading time to the latest browsers that don’t require it. You should aim to conditionally load legacy code only when it is required.

Avoid document.write()

This repaints the DOM after the page has loaded which can cause jarring layout shifts. It also delays content being displayed at all on slower connections.

Defer offscreen images

This is also known as lazy loading and essentially tells your website to load images only once they would physically be seen on the page i.e. above the fold. This reduces the amount of data required for the initial page load and therefore increases the speed of your initial page load. This also provides benefits for people with bandwidth limits on their internet connections as they only download data when necessary.

Efficiently encode images

It is often possible to compress images for smaller file sizes on the web without noticeably impacting the visual image quality for your users. You can do this during image production, through the use of image optimisation plugins for your content management system (CMS) or even use online tools such as Squoosh to compress them before uploading to your website.

Eliminate render-blocking resources

Your pages JavaScript and CSS files need to be fully loaded and parsed before the page fully begins rendering. While the browser is waiting for this to happen they become “render-blocking resources”. This means the more of these files you have and the larger they are, the more likely it is to slow down your site’s loading times.

Therefore if you link to multiple JavaScript and CSS files on your site, make sure they only load on pages where they will actually be utilised. For example, a custom script and styling for your pricing page tables shouldn’t need to be downloaded for somebody that never visits your pricing page.

Additionally, you may want to periodically check your files for code that is no longer required for one reason or another to reduce the total amount of code that is required to load.

Enable text compression

Text compression uses complex algorithms to reduce the file size of text-only documents such as HTML, JavaScript and CSS files. GZIP is the most common form of text compression, however, Brotli is a new alternative that is also widely supported. Both of these tools are configured on your server and should result in quicker loading times due to the reduced file size of your pages. You can check what method of text compression your site is using, if any, with this text compression testing tool. If you aren’t using either of these tools, you should reach out to your host to enable one of them.

Ensure text remains visible during Webfont load

Custom fonts are a common source of layout shifts. If a user doesn’t have a specific font on their device, they will have to download it before the content can be displayed with it. Depending on how a website has implemented any custom fonts this can lead to text loading with a default font which may be a different size and refreshing once the custom font has been downloaded and in some cases text is prevented from showing at all until the custom font has loaded.

The simplest fix for this is to use a web-safe font as these are likely to already be installed on a visitor’s device. This will avoid the browser having to download anything special which also has the added benefit of reducing the amount of data required by your website. However, fonts are an important design and branding tool so this may not be an option.

If custom fonts are required for your website, there are a couple of steps you can take to help prevent layout shifts on your website. The first is to preload your custom font so that it is downloaded earlier in your page loading sequence. You can do this by adding a <link rel="preload"> tag within the <head></head> section of your site’s HTML. This would look a little something like the following making sure that the href and type values are correct for your custom font file:

<link rel="preload" href="fonts/customfont.woff2" as="font" type="font/woff2" crossorigin>

You can also combine this with the font-display: optional CSS attribute so that font rendering is delayed for up to 100ms while the browser attempts to download your custom font file which will help avoid potential layout shifts.

First contentful paint 3g

This is the length of time for the First Contentful Paint on a simulated 3g mobile device. It will be slower than the FCP but you should aim for it to fall within the same acceptable ranges.

First Meaningful Paint

This metric, also known as FMP, is being phased out as it is not consistent between browsers so you can safely ignore it and refer to your Largest Contentful Paint score instead. You can learn more about what FMP measures here and the associated challenges that led to its depraction.

JavaScript execution time

This is the amount of time it takes to execute the JavaScript on your website. If it is excessively long you may want to consider removing any JavaScript that isn’t essential for the functionality of your site, for example, visual flourishes. If you are using a content management system, there is also a chance that the same scripts are being loaded multiple times. If this is the case, you will want to ensure that any custom code or plugins use the correct methods to call dependencies which can avoid duplication. Alternatively, you can search for options or filters within plugins that allow you to disable commonly used packages where not required.

Minify CSS

This removes unnecessary whitespace in your CSS files which reduces their overall file size so they can load faster. There is an online tool you can use for this here.

Minify JavaScript

This removes unnecessary whitespace in your JavaScript files which reduces their overall file size so they can load faster. In some cases, this can cause problems with your code so make sure you test your site after you make changes. There is an online tool you can use to minify your JavaScript here.

Minimize main-thread work

The main thread describes the core processing a browser undertakes to load a web page, including the parsing and executing all of your HTML/CSS and JavaScript. The main thread processes one thing at a time so when large scripts block the main thread, it means the processing of the rest of your site cannot continue until prior tasks are complete. Therefore, any reduction in work that has to be processed on the main thread will result in faster completion of your page load overall. There are many things that you can do to minimise main-thread work, many of which are described on this page. You can learn some of the most common ways to minimise main thread work here.

Modern image formats

Both AVIF and WebP are newer image file formats that offer better compression and therefore smaller file sizes than traditional jpg or png files. Due to their smaller file sizes, they will typically load faster which will improve your page performance scores. Unfortunately, neither of the new formats are as widely supported by browsers and web applications so you may need to provide fallbacks. You can learn more about file formats for the web here.

Preconnect to required origins

Many websites utilise assets from third-party domains. Each new request adds to your loading time, especially on slower networks, as they require time to resolve the DNS, verify SSL certificates and potentially follow any redirects. When these assets are requested later within your DOM, it can slow things down even further as much of your content has already loaded before this process begins. To avoid this happening, you can preconnect to third party originals with the <link rel="preconnect"> or dns-prefetch tags so that any network negotiations occur earlier within the loading process so when the asset is requested the connection has already been established. This may not be required for domains where you are already preloading assets.

Preload key requests

Some resources may take some time to download but will only be discovered later within your page load. For example, fonts that are loaded by @font-face CSS rules. In these cases, you can set up a <link rel="preload"> tag to ensure that any critical files are loaded as soon as possible to avoid negatively impacting your FCP.

Preload lcp image

If your largest contentful paint (LCP) is an image, you can preload with <link rel="preload"> to ensure it is loaded at the earliest possible moment. If you don’t do this, it is possible that it will be requested later in the process and could slow things down whilst the browser waits for it to download.

Properly size images

Ensure that any photos you upload are appropriately sized for where they will load in. Modern cameras will often capture photos that are many multiples of the average screen resolution. If you upload photos at full resolution it will add unnecessary loading time to your page requests.

Reduce initial server response time (TTFB)

Your Time to First Byte (TTFB), measures how long it takes for your server to return the first data after the initial request is sent. It can be impacted by a variety of things such as the speed of any database requests, any server-side caching that has been implemented and the physical resources available to your website, such as the server’s CPU and memory. Therefore to improve your TTFB you should be taking any opportunity to optimise server-side processing.

Remove duplicate modules in JavaScript bundles

Modern JavaScript is often composed with a collection of dependencies so that common coding patterns don’t need to be written from scratch for every project. While this can speed up the development process, in some cases it can mean that the same modules are called multiple times within a single project due to versioning or file path issues. The best way to avoid this is to audit your custom code as you create it for any signs of duplication. If module duplication is occurring in code that you did not create then you may be able to use a deduplication tool instead.

Remove unused CSS

Often people will use just one or two CSS files for their entire site, especially with popular CMS tools. However, if there are CSS styles that are only relevant for one or two pages, you should only load that CSS on the relevant pages to reduce the amount of code that has to be downloaded for the rest of the site and avoid the downloading of that code by users who do not need it.

Remove unused JavaScript

The same as above. If you have JavaScript files providing functionality only for certain pages, for example on a pricing table, you shouldn’t load these files for every page on your website as it will slow things down unnecessarily.

Speed Index

Your speed index is a score that is calculated from how quickly the visible assets on your page load. You can learn more about the speed index calculation here. There are many things that can contribute to this score so this metric is more useful as a reference point than an indicator of which specific elements you need to focus on improving. With that said some optimisations may have a bigger impact on this score than others.

Time to Interactive (TTI)

This is the amount of time before your page has finished loading and a visitor is able to interact with it. Simply seeing your content isn’t enough if a user can’t also interact with it in a meaningful way, such as being able to click a link etc.

Total Blocking Time

This is the amount of time between the FCP and the TTI. It represents the time where a user can see content on your site but isn’t able to interact with it which leads to a bad user experience.

Unsized Images

Images (and other media) often make up a large part of modern websites. While your media is being downloaded by the browser, it won’t know its size until the data has been received unless you tell it. Therefore it is recommended that you always include height and width tags within your HTML so the browser can allocate the space for the picture on your page before the full data has been downloaded. The HTML code for an image with the correct usage of these tags will look a little something like this:

<img src="http://example.com/logo.jpg" height="200" width="400" />

While the above recommendation works when you know exactly how big an image is, it doesn’t work as well for responsive images. A common design pattern for creating responsive images is using CSS with a width attribute of 100% and a height attribute set to auto without setting inline height and width values. In this case, the browser still needs to download the image data before it can establish its size. One solution is providing an aspect ratio to the browser for the image so it can calculate the amount of space to reserve. Luckily, most modern browsers are able to calculate the aspect ratio automatically if you set some initial image dimensions. Therefore, even when using responsive CSS, ensure that you set the actual height and width of the image in HTML first. The code would look something like this:

HTML

<img src="http://example.com/logo.jpg" height="200" width="400" class="responsive-image"/>

CSS

.responsive-image {
    height: auto;
    width: 100%;
}

In the example code above, the browser calculates the aspect ratio from the image dimensions in the HTML code and the CSS immediately resizes the image to fill the available space. When combined this means the correct amount of space is allocated for the image before its data has finished downloading and there is less chance of visible layout shifts occurring.

Uses efficient cache policy on static assets

Often visitors will return to your site multiple times. If there are files on your site that don’t frequently change, you should set up a caching policy so that they don’t have to re-download any assets they already hold on their computer.

Uses passive listeners to improve scrolling performance

Event listeners are a commonly used JavaScript tool which can be used with touch events and mouse wheel events to create custom scrolling configurations. For this reason, browsers will typically wait until listeners attached to these events have finished executing before they allow scrolling. However, use of these events does not inherently mean that scrolling needs to be delayed so users can end up waiting unnecessarily while irrelevant code is loaded.

Luckily, if you are using listeners on these events in a way that does not require blocking, you can use the passive tag to tell the browser that it shouldn’t have to wait for a specific listener before allowing scrolling. The resulting code will look a little something like the following:

document.addEventListener('touchstart', onTouchStart, {passive: true});

Breaking this code down, the outer part document.addEventListener( ); sets up an event listener, the first attribute touchstart attaches the event listener to the touchstart event, the second attribute onTouchStart is the name of the JavaScript function to execute when the event is triggered, and the third and final attribute {passive: true} indicates that this is a passive event which should not delay user scrolling. You can learn more about passive event listeners here as well as information on browser support.

Use video formats for animated content

Animated GIF files are quite large and often it is possible to present the same content in a video format such as MPEG4 which produces a much smaller file size. You can convert GIFs into MPEGs with free tools such as FFmpeg or Cloud Convert. You could also use newer file formats such as WebM, however, these don’t have wide support, especially on mobile, so you will also have to provide a fallback. Whichever route you take, the smaller you can make the size of your media files, the less impact they will have on your performance scores. \

How to Monitor Changes in Your Scores With Custom Alerts

You should generally make a habit of checking on these scores regularly as websites tend to pick up bloat and slow down your own time. One last trick that can save you hours every year instead of manually checking these reports is configuring Custom Alerts for your SEO Web Vitals. These alerts can be dependent on a specific metric level, for example, your mobile Page Speed score going below 50 which would bring it into the range of Poor scoring that can cause issues for your SEO. This would look a little something like the following:

SEO Web Vitals Alerts

Alternatively, if you don’t want to wait for it to hit a certain problem level before being notified, you could set up an alert that notifies you when your score has decreased by a certain percentage. This can help you to quickly identify problematic changes to your web pages and would look a little something like this:

SEO Web Vitals - Custom Alerts

For more details on configuring alerts in general, you can refer to the Custom Alerts documentation which details how you can set up any number of alerts that get sent to you via email or SMS when certain conditions are met.