Skip to content

How fast does your site
really load?

A real Chrome loads your page twice: once on desktop, once on a throttled-4G phone. You get first byte, first paint, largest content and fully loaded in seconds, plus what fixing each one is worth.

Real Chrome, not estimates Desktop + mobile in one run Fix list priced in seconds
How we test mobile — mid-range phone on throttled 4G cold cache — a first-time visitor Lighthouse lab run — instantly repeatable 5 regions — pick one above
Seconds, not scores

Four moments behind “it feels slow”

A single load-time number lies. A page becomes usable in stages — and each stage has its own cause, and its own fix.

First byte (TTFB)

How long the server thinks before it starts answering. Pure backend: hosting, database, server cache, CDN.

good < 0.8 s

First paint (FCP)

The blank screen ends — something appears. Held hostage by render-blocking CSS and scripts in the head.

good < 1.8 s

Largest content (LCP)

The main thing lands — the hero image, on most pages. This is Google’s headline metric, and the one images ruin.

good < 2.5 s

Fully loaded

The spinner stops — every request finished. Where page weight, third-party tags and analytics pixels show up.

aim ≤ 3 s on mobile
The Google question

Same numbers Google grades — measured live

This is a Lighthouse-class lab test: a real browser, a controlled connection, results in seconds — run it, fix something, run it again.

  • The metrics match Google’s. LCP, INP and CLS are the same Core Web Vitals that PageSpeed Insights grades and Search uses as a ranking signal.
  • Lab vs field: PageSpeed Insights also shows CrUX field data — a 28-day average of real visitors. Lab answers “is it fast now?”; field answers “was it fast last month?” Use both.
  • Mobile first: we test a mid-range phone on throttled 4G — not your office fibre. That’s the connection most of your visitors actually have.
  • Cold cache: every run is a first-time visitor — the person your marketing just paid for.

What moves each number

metric · the usual suspect
TTFBHosting, database queries, missing server cache, no CDN
FCPRender-blocking CSS and scripts loaded in the head
LCPThe hero image — oversized, unoptimized, or loaded late
CLSImages without dimensions, late ads and embeds, swapping fonts
INPHeavy JavaScript hogging the main thread when users tap
Fully loadedTotal weight and third-party tags — every pixel and tracker counts
For terminal people

Speed checks from the command line

Every number this page reports has a CLI equivalent. We run them all at once, twice, and translate the output.

Time to first bytecurl -o /dev/null -sw 'ttfb %{time_starttransfer}s\n' https://example.com
The full timing breakdowncurl -o /dev/null -sw 'dns %{time_namelookup} · connect %{time_connect} · ttfb %{time_starttransfer} · total %{time_total}\n' https://example.com
Lighthouse, locallynpx lighthouse https://example.com --view
Lighthouse, as a phonenpx lighthouse https://example.com --form-factor=mobile --screenEmulation.mobile
Weigh the whole pagetime wget -pq --delete-after https://example.com
How big is that hero imagecurl -sI https://example.com/img/hero.jpg | grep -i content-length
FAQ

Common questions

As a working target: content visible under 1.8 s, main content (LCP) under 2.5 s, fully loaded under 3 s — on mobile, not just desktop. Under 2 s fully loaded is genuinely fast; past 5 s, bounce rates climb steeply. But the single number matters less than the stages. A 4-second page that paints at 0.9 s feels faster than a 3-second page that stays blank until 2.8 s.

Three reasons compound. 4G adds latency to every one of your dozens of requests. Its bandwidth moves megabytes far slower than fibre. And a phone CPU takes 3–4× longer to run your JavaScript. That’s why we test a mid-range phone on throttled 4G, not your office Wi-Fi. Heavy pages fall apart on mobile first.

Same family, same metrics. PageSpeed Insights runs a Lighthouse lab test, as we do, and adds CrUX field data: a 28-day average from real Chrome users. The lab run answers “is it fast right now?” and is instantly repeatable after a fix. The field data answers “was it fast for real visitors last month?” The LCP, INP and CLS thresholds you see here are Google’s own.

Networks jitter, servers have busy moments, and third-party tags respond differently every time. A few hundred milliseconds of run-to-run variance is normal. For a stable number, run the test a few times and compare. Always compare like with like: same location, same device, not London-desktop against Singapore-mobile.

Core Web Vitals are a Google ranking signal — one among many, and rarely the difference between page one and page two. The measurable effect is on people: slower pages bounce more and convert less. Fix speed for visitors; whatever ranking benefit follows is a bonus.

Images — they’re half the weight of the average page, and one oversized hero can cost seconds on 4G. Then render-blocking scripts, then server response time. Our fix list saves you the guessing: it’s ranked by estimated seconds saved, so the top item is always the biggest win.

Pick a region in the test bar — London, Cologne, Paris, Toronto or Singapore — and re-run to compare. If you want every location at once, that’s the Website Availability Test, which loads your page from 30+ places in one pass. Free either way, no sign-up.

Free tools are just the start.
Uptimia keeps your sites healthy.

Uptime, SSL, domain expiry, page speed, transactions — monitored from 171+ locations worldwide. Free for 30 days.

30 days free no credit card cancel anytime free plan after trial
100,000+ websites monitored · GDPR-compliant