Enterspeed logo
Login
Enterspeed Blog

How fast should your website be in 2022?

Thumbnail for blog post: How fast should your website be in 2022?

We're often asked how fast a website should be.

Awesome question, we think. And one we’re happy to answer.

But beware… The answer is a smidge complicated. Let's throw a few metrics at you, though. You can use them as a guideline when you evaluate a website. As part of the package we'll also provide a bit of knowledge you can put into actual use.

Before we get into the concrete numbers, we want you to keep in mind that performance should be seen in relation to the business. As a rule of thumb, a faster website means better business. Don’t just optimise the performance for the sake of better performance, optimise your website’s performance to create a better business.

The easiest way to gauge if a performance optimisation is worth the effort, is to compare your website to your competitors’. And if you want to stand out on performance, you should set a goal to be 20% faster than your fastest competitor.

But let’s get to it and check out the 10 most important website performance metrics for 2022.

Top 10 Web Performance Metrics

METRICTARGETHOW TO MEASURE*
1Largest Contentful Paint2.5 sRUM, Lab
2Server response time300 msRUM, Lab
3Total Page Weight3 MBLab
4Total Blocking Time200 msLab
5Cumulative Layout Shift0.1RUM, Lab
6Total Number of Requests75Lab
7Number of Third-party Requests40Lab
8Speed Index3.4 sLab
9First Input Delay200 msRUM
10First Contentful Paint1.8 sRUM, Lab
BonusLighthouse Performance Score95Lab

RUM = Real User Monitoring (aka. field data)
Lab = Laboratory testing and not real users (aka. Synthetic testing)
Bold = recommended measuring technic

 

We’ve organised the list, so you’ll learn the most from the first 2 or 3 points and then you will get more and more details into your performance optimisation work.

1. Largest Contentful Paint

The Largest Contentful Paint (LCP)  metric for how fast your website loads. If you only track one metric, this is the one.

The recommended target for LCP is 2.5 seconds for the 75th percentile.

About LCP

The LCP is part of Google’s Core Web Vitals and is a user-centric performance metric. User-centric performance metrics aim to quantify the user’s experience of the website’s performance. The LCP measures the time from when the user requests the page until the most important visual element (text or media) is presented to the user.

Understanding how you measure the LCP is crucial when you interpret the result. The recommended target of 2.5 seconds should be what the majority of your users experience. We recommend that you follow Google’s definition and define the 2.5-second goal for the 75th percentile.

The recommended strategy for measuring the LCP is to monitor and collect the performance measurements from your actual users using a Real User Monitoring (RUM) tool.

We need to note that even though LCP has been a performance metric for a few years, it is currently only available in Chrome-based browsers.

2. Server response time

A low server response time is a prerequisite for all other metrics. If the content is not delivered to the users in a timely fashion, then you don’t have a chance.

The recommended target for server response time is 300 milliseconds for the 75th percentile.

About Server response time

The server response time – also known as the time to the first byte (TTFB) – is perhaps the oldest metric in the field of web performance. It’s simply a measurement of how fast the page is served to the user, but many factors come into play when measuring and optimising server response times.

The most important factor for server response time is usually the web application serving the pages, often the CMS, but the geographical location of the users can also affect server response time quite considerably.

Our recommended target of 300 ms is an aggressive target, but since the server response time is the foundation that everything else depends upon, this is not where you want to be lax. Over the years, the recommended server response time metric has changed. In 2019 the definition of a “fast” website used by the 2019 HTTP Archive Web Almanac was 200 ms. Up till early 2022 Google’s target for labelling the server response time as “good” was 500 ms, and currently the threshold is 800 ms. Due to the many factors affecting server response time and real-world web performance in general, we believe that a 300 ms is an  rule of thumb target across devices and geography.

The recommended strategy for measuring the server response time is to monitor and collect the performance measurements from your actual users using a Real User Monitoring (RUM) tool. Having RUM data from the field is especially important for server response time, due to many factors that affect this for the specific user.

3. Total Page Weight

This is a metric that simply measures how much data the user needs to download when viewing your page. The total page weight is a very good indicator of the performance of a web page.

The recommended maximum for total page weight is 3 MB.

About Total Page Weight

There is a strong correlation between the amount of data a user must download and how fast the page loads, but the actual impact on performance depends on the user’s type of connection and the capabilities of the user’s device. This is a metric where you could choose to have different goals for mobile and desktop users.

The recommendation of one goal of a maximum of 3 MB is based on two data points. Firstly, the HTTP Archive states that the median desktop webpage is 2317.8 KB, while the median for mobile webpages is about 10% lighter with 2022.5 KB (June 2022). Secondly, Google’s Lighthouse’s maximum limit is 5 MB.

The simplest way to evaluate the total page weight is to use the developer tools in the Chrome browser.

Chrome Developer Tools show how much data is transferred. But we recommend that you use a performance monitoring service that regularly visits your website to continuously monitor the page weight.

4. Total Blocking Time

The Total Blocking Time (TBT) is a key metric for evaluating when your webpage becomes reliable responsive for user input. A high TBT is a sign of too much JavaScript.

The recommended target for the Total Blocking Time is 200 milliseconds.

About TBT

This is a somewhat technical metric, but Google’s 2020 updates to its performance metrics make this a metric we can’t ignore. The Total Blocking Time provides a finer-grained perspective on the effect of JavaScript on a page.

As an oversimplification, a description would be that the more JavaScript you have, the longer the user must wait for the page to become usable. With the Total Blocking Time, we have a metric showing how long the user must wait.

Our recommendation of aiming for 200 ms is based on Google’s Lighthouse definition of a “fast” TBT.

This metric can only be measured with tools powered by Google’s Lighthouse. We recommend that you use a performance monitoring service that regularly visits your website to continuously monitor the Total Blocking Time.

5. Cumulative Layout Shift

The Cumulative Layout Shift (CLS) measures how quickly a webpage becomes visually stable. An unstable page will see the various elements move around as the page loads.

The recommended target for Cumulative Layout Shift is 0.1 for the 75th percentile.

About CLS

Who hasn’t tried to tap or click on a menu item or button, and then have it moved on the screen just before you hit it? The CLS is a relatively new metric – also part of Google’s Core Web Vital – that measure how often the user’s experience is affected by the elements moving around on the screen.

The goal is to have a CLS score of 0 (i.e., all elements stay where they are at all times), but our recommendation follows Google’s with 0.1 or below as ‘good’. You should not worry about how the score is calculated for now, but you can see a visualisation of CLS on your website using this CLS Gif creator.

As with all user-centric performance metrics, the recommended strategy for measuring the CLS is to monitor and collect the performance measurements from your actual users using a Real User Monitoring (RUM) tool.

6. Total Number of Requests

This is a metric that simply measures how many requests a user needs to perform when viewing your page. The total number of requests is a good indicator of the performance of a web page – especially for discovering the performance regressions that the accumulated daily work infers.

The recommended target for the total number of requests is 75.

About Number of Requests

To be perfectly candid the number of requests doesn’t necessarily determine the performance of a webpage, but we have found a high correlation between them. Even though it is a rough proxy metric, we like it because it is both simple to evaluate and easy to communicate. Everyone understands that the more work you ask the browser to do, the slower the experience will be.

The recommended maximum is derived from years of experience combined with the HTTP Archive’s statistic that shows that the median of web pages has 70 requests on mobile (June 2022). With 75, you are in the middle of the pack, and below 60 is good, but when the number gets above 95 requests, it becomes critical.

The simplest way to evaluate the total number of requests is to use the developer tools in the Chrome browser.

But we recommend that you use a performance monitoring service that regularly visits your website to monitor the number of requests.

7. Number of Third-party Requests

Another request metric is the number of third-party requests. Third-party requests come from the various scripts used for analytics and marketing tools. Third-party scripts are typically easy to install, but restraint must be shown, because honestly – they are like bad calories and can weigh down your website.

The recommended maximum of third-party requests: 40 in total (but never more than 50%).

About Number of Third-party Requests

Third-party scripts – such as analytics, marketing tools and chats – are a double-edged sword; on one side, they provide an easy way to include functionality but on the other, you give up control with page weight and the number of requests. We often see third-party tools cause more than 10 new requests and the inclusion of large legacy frontend libraries.

According to the 2021 Web Almanac, 46% of all requests are third-party. The trend is towards more third-party scripts. This makes sense, as it’s usually advised against re-inventing the wheel. We recommend that you keep your requests from third parties to less than 50% of – and see if you can avoid more than 40 in total.

You can use Google’s Page Speed Insights to quickly evaluate your own website. It runs a check for third-party code:

to use as a guideline when you evaluate your website. As part of the packagend also a bit of knowledge that you can put into actual use.

We recommend that you use a performance monitoring service that regularly visits your website to monitor the number of third-party requests.

8. Speed Index

The Speed Index is a measurement of how fast the web page is displayed on the screen.

The recommended target for the Speed Index is 3.4 seconds for the 75th percentile.

About Speed Index

The Speed Index is calculated from analysing a recording of the loading of the website. On a historical note, this metric was one of the first that quantified the visual completeness of web site. You can view it as the precursor of the LCP. Our recommendation of 3.4 seconds is aligned with Google's 0-3.4 second "good performance" bucket.

This metric can only be measured with lab testing performance tools such a Google Page Speed Insights or WebPageTest.org. But we recommend that you use a performance monitoring service that regularly visits your website to monitor the Speed Index.

9. Interaction to Next Paint

Interaction to Next Paint (INP) is a metric for measuring responsiveness of the webpage, and in this narrow context the INP metric tells how fast the webpage reacts to user input.

The recommended target for the Interaction to Next Paint is 200 ms for the 75th percentile.

About INP

As websites become more and more interactive and app-like, the responsiveness of each user interaction becomes more and more important for the overall user experience. The INP is a new, and still experimental, metric that give insights to how the user experiences the interactions with the webpage.

The thinking behind this metric is very classic human-computer interaction science. Users get frustrated on technology when their input is not immediately met with a response from the user interface. Imaging how you react, when clicking a button doesn’t provide immediately feedback. It doesn’t take many milliseconds before you lose your patience and believe the machine isn’t working.

With thicker frontends, the amount of JavaScript increases and the INP metric can be a tell-tale sign that your frontend has become too heavy with JavaScript and content, and if above 200 ms it is negatively affecting the user experience.

Our recommended target is based on Google’s good threshold.

As the Interaction to Next Paint requires a user to actually do something, this metric can only be meaningfully measured with Real User Monitoring. The INP is still new, and support is not yet widespread in the various RUM tools out there. Thus, the ordinary recommendation to monitor and collect the performance measurements from your actual users using a Real User Monitoring (RUM) tool, is not valid as of yet. Instead we recommend the Chrome User Experience Report data, where you can see the FID data from your own site.

10. First Contentful Paint

The First Contentful Paint metric answers the question “when is the first content displayed?”

The recommended target for the First Contentful Paint is 1.8 second for the 75th percentile.

About First Contentful Paint

It’s a critical point in the loading process when a page goes from “nothing” to “something”. When there is more than 1 second between the user performing an action to the website providing feedback, the sense of flow is lost.

The recommended strategy for measuring the FCP is to monitor and collect the performance measurements from your actual users using a Real User Monitoring (RUM) tool. For now, FCP is only available in Chrome-based browsers, but the metric is under development to also be reported from Safari browsers (macOS and iOS).

Bonus: Lighthouse Performance Score

One of the most popular metrics of website performance is the Lighthouse Performance Score. LPS scores your website performance from 0-100 when you use Google’s PageSpeed Insights.

The recommended target for the Lighthouse Performance Score is 95.

About Lighthouse Performance Score

The Lighthouse Performance Score is compounded of the following metrics (weight in parentheses):

  • FCP – First Contentful Paint (10%)
  • SI – Speed Index (10%)
  • LCP – Largest Contentful Paint (25%)
  • TTI – Time to Interactive (10%)
  • TBT – Total Blocking Time (30%)
  • CLS – Cumulative Layout Shift (15%)

Each metric scores from 0-100 on the “Lighthouse scoring distribution”. A score of 50 is derived from the 25th percentile as collected by the HTTP Archive.

We recommend a score of 95 because the Lighthouse scoring distribution is a log-normal distribution. This means that you’ll reach a point of diminishing returns and according to the documentation, “taking a score from 99 to 100 needs about the same amount of metric improvement that would take a 90 to 94”.

Source: https://www.desmos.com/calculator/o98tbeyt1t

We recommend that you use a performance monitoring service that regularly runs a Lighthouse test on your website to monitor the Lighthouse Performance Score.

Conclusion

Web performance metrics are a complex topic, and one size rarely fits all. This top 10 is our current 2022 answer that you can use as a pretty good guide. Reach out to us at Enterspeed to learn more about how your website performs and what it means to your business.