Build my site for free

The knowledge bank Speed

Speed: Google's limits and our requirement

The three measures Google uses (Core Web Vitals), the limits for good, our own requirement for every site we build (the main content in under 0.7 seconds) and how we test the speed of every site.

2 min read6 sections6 sources

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].

LCP: how quickly the main content showsGood: at most 2.5 sNeeds improvement: 2.5 s to 4 sPoor: over 4 s2.5 s4 sINP: how quickly the page responds to clicksGood: at most 200 msNeeds improvement: 200 ms to 500 msPoor: over 500 ms200 ms500 msCLS: how much the page jumpsGood: at most 0.1Needs improvement: 0.1 to 0.25Poor: over 0.250.10.25

✓ Good ! Needs improvement ✕ Poor

Show as a table
MeasureGoodNeeds improvementPoor
LCPat most 2.5 s2.5-4 sover 4 s
INPat most 200 ms200-500 msover 500 ms
CLSat most 0.10.1-0.25over 0.25
Source: web.dev (Google). Assessed at the 75th percentile of real visits.

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].

MeasureGoogle's limit for goodOur 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), computerat most 2.5 sat most 0.7 s
The main content shows (LCP), mobile on 4Gat most 2.5 sat most 2.5 s, target 1.0 s
Response when you click (INP)at most 0.2 sat most 0.1 s
Layout shift (CLS)at most 0.1at most 0.1, target 0.02
Lighthouse performance90+ counts as good90-100
Lighthouse SEO and accessibilityno requirement from Google95-100
LCP, INP and CLS are Google's Core Web Vitals. TTFB and FCP are Google's recommendations, not ranking requirements. Our requirements are technical targets we set to give a margin; perfect figures guarantee no position.

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

Next topicTimeline →What happens in the first day, the first weeks and the first months after we have taken over, and when you can expect to see a difference.

Sources on this page

  1. Web Vitals: metrics and thresholds web.dev (Google) · Official documentation
  2. Core Web Vitals and Google Search Google Search Central · Official documentation
  3. Chrome UX Report: methodology Chrome for Developers · Official documentation
  4. Largest Contentful Paint (LCP) web.dev (Google) · Official documentation
  5. Time to First Byte (TTFB) web.dev (Google) · Official documentation
  6. About PageSpeed Insights Google for Developers · Official documentation

Knowledge bank updated 15 October 2026. Found something that is not right? Tell us and we will correct it.