Page load speed: what is good and how to measure it

By Romulo Felizola · Updated · 4 min read · Leer en español

According to Google, a page loads well if its main content appears in under 2.5 seconds (LCP), it responds to taps in under 200 milliseconds (INP) and it doesn't move while loading (CLS under 0.1). It also helps if the server answers in 0.8 seconds or less (TTFB). You measure it with PageSpeed Insights and the Core Web Vitals report in Search Console; here are the numbers from six of our own sites.

In this guide
  1. The numbers that matter
  2. How to measure it
  3. What we measured on our sites (November 10, 2026)
  4. What to do if you don't make it
  5. Frequently asked questions

The numbers that matter

  • LCP (Largest Contentful Paint)

    What it measures
    How long until the biggest element on screen appears (a photo or a headline)
    Good according to Google
    Under 2.5 seconds

  • INP (Interaction to Next Paint)

    What it measures
    How long the page takes to react when you tap or click
    Good according to Google
    Under 200 milliseconds

  • CLS (Cumulative Layout Shift)

    What it measures
    How much the content moves while loading (the jumps that make you tap the wrong thing)
    Good according to Google
    Under 0.1

  • TTFB (time to first byte)

    What it measures
    How long until the first byte arrives from the server. Not a Core Web Vital
    Good according to Google
    0.8 seconds or less (0.8 to 1.8 needs improvement; over 1.8 is poor)

Google Search Central (Core Web Vitals) and web.dev/ttfb, read on November 10, 2026. Google says this “aligns with what our core ranking systems seek to reward”.

How to measure it

  • [PageSpeed Insights](https://pagespeed.web.dev/): paste your address. At the top it shows data from real users (if there are enough) and below a lab test. The two can disagree.
  • Search Console, Core Web Vitals report: it uses data from real people and groups your pages by status. It is the measurement that matters.
  • Server time with curl: measure TTFB in your terminal (see TTFB).

A distinction worth keeping straight: lab is a simulated, repeatable test on one machine; field is data from real people with their phones and networks. To decide, field rules; the lab helps find what to fix.

What we measured on our sites (November 10, 2026)

  • seoclave.com (home)

    LCP mobile
    704 ms
    LCP desktop
    272 ms
    CLS
    0
    Total weight (mobile)
    1,254 KB

  • seoclave.com/precios

    LCP mobile
    292 ms
    LCP desktop
    260 ms
    CLS
    0
    Total weight (mobile)
    1,291 KB

  • jsbrandlab.com (home)

    LCP mobile
    320 ms
    LCP desktop
    396 ms
    CLS
    0
    Total weight (mobile)
    804 KB

  • jsbrandlab.com/hosting/vps-colombia

    LCP mobile
    180 ms
    LCP desktop
    156 ms
    CLS
    0
    Total weight (mobile)
    615 KB

  • orinocorp.com

    LCP mobile
    232 ms
    LCP desktop
    296 ms
    CLS
    0
    Total weight (mobile)
    3,261 KB

  • tramitesve.com

    LCP mobile
    332 ms
    LCP desktop
    324 ms
    CLS
    0
    Total weight (mobile)
    2,001 KB

Chromium with a 360 px mobile screen and a 1280 px desktop one, measured from the server itself (a Hostinger KVM 2 VPS), with NO network or CPU throttling. It is the part that depends on the page and the server; on a real phone on 4G the LCP will be higher, which is why you also look at field data. Uncompressed weights, in KB of 1,024 bytes.

Two things the measurement taught us. One: the server is not the bottleneck; with a VPS of 2 cores and 8 GB for about twenty sites, the LCP comes out far below 2.5 seconds. Two: the heaviest thing on our fast pages isn't ours. On jsbrandlab.com, the JavaScript of a 17 KB page is almost all Google Analytics' script: about 541 KB uncompressed. Measuring costs weight, and it is worth knowing.

What to do if you don't make it

In this order, highest usual impact first:

  1. 1Images: they weigh less in modern formats (WebP or AVIF) and at the size they are actually shown. It is the number one cause of a bad LCP.
  2. 2JavaScript: remove what you don't use (plugins, widgets, tags). Every script competes with your content.
  3. 3Caching: serve the page ready-made instead of generating it on every visit.
  4. 4The server: if time to first byte is over 0.8 seconds even with the above done, look at your plan or host.
  5. 5Distance: a server far from your visitors adds network time; a CDN or a nearer server reduces it.

Our free site audit looks at titles, descriptions, headings and images on up to 10 pages: run it here. If the server turns out to be the problem, read how hosting affects SEO and what a hosting needs for SEO.

Frequently asked questions

What page load speed is good?

According to Google: main content in under 2.5 seconds (LCP), response to taps in under 200 milliseconds (INP) and CLS under 0.1. For the server, a TTFB of 0.8 seconds or less.

Does page speed affect SEO?

Yes, through the Core Web Vitals: Google says they align with what its core ranking systems seek to reward. It is not the only thing or the most important: content that answers what people search for still rules.

Why does PageSpeed Insights give one number and Search Console another?

Because PageSpeed also shows a simulated lab test, and Search Console uses only data from real users. If they disagree, trust the real data.

Is my hosting the reason my site is slow?

Sometimes. Check by measuring time to first byte; if it is good, the problem is in the site (images, scripts), not the server.

Is it normal that Google Analytics weighs so much?

Yes: on our pages its script is 99% of the JavaScript. Load it only if you'll use it and review now and then which tags are still active.

Keep reading