Improving Your SEO Web Vitals

Please note that the SEO Web Vitals feature is exclusive to Matomo On-Premise and is not available in Matomo Cloud.

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.

Previous FAQ: Where do I find the SEO Web Vitals report?