Discover how to harness the potential of ChatGPT for advanced keyword research in SEO with our comprehensive guide.
Most people are aware that website performance matters. However, what does it actually mean when we talk about making a website “fast”?
Website performance is all relative. For example, a user with a powerful device and fast network may find a website fast to load, while another user who has a lower-end device and a slower network may find it very slow to load.
Alternatively, two sites could finish loading up in identical time, however one may appear to load more quickly if its content loads progressive instead of having to wait until the end before anything is displayed. Another site could appear to load rapidly but respond slowly when the user interacts with it.
It’s clear, then, that performance should be referred to in objective terms with criteria that can be measured quantitatively i.e. metrics.
Traditionally, load event measures web performance. But, even though this is a well-defined moment within a webpage’s lifecycle, it doesn’t correspond, necessarily, with anything that users care about.
A server may respond with an immediate-loading minimal page but then fetching content may be deferred so nothing will be displayed on the web page for several seconds after the initial load event is fired. This page may technically have a rapid loading time, however that doesn’t relate to the user experience of loading up the page.
With this in mind, some key questions need to be asked to ensure metrics can be used that have relevance to users. These include:
Generally, performance metrics can be measured either in the field (when real users load and interact with a page) or in a lab (when tools are used to simulate the page load within a controlled and consistent environment). Using both of these options is the best ideal if you want to ensure optimal website performance.
When developed a new feature, testing performance within a lab is vital. Before releasing features in production, it isn’t possible to measure how they perform with real users so lab testing is the only way of preventing performance regressions.
Although lab testing is a suitable proxy, it doesn’t always reflect how every user will experience your website in practice. A website’s performance may vary wildly depending on the capabilities of the user’s device and the network conditions they’re operating under, as well as how or whether the user interacts with the page. Lab tests cannot capture these differences.
Several kinds of metric are relevant to the way in which users perceive website performance. These include:
Perceived load speeds– the speed at which a page loads and renders its visual elements onto the screen.
Runtime responsiveness – once the page has loaded, how rapidly it responds to the user’s interactions.
Load responsiveness – how rapidly the page loads and executes required code to allow components to rapidly respond to the user’s interactions.
Visual stability – whether the page elements shift in a way that the user doesn’t expect.
Smoothness – whether the animations and transitions render consistently and flow fluidly between states.
All of these metrics need to be borne in mind when determining a page’s performance characteristics.
Some key metrics for measurement include:
FCP (First Contentful Paint) – this measures the length of time between the page starting to load and any element of the content being rendered on the screen.
LCP (Largest Contentful Paint) – this measures the length of time between the page beginning to load and the biggest image element or text block being rendered on the screen.
FID (First Input Delay) – this measures the length of time between the user first interacting with the site and the time that the browser responds to the interaction.
TTI (Time to Interactive) – this measures the length of time between the page beginning to load to the time that it is visually rendered and its initial scripts have loaded so it can respond reliably and quickly to the user’s input.
TBT (Total Blocking Time) – this measures the length of time between TTI and FCP where the main thread has been blocked for sufficient time to stop input responsiveness.
CLS (Cumulative Layout Shift) – this measures a cumulative score of every unexpected layout shift to occur between the time the page begins to load and the time its lifecycle state switches to hidden.
There are other metrics that can be measured too, including runtime smoothness and responsiveness, which could help to determine a website’s performance.
Although the metrics above are ideal to give you an overall understanding of a website’s performance characteristics and to compare performance against that of competitors, having custom metrics for your own website is the best course of action. These will ensure that the complete performance picture can be captured. Some lower-level APIs are useful for implementing your own metrics customised for your website’s specific needs including:
Without properly measuring user performance metrics, it’s impossible to really know how well your website is performing and how effective it is when your visitors try to interact with it. By taking into account the various performance metrics mentioned here - and by taking the time to measure the ones that are most critical to your website’s performance - you can be sure that you can pinpoint any potential issues as early as possible.
This enables you to put steps in place to rectify the problems before they have a seriously negative impact on the performance of your webpages. By optimising your performance metrics as much as possible, you can be confident that your visitors will all enjoy the best possible user experience.