Kevin Farrugia

Adding a CrUX Vis shortcut to Chrome's address bar

Tue, 15 Apr 2025 11:00:00 GMT

CrUX Vis is a (experimental¹) tool that allows you to visualize and analyze the Chrome User Experience Report (CrUX) data. The CrUX dataset provides insights from real users, including loading performance, responsiveness, and visual stability.

The preceding image is taken from CrUX Vis and shows the Core Web Vitals of https://web.dev.

Accessing the CrUX Vis report is straightforward as you are only required to input the URL (origin or page). However, if you are as lazy as me you can speed this up slightly by adding a Chrome search shortcut. This was my preferred method for accessing the CrUX Dashboard and I wanted to replicate this behavior for CrUX Vis.²

To create a custom Search Engine in Chrome, you need to navigate to chrome://settings/search and select Manage search engines and site search.

Find the section titled Site Search and click on the Add button. In the dialog, insert the following details:

Search engine: CrUX Vis
Shortcut: cruxvis (or any other unique keyword)
URL with %s in place of query: https://cruxvis.withgoogle.com/#/?view=cwvsummary&url=https%3A%2F%2F%s&identifier=origin&device=ALL&periodStart=0&periodEnd=-1&display=p75s

You can now navigate to a CrUX Vis report directly from Chrome’s address bar. Typing cruxvis and pressing tab in the address bar will allow you to input the URL of the origin or page you want to query and Chrome will navigate to the CrUX Vis report for that URL.

Note that the URL should not include the protocol as https is inferred through the URL we used when creating the custom search.

Thank you for reading and I hope you’ll find this useful.

¹ CrUX Vis is expected to replace the CrUX Dashboard in the coming months. If you have any feedback on CrUX Vis, let the CrUX team know using the CrUX Vis survey or the CrUX discussion group.

² This post is heavily inspired by Rick Viscomi’s CrUX Dash shortcut. ❤️

Improving Largest Contentful Paint on slower devices

Sat, 09 Mar 2024 17:00:00 GMT

Looking at our real user metrics, we noticed that our histogram followed a bimodal distribution. A multimodal distribution has more than one mode (a.k.a. peak) and a bimodal distribution has two. Segmenting the data into two groups and optimizing each one separately allowed us to improve our website’s Largest Contentful Paint for most of our users.

The histogram above is taken from January and the two modes are highlighted in red. After careful examination of the data available, we used SpeedCurve to segment our data by device memory. The API has some minor limitations due to privacy, but it allowed us to correlate performance with the user’s device. We could also see that almost all of our users are evenly split between 8 GB and 4 GB devices, with very small numbers for 2 GB and 1 GB devices.

Unsurprisingly, devices with more RAM—and most likely better CPUs—perform better. What was more surprising was the huge difference in loading performance between these user segments.

As illustrated in the preceding chart, in January, users with 4 GB devices had a loading experience that was almost 2 seconds slower when compared to 8 GB devices. The performance continued to degrade even further on 2 GB and 1 GB devices.

We identified several issues that were contributing to the slow loading performance users were experiencing on low-end devices. I will be writing about these in more detail in a future blog post, but in a nutshell, the majority of issues were CSS-related.

For example, on interaction with one button, we would add touch-action: none to the tag. Surprisingly, this affected all DOM elements (6,700 elements in the screenshot above), causing style recalculations—that while negligible on a high-end device—were blocking the main thread for more than 200 milliseconds on low-end phones.

Over two months, we improved LCP on 4 GB devices to 3.4 seconds, reducing the gap with 8 GB devices.

The preceding chart shows that LCP on 8 GB devices improved from 2.88 seconds to 2.30 seconds (a 580-millisecond improvement), while performance on 4 GB devices improved from 4.50 seconds to 3.42 seconds (a 1,080-millisecond improvement).

Conclusion

It is useful to recognize if your data consists of two or more distinct groups of users. If your histogram has two modes, understanding and recognizing why you have two groups can be a powerful tool for improving your website’s performance.

In this example, the two groups contained users with different hardware specifications. In other examples, groups may arise from different geographical locations, user behavior, or maybe one group is irrelevant to you. In any case, understanding the differences between these groups of users helps you improve the user experience for all of them.

Thank you for reading. Feedback is always welcome.

Notes

The website is a single-page app built in React. It is dependent on JavaScript for almost anything, including rendering critical content and—in most cases—the LCP element. Fixing that is a story for another day.
All charts included in this post show data from the home page on mobile devices.
The data is sampled and was collected using SpeedCurve. Visualizations are my own.
An export of the data is available on Google Sheets.

Learn Performance course on web.dev

Wed, 01 Nov 2023 12:00:00 GMT

Together with Jeremy Wagner, I am proud to have co-authored the web.dev Learn Performance course.

The course covers introductory web performance topics, including resource hints and image performance, before diving into more advanced topics, such as JavaScript scheduling, prefetching and prerendering, and web workers.

Thank you to Rachel Andrew and Barry Pollard for their invaluable reviews. Also, a shout-out to the entire web performance community for their continuous feedback and help. 🙏

The course is in its early phases. If you have discovered any bugs or would like to provide feedback or content suggestions, you are welcome.

Setting up a Private WebPageTest instance

Mon, 26 Jun 2023 12:00:00 GMT

This document explains the steps which were taken to set up a private WPT instance on an Ubuntu 22.04 Server.

Virtual Machine

The recommended approach is to set up WPT on a virtual machine rather than your machine. This could be an EC2 machine or a virtual machine. In this tutorial, I am using virt-manager on an Ubuntu host.

When setting up virt-manager, it is recommended to enable File System passthrough.

Enable Shared Memory
Setup a File System passthrough using virtiofs
After installation is complete configure it to automatically mount the shared drive:

$ sudo nano /etc/fstab

Add the following line:

QEMU /mnt virtiofs rw,_netdev 0 0

You may also need to enable IP forwarding on your host machine if it is disabled

sudo sysctl -w net.ipv4.ip_forward=1
sudo systemctl restart libvirtd

WPT Server

The first step is to set up a WebPageTest server. The WebPageTest server hosts the PHP files which are used to show the user the WPT interface as well as run PHP scripts.

webpagetest has the following branches:

master - used on www, not for commercial use (recommended for personal use)
release - rebased from master (might be outdated)
apache - uses the Apache license. Can be used for commercial purposes

To install the WebPageTest server, you can use the install script provided by webpagetest. The below script is taken from wptserver-install but uses the master branch

#!/bin/bash

#**************************************************************************************************
# Configure Defaults
#**************************************************************************************************
set -eu
: ${WPT_BRANCH:='master'}

# Prompt for the configuration options
echo "WebPageTest automatic server install."

# Pre-prompt for the sudo authorization so it doesn't prompt later
sudo date

cd ~
until sudo apt-get update
do
    sleep 1
done
until sudo DEBIAN_FRONTEND=noninteractive apt-get -yq -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" dist-upgrade
do
    sleep 1
done
until sudo apt-get install -y git screen nginx beanstalkd zip unzip curl \
    php-fpm php-apcu php-sqlite3 php-curl php-gd php-zip php-mbstring php-xml php-redis \
    imagemagick ffmpeg libjpeg-turbo-progs libimage-exiftool-perl \
    software-properties-common psmisc
do
    sleep 1
done
sudo chown -R $USER:$USER /var/www
cd /var/www
until git clone --depth 1 --branch=$WPT_BRANCH https://github.com/WPO-Foundation/webpagetest.git
do
    sleep 1
done
until git clone https://github.com/WPO-Foundation/wptserver-install.git
do
    sleep 1
done

# Configure the OS and software
cat wptserver-install/configs/sysctl.conf | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
mkdir -p /var/www/webpagetest/www/tmp
cat wptserver-install/configs/fstab | sudo tee -a /etc/fstab
sudo mount -a
cat wptserver-install/configs/security/limits.conf | sudo tee -a /etc/security/limits.conf
cat wptserver-install/configs/default/beanstalkd | sudo tee /etc/default/beanstalkd
sudo service beanstalkd restart

#php
PHPVER=$(find /etc/php/8.* /etc/php/7.* -maxdepth 0 -type d | head -n 1 | tr -d -c 0-9\.)
cat wptserver-install/configs/php/php.ini | sudo tee /etc/php/$PHPVER/fpm/php.ini
cat wptserver-install/configs/php/pool.www.conf | sed "s/%USER%/$USER/" | sudo tee /etc/php/$PHPVER/fpm/pool.d/www.conf
sudo service php$PHPVER-fpm restart

#nginx
cat wptserver-install/configs/nginx/fastcgi.conf | sudo tee /etc/nginx/fastcgi.conf
cat wptserver-install/configs/nginx/fastcgi_params | sudo tee /etc/nginx/fastcgi_params
cat wptserver-install/configs/nginx/nginx.conf | sed "s/%USER%/$USER/" | sudo tee /etc/nginx/nginx.conf
cat wptserver-install/configs/nginx/sites.default | sudo tee /etc/nginx/sites-available/default
sudo service nginx restart

# WebPageTest Settings
LOCATIONKEY=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1)
SERVERKEY=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1)
SERVERSECRET=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1)
APIKEY=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1)
cat wptserver-install/webpagetest/settings.ini | sed "s/%LOCATIONKEY%/$LOCATIONKEY/" | tee /var/www/webpagetest/www/settings/settings.ini
cat wptserver-install/webpagetest/keys.ini | sed "s/%SERVERSECRET%/$SERVERSECRET/" | sed "s/%SERVERKEY%/$SERVERKEY/" | sed "s/%APIKEY%/$APIKEY/" | tee /var/www/webpagetest/www/settings/keys.ini
cat wptserver-install/webpagetest/locations.ini | tee /var/www/webpagetest/www/settings/locations.ini
cp /var/www/webpagetest/www/settings/connectivity.ini.sample /var/www/webpagetest/www/settings/connectivity.ini

# Crontab to tickle the WebPageTest cron jobs every 5 minutes
CRON_ENTRY="*/5 * * * * curl --silent http://127.0.0.1/work/getwork.php"
( crontab -l | grep -v -F "$CRON_ENTRY" ; echo "$CRON_ENTRY" ) | crontab -

clear
echo 'Setup is complete. System reboot is recommended.'
echo 'The locations need to be configured manually in /var/www/webpagetest/www/settings/locations.ini'
echo 'The settings can be tweaked in /var/www/webpagetest/www/settings/settings.ini'
printf "\n"
echo "The location key to use when configuring agents is: $LOCATIONKEY"
echo "An API key to use for automated testing is: $APIKEY"

After installation is successful, you are prompted to reboot.

After rebooting, navigating to the IP address of the virtual machine should show you the WebPageTest interface. Navigating to /install will show you a checklist of dependencies and prerequisites which were configured during the installation.

I also recommend setting display_errors = on in php.ini to see any PHP errors in the browser.

WPT Agent

The WPT Agent is the location from where the tests are run. You may have multiple agents for a single WebPageTest server. This may be useful if you want to test from multiple locations. In this tutorial, you are going to set up a single location with Chrome and Firefox on the same virtual machine as the wptserver. If the WPT agent is hosted on a different machine, you just need to update the configurations.

You can run the following script which sets up the configurations before calling the wptagent-install script. The WPT_KEY must be taken from the WPT server, /var/www/webpagetest/www/settings/settings.ini.

#! /bin/bash

WPT_SERVER="127.0.0.1" \
WPT_LOCATION="localhost" \
WPT_KEY="{WPT_KEY}" \
DISABLE_IPV6=y \
WPT_BRAVE='n' \
WPT_EPIPHANY='n' \
WPT_EDGE='n' \
bash <(curl -s https://raw.githubusercontent.com/WPO-Foundation/wptagent-install/master/debian.sh)

After the agent has finished installing, you will be prompted to reboot.

After rebooting, the OS will execute the script ~/agent.sh. This script initiates the WPT agent. If you do not use HTTPS on 127.0.0.1, you may need to update the agent.sh script to remove https as per below.

python3 wptagent.py -vvvv --server "http://127.0.0.1/work/" --location localhost --key {WPT_KEY} --exit 60 --alive /tmp/wptagent

You can confirm that the agent is running by accessing the nginx logs:

$ tail -f /var/logs/nginx/access.log

127.0.0.1 - - [02/Mar/2023:12:16:26 +0000] "GET /work/getwork.php?f=json&shards=1&reboot=1&servers=1&testinfo=1&location=localhost&pc=webpagetest-192.168.122.253&key={WPT_KEY}&version=230215.171357&dns=127.0.0.53&freedisk=6.641&upminutes=26 HTTP/1.1" 200 5 "-" "wptagent"
127.0.0.1 - - [02/Mar/2023:12:16:31 +0000] "GET /work/getwork.php?f=json&shards=1&reboot=1&servers=1&testinfo=1&location=localhost&pc=webpagetest-192.168.122.253&key={WPT_KEY}&version=230215.171357&dns=127.0.0.53&freedisk=6.641&upminutes=26 HTTP/1.1" 200 5 "-" "wptagent"
127.0.0.1 - - [02/Mar/2023:12:16:36 +0000] "GET /work/getwork.php?f=json&shards=1&reboot=1&servers=1&testinfo=1&location=localhost&pc=webpagetest-192.168.122.253&key={WPT_KEY}&version=230215.171357&dns=127.0.0.53&freedisk=6.641&upminutes=26 HTTP/1.1" 200 5 "-" "wptagent"

This access log shows that the WPT Agent is pinging the WPT Server. If there isn’t any traffic you may want to check if the --server URL in the wptagent.py script is correct. If it returns a 500, try opening the URL in the browser and see if it shows any PHP errors.

Locations

Finally, you need to configure the WPT Server to accept traffic from the WPT Agent you have just configured. This is done in /var/www/webpagetest/www/settings/locations.ini. For the above agent configurations, you can copy-paste the following:

[locations]
1=Local
default=Local

[Local]
1=localhost
label=Ubuntu 22.04
group=Virtual Machines

[localhost]
browser=Chrome,Firefox
label="Ubuntu 22.04"

Now that everything is set up, you should be able to confirm that the installation is correct by navigating to /install. Your agent should show up at the end of the checklist.

Limits

Before using your new WPT instance, you might want to revisit the test limits, which default to a maximum of 50 monthly tests. These are configured in /www/settings/settings.ini.

rate_limit_anon_monthly=0
rate_limit_anon=0

You can also set limits on the Web UI or API through the /www/settings/keys.ini file.

Automatic updates

Personally, I recommend disabling automatic updates by commenting out the following line in /www/settings/settings.ini:

gitUpdate=1

Simple Configurations

To create simple configuration presets which show up on the home page, you need to create a /www/settings/profiles.ini file. This file will include a list of presets, including their connection, device, and location.

[MotoG4]
label="MotoG4  4G Ubuntu 22.04"
description="Ubuntu 22.04, Simulated MotoG4, 4G Connection, 9 Mbps, 170ms RTT"
location="localhost:Chrome;MotoG4.4G"
runs=3
video=1
timeline=1
fvonly=1
lighthouseTrace=1

In the configuration above, I am creating a configuration named MotoG4 which uses the localhost location with the Chrome browser and emulated MotoG4 with a 4G connection. The label and description affect how the configuration appears on the page, while the runs, video, timeline, fvonly, and lighthouseTrace set some default values.

In the screenshot above, you can see three simple configurations—iPhoneX, MotoG4, and Desktop—that were added to profiles.ini.

Happy testing!

First Important Paint - Developing a custom metric

Sat, 10 Jun 2023 12:00:00 GMT

Updated: Monday Nov 27 2023 | This article is also available in Japanese.

In May 2020, Google proposed a set of user-centric metrics that serve to describe a website’s performance. These are known as the Core Web Vitals (CWV) and include:

Largest Contentful Paint (LCP): The time it takes to paint the largest element in the viewport.
First Input Delay (FID): The delay in responding to the first user input. Soon to be replaced with Interaction to Next Paint (INP).
Cumulative Layout Shift (CLS): A measure of how much the page content shifts.

The CWVs aim to simplify the many performance metrics available and allow you to prioritize the metrics that matter the most. This abstraction has worked very well. In the years following the CWV announcement, website owners and service providers have invested in web performance, improving the user experience for users all across the web.

As shown in the chart above extracted from cwvtech.report, the number of websites passing the CWV thresholds has increased from 22% to 40%.

The role of custom metrics

Custom metrics allow you to extend the set of measures already available in the browser with your own measures that might describe your website’s user experience better than the default metrics. For example, LCP assumes that the largest element is also the most important one. This may be true for some websites but not for others.

In the filmstrip above, the LCP element is the blue gradient background image as highlighted in the frame with the red border. While arguably, the most important element is the page title “Lorem” which is rendered in the next frame. This might be an exaggerated example, but the same problem exists if the important element is a grid or table, or if the background is a element with a poster image.

Element Timing API

Similarly to LCP, the Element Timing API allows you to measure the time a DOM element is rendered on the page. However, unlike LCP, Element Timing allows the developer to choose which element (or elements) to measure. Element Timing is configured by adding the elementtiming attribute to an element.

One limitation of Element Timing is that it is only supported in Chromium-based browsers. Additionally, it is only supported on a limited subset of elements.

User Timing API

The User Timing API is an API that allows you to set marks and measures at specific points in time. For example, this could be once an element is painted onto the page or once an important task has been executed.

// record the time before the task
performance.mark('doSomething:start');
await doSomething();

// record the time after the task has completed
performance.mark('doSomething:end');

// measure the difference between :start and :end
performance.measure('doSomething', 'doSomething:start', 'doSomething:end');

Real user metrics and lab tests

When developing a custom metric, the first question to ask is whether you want to measure this metric from real users on real devices or if it will only be collected from lab tests. Both types of measures can provide you with value, albeit slightly differently.

Real user metrics (RUM) give you a full spectrum of the user experience. Instead of a single score, you will have a range of values that reflect the different users and experiences. For example, users at the 90th percentile may have a terrible experience while the median user has a good one. Understanding the different factors that influence your metrics—for example, geographical location, browser, or device—will allow you to better optimize your website for your users. On the downside, implementing a RUM solution may be expensive or complex.

The screenshot above is taken from SpeedCurve and shows a distribution of different user experiences.

Lab tests run in a controlled environment. You might be able to configure several parameters, such as connection speed, device, and location from where the tests would run. The test result will be a report detailing the different metrics collected from your page.

Lab tests are highly effective at debugging issues. Running lab tests at regular intervals allows you to compare your page’s performance over time and identify regression. My favorite tool for running lab tests is the amazing WebPageTest.

Properties of a good metric

When presenting LCP in 2020, Paul Irish described a list of 8 properties that a good metric should observe—there is also a slight variation documented in the Chromium source code:

Representative: Correlates with user experience and business value.
Interpretable: The metric and its value are easy to understand.
Accurate: How closely the metric measures what it is expected to measure.
Simple: The method it is computed is not complex.
Orthogonal: It should not be measuring something that is already being measured by other metrics.
Stable: There shouldn’t be a lot of variance between runs.
Elastic: A small change in the input results in a small change in the metric.
Correlates: The metric should correlate well with other metrics and between lab/field tests.

Observer Effect

Another important property of a good metric is that it does not influence the test itself. In science, the Observer effect is described as the disturbance of a test by the act of observation. If measuring a custom metric measurably slows down the page, then the metric is not a good one.

First Important Paint

First Important Paint (FIP) is a custom metric that was developed to measure the time it takes to paint the first annotated HTML element onto the page.

The need for this metric arose because the LCP element did not always correspond to the user experience. Additionally, pages were composed of different components—often built by developers on different teams. By annotating the element—instead of the page—the developers creating the component do not need to know on which page the component is being used as it would automatically be treated as an FIP candidate.

(It also comes with a three-letter acronym so you know it’s legit 😛)

Is FIP a good metric?

First Important Paint can be measured both in the field and in the lab. To determine if FIP is a good metric, I ran some lab tests and collected data from two production websites in unrelated markets.

Representative

To test if FIP is representative, I prepared some lab tests with screenshots from different pages and devices and asked colleagues with no knowledge of the metric to tell me in which frame they would consider the most important element to be painted. We used this data to decide which components should be treated as important and to assess whether LCP was already representing this information.

Interpretable

The First Important Paint is easy to understand and is measured in milliseconds.

Accurate

To measure the accuracy of the custom metric, I ran some lab tests where the FIP element was also the LCP element. This means that FIP should record a similar value as LCP. For text elements, I used the Element Timing API instead of LCP.

The tests were executed for image and text elements using 3 different connection speeds. For native connections, the FIP differed from the LCP by 50ms. For Regular 4G and Regular 3G connections, the difference between FIP and LCP elements increased to 200ms and 1000ms respectively.

While the results may appear underwhelming the measurements were consistent and the difference between FIP and LCP or Element Timing did not vary greatly between one test and another. For example, it would have been more concerning if one test registered an FIP that is 50ms faster than LCP and the successive test registers an FIP that is 50ms slower than LCP.

The reasons for the inaccuracy are various and are limitations in how the metric is computed.

Simple

The code for measuring and computing FIP is simple and can easily be debugged or modified if needed.

Orthogonal

FIP is a custom metric that aims to measure the most important element on the page. In some cases, this might be the same as the largest element, in which case it would overlap with LCP.

Stable

To measure the stability of First Important Paint, I ran lab tests on 3 different connection speeds.

As shown in the chart above, all connections experienced very little variation between one test and another.

Elastic

A metric is elastic if it responds proportionately to a change in the user experience. To test if FIP is elastic, I created a demo to serve as a baseline and a variation of this page that self-hosts and preloads the font files. It is expected that the user experience should improve as the title is rendered earlier—and as a result, FIP should also improve.

One of the earlier iterations of FIP did not record any improvements after this change. This helped me identify a flaw in the metric as FIP was recording the time a text element was added to the DOM but did not consider cases when the web fonts have not yet been downloaded.

After this issue was resolved we can see a small and proportional improvement in FIP that matches the improved user experience.

In the comparison above, the Original test reported an LCP of 1.315s and FIP of 1.470s. The Optimized test—which included the fixes above—reported an LCP of 1.305s and an improved FIP of 1.188s. This coincides with the user experience, where the second test has a much-improved experience.

Correlates

To check if FIP correlates with other metrics, I used the same tests described earlier in Accuracy. I plotted FIP against LCP in a scatter plot and calculated the coefficient of determination. For the two metrics to correlate, they do not need to have the same value, but an increase in LCP should result in a proportional increase in FIP and vice-versa.

For text elements, Regular 4G recorded a strong correlation while Regular 3G did not register an equally strong correlation.

Using real user data available in SpeedCurve we can also check if FIP correlates to business metrics.

The chart above is extracted from SpeedCurve and shows a positive correlation between the page’s bounce rate (blue line) and FIP—as FIP increases so does the bounce rate.

Observer Effect

Finally, we want to confirm that the metric does not influence the performance of the page being tested. We ran some tests that contained the measurement and the same tests that do not use the measurement—but include a similarly sized render-blocking script.

As shown in the chart above, the LCP element did not vary between the two sets of tests. In the future, we may also want to extend this test to include JavaScript long tasks in addition to LCP.

Conclusion

The goal of this document is not to promote FIP, but to initiate an internal process of metric reviews. Understanding the scope of the Core Web Vitals and what makes a good custom metric allows us to be critical of our metrics and improve them.

So, is First Important Paint a good metric? It has its limitations and your mileage may vary, but for us, it currently serves an important purpose. I do hope we can improve it and add new custom metrics that describe other aspects of the user experience too.

Thank you for reading. I’m always eager to learn, so feedback and questions are welcome.

Web Performance Audit

Wed, 07 Jun 2023 12:00:00 GMT

Updated: Wednesday July 12 2023

I was asked to perform a performance audit for an online casino operating in Europe. My client noticed that their website is slower than their competitors and they knew that it was costing them millions in lost revenue. This article is an overview of the process, analysis, and recommendations that went into that audit.

My first step when starting a performance audit is to understand the current situation and set up a baseline. Relying on Lighthouse or lab tests alone might not represent what your users are experiencing so I always recommend looking at real user metrics (RUM). For this client, we installed SpeedCurve. Alternatively, you could use the RUM data already available in CrUX.

We then configured some lab tests on WebPageTest. RUM told me that 88% of users are on a mobile device and 99% are on a 4G connection or better. Therefore we set up the lab tests to run on an emulated iPhone X and a Moto G4—using an LTE and 4G connection respectively. We also ran some tests on desktop devices but our main priority was mobile.

In addition to the home page, we also ran tests against other pages that play a critical role in the user journey. The RUM data for these pages was only available in SpeedCurve as the inner pages did not meet the CrUX eligibility criteria.

Largest Contentful Paint (LCP)

The first thing we noted is that the LCP element on the home page is a placeholder image and not representative of the user experience.

If we run the same test but block the above LCP element the LCP increases from the current 1.5s to 4.5s. The new LCP element is the hero image shown on the home page banner. This is much more representative of the user experience and should be the loading experience we should be optimizing for.

To avoid the placeholder image becoming our LCP element we can reduce the size of the image—for example by using CSS for the background color—or reduce the bits-per-pixel to not pass the 0.05 bpp threshold. If either of these is not possible, then it might be worthwhile to add a custom User Timing—for example First Important Paint.

The new LCP image is the 79th requested element. It is a late-discovered resource—such as a CSS background-image or an element added to the DOM using JavaScript. For this client, while the element is present in the initial document, the src attribute is populated using a JavaScript lazy-loading library. Lazy-loading the LCP element is an anti-pattern and can delay rendering.

Cumulative Layout Shift (CLS)

The main contributor to CLS is a UI issue in the slider which appears on the home page.

As can be seen in the image above, the width of the content of the slider increases as the first slide transitions into view—starting from 0px until it reaches the full viewport width.

To test my hypothesis, we added width: 100% !important to the .slider-slide CSS selector using WebPageTest experiments, forcing the slider’s contents to always take up the full viewport width rather than transition from 0px. This eliminated the layout shift from the home page banner content resulting in an improvement from 1.20 to 0.17.

The second largest contributor to the CLS score is a layout shift of the footer.

Until the game thumbnails load, the footer is shown within the initial viewport before being pushed downwards and outside of the viewport once the game thumbnails have loaded. If the server-rendered HTML does not include the game data, it may be sensible to reserve the space for the game thumbnails or show skeleton placeholders. In this client’s case, the initial HTML already included the games but they were being removed because of a bug in the hydration phase.

Time to First Byte (TTFB)

The lab tests for the home page are showing a TTFB of 352ms, while the lab tests for the game page are showing a TTFB of 661ms. These are both much less than the 2.1s recorded by real users on both CrUX and SpeedCurve.

On further investigation and as visible in the chart above, the TTFB of the second run has a terrible 8.9s TTFB—while the first and third tests have a TTFB of approximately 660ms. After a few more tests we were able to confirm that it was not an anomaly and a high TTFB was recorded almost once every four page views. We loaded the page in the browser a few times to check if this only occurs on WebPageTest but sure enough, we experienced a high TTFB within a few refreshes.

I advised the development team to set up monitoring on the server and include server-timing response headers to allow us to correlate the high TTFB with a server process. Based on the latest update I have received from the development team, the high TTFB was caused by cache invalidation on node-cache and will be re-implemented to use a “stale-while-revalidate” strategy.

Document Object Model (DOM)

The home page has a large number of DOM nodes which can affect load time and interactivity.

document.querySelectorAll('*').length; // 3704

After the page has loaded it has a total of 3,704 DOM nodes. It is possible to reduce the number of DOM nodes by flattening a tree structure.


  
    
      The
        Lorem Ipsum

If we look at the above HTML structure we are creating 5 DOM nodes to display a short string. This can be refactored to only require two elements without changing its appearance:


  The Lorem Ipsum

When deciding which HTML to refactor, you should search for HTML that appears on the page many times. This way any savings will be multiplied by the number of times that the HTML appears on the page.

A good example on this page is the PlayButton element that includes an element. The same HTML is repeated on each game thumbnail—a total of 238 times. This can be refactored to use an external image in an element or a CSS background-image. Applying a long cache lifetime means that the image will not be downloaded more than once while also improving the user experience for repeat visitors.

JavaScript

The page downloads a lot of JavaScript—a large part of which remains unused at page load. Code-splitting is a common technique to delay the loading of non-critical JavaScript.

The website is developed using React so it is possible to implement code-splitting using React.lazy.

The page also downloads a JavaScript file /static/js/svg-0.js which seems to contain embedded SVGs. JavaScript requires more CPU processing to parse than SVG or HTML, so it may be better to avoid embedding SVGs in JavaScript and instead reference the SVG files as external resources. This client was using webpack so it only required a small alteration to change the loader in the webpack config from svg-url-loader or url-loader to file-loader. Jacob Grob has written a detailed article on this topic.

The page also has a single render-blocking script https://cdn.trackjs.com/agent/v3/latest/t.js that is a third-party resource. Third-party blocking requests are risky as your page’s performance is dependent on the third party’s response time. Can this script be deferred using the defer attribute?

Images

The website uses a JavaScript library for image lazy-loading. We can replace this with the browser’s native image lazy-loading which is available in all major browsers. Additionally, all images are being lazy-loaded, including those in the initial viewport. Only use loading="lazy" for images outside the initial viewport. If you are unsure whether an image would appear in the viewport or not, I recommend that you are cautious and do not lazy-load these images. The browser usually does a good job with resource prioritization.

The page has a large number of images in different formats. WebP is supported on all major browsers and should be the preferred option with a fallback for older formats. The page also includes GIF images that are highly inefficient and should not be used.

The page also features a large number of SVG animations. This is causing two issues. The first issue is that each SVG image includes several Base64 images encoded within the SVG. This results in image files that are larger than their JPEG or WebP equivalent. Additionally, these images cannot be compressed since Base64 is not easily compressed.

Secondly, SVG animations do not run on the compositor thread unless the device has a DPR of 1.0 and the SVG is inlined. This page includes all SVG animations using the tag which causes CPU (and GPU) usage to increase significantly.

Inlining the animations would improve performance on some devices—with a DPR of 1.0—however, most users would not benefit from this and embedding all the animations could significantly bloat the HTML. I would recommend limiting the number of animated SVGs on each page and using CSS transforms when possible.

Finally, we can improve the cacheability of the banner images by increasing the max-age to 31536000 (1 year) since each new banner image gets its unique URL and fingerprint. The same could be done for the favicon and android-icon that currently have a max-age of 200.

Fonts

The three font files are served in the modern WOFF2 format and already use font-subsetting to reduce their size. This is great news as the average font file is only around 15KB. However, they are only cached for 200 seconds. The max-age for all three font files can be increased to 31536000—1 year.

Browser Hints

Fetch Priority API

The Fetch Priority API is supported on Chrome and will soon be enabled on Safari. You can add fetchpriority="high" to prioritize critical assets. Consider adding fetchpriority="high" on the first banner image (the LCP element) and the