How fast should your website be in 2023?
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 2023.
Top 10 Web Performance Metrics
|
 |
METRIC |
TARGET |
HOW TO MEASURE* |
|
1 |
Largest Contentful Paint |
2.5 s |
RUM, Lab |
|
2 |
Server response time |
300 ms |
RUM, Lab |
|
3 |
Total Page Weight |
2.5 MB |
Lab |
|
4 |
Total Blocking Time |
200 ms |
Lab |
|
5 |
Cumulative Layout Shift |
0.1 |
RUM, Lab |
|
6 |
Interaction to Next Paint |
200 ms |
RUM |
|
7 |
Total Number of Requests |
75 |
Lab |
|
8 |
Number of Third-party Requests |
40 |
Lab |
|
9 |
Speed Index |
3.4 s |
Lab |
|
10 |
First Contentful Paint |
1.8 s |
RUM, Lab |
|
Bonus       |
Lighthouse Performance Score |
95 |
Lab |
Â
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'll get more and more details into your performance optimisation work.
1. Largest Contentful Paint
The Largest Contentful Paint (LCP) is the most important 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 ambitious yet realistic 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 2.5 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 2.5 MB is based on two data points. Firstly, the HTTP Archive states that the median desktop webpage is 2393.8 KB, while the median for mobile webpages is about 10% lighter with 2095.4 KB (May 2023). Secondly, Googleâs Lighthouse begins to warn about "enormous" page weight at 5 MB. So, targeting something around the median and in safe distance from Lighthouseâs warnings 2.5 MB is a good target.
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; at 30 % of the Lighthouse Performance score, it is the metric with the single largest effect on the performance score. 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. 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 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 was a new addition last year, and the metric that gives insights to how the user experiences the interactions with the webpage. In March of 2024 the INP will replace the FID (First Interaction Delay) in Googleâs Core Web Vitals and will thus become part of the ranking algorithm.
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.
7. 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 72 requests on mobile (May 2023). 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.
8. 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 2022 Web Almanac, 45% 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:
We recommend that you use a performance monitoring service that regularly visits your website to monitor the number of third-party requests.
9. 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.
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%)
- TBT â Total Blocking Time (30%)
- CLS â Cumulative Layout Shift (25%)
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 2023 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.