Three measures and their limits#
Google measures how the site is experienced with three measures. The assessment is made at the 75th percentile, that is, how it goes for three out of four visits [1]. Google uses the measures in its page experience systems [2].
✓ Good ! Needs improvement ✕ Poor
Show as a table
| Measure | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP | at most 2.5 s | 2.5-4 s | over 4 s |
| INP | at most 200 ms | 200-500 ms | over 500 ms |
| CLS | at most 0.1 | 0.1-0.25 | over 0.25 |
Where the figures come from#
The figures come from the Chrome UX Report: anonymous data from real Chrome users who share statistics. Only sites with enough visits are included, and Google does not say where the threshold is [3]. If data is missing for your site, we say so. We never guess a figure.
Our requirement: under 0.7 seconds#
Google's limits are a minimum level. On sites we build and run, we require more: the main content must show within 0.7 seconds on a computer and the server must answer within 0.2 seconds. On mobile, where Google assumes a slower 4G network, the page must pass Google's limit for good with a margin. The requirements apply both to the new design and to the copy of the customer's current site [4] [5].
| Measure | Google's limit for good | Our requirement for our sites |
|---|---|---|
| The server's response (TTFB) | at most 0.8 s (recommendation) | at most 0.2 s |
| The first content shows (FCP) | at most 1.8 s (recommendation) | at most 0.8 s |
| The main content shows (LCP), computer | at most 2.5 s | at most 0.7 s |
| The main content shows (LCP), mobile on 4G | at most 2.5 s | at most 2.5 s, target 1.0 s |
| Response when you click (INP) | at most 0.2 s | at most 0.1 s |
| Layout shift (CLS) | at most 0.1 | at most 0.1, target 0.02 |
| Lighthouse performance | 90+ counts as good | 90-100 |
| Lighthouse SEO and accessibility | no requirement from Google | 95-100 |
How we test the speed#
- Every site we build or preview is tested with Google's PageSpeed Insights, on mobile and computer, at least once a week and after every change. A site that misses the requirement shows at once in our operations, with what needs to be fixed [6].
- Every site we analyse, the customer's current one too, is tested the same way. The salesperson sees the figure with its source, for example how many seconds it takes before the main content shows on mobile, compared with Google's limit.
- If the site has enough visitors, we also show Google's measurement of real visitors (the Chrome UX Report), which is what Google itself uses [3].
This is what we do so that the site is fast#
- The page is sent finished from the server, with the most important styling directly in the page, so that nothing has to wait for scripts.
- The main image is fetched first and in the right size for the screen; images further down load when the visitor scrolls there.
- The fonts are on our own server, and a fallback style with the same measurements keeps the text from jumping when the font arrives.
- The next page is fetched in advance when the visitor points at a link, so that it opens at once.
- Background work on the server always comes after the visitors' pages.
- We show Google's measurement in the analysis when it exists, with date and source.
Images#
How images should be named, described and loaded, and what the myths about EXIF and GPS are, is in Images and file names.
How fast is your website?
The free analysis measures the speed on mobile and computer.
0 SEK · no sign-up · an answer in about a minute
Sources on this page
- Web Vitals: metrics and thresholds web.dev (Google) · Official documentation
- Core Web Vitals and Google Search Google Search Central · Official documentation
- Chrome UX Report: methodology Chrome for Developers · Official documentation
- Largest Contentful Paint (LCP) web.dev (Google) · Official documentation
- Time to First Byte (TTFB) web.dev (Google) · Official documentation
- About PageSpeed Insights Google for Developers · Official documentation