Nitro Speed Test

Nitro Speed Test answers the question every site owner actually cares about: is my site fast for the people visiting it, and if not, exactly what’s slowing it down? It combines two very different kinds of data: Google’s real-world field data (Core Web Vitals from actual Chrome users over the last 28 days) and a full Lighthouse lab run (a controlled, repeatable simulated load), and explains the difference in plain English instead of leaving you to guess which number matters.

Core Web Vitals, explained for owners (not engineers)

Google measures three things about how a page feels to use, from real Chrome browsers, and folds them into search ranking:

Metric	What it measures	Good threshold (p75)
LCP: Largest Contentful Paint	How long until the biggest visible thing (hero image, headline) finishes rendering	≤ 2.5 s
INP: Interaction to Next Paint	How long the page takes to visibly respond after a click, tap or keypress	≤ 200 ms
CLS: Cumulative Layout Shift	How much content unexpectedly jumps around as the page loads	≤ 0.1

These aren’t lab theory: they’re the 75th-percentile experience of your actual visitors, recorded by Chrome itself and published in Google’s Chrome UX Report (CrUX). If a page has enough real-world traffic, Google shows this “field data” directly. If it doesn’t (a brand-new page, a low-traffic site), there’s no field data to show yet: Nitro Speed Test says so honestly instead of making something up, falling back to site-wide data or lab-only results.

Field data vs. lab data: the section every other speed tool glosses over

This is the single most confusing thing about speed testing, and most tools don’t explain it:

• Field data is what real visitors experienced, aggregated over the last 28 days, across every device, connection speed and cache state they happened to have. It’s the truth, but it’s a lagging indicator: change your site today and the field data won’t fully reflect it for weeks.
• Lab data is one simulated page load, on a fixed virtual device (a mid-range Android phone on throttled 4G, for the mobile test), captured right now. It’s instant and reproducible, but it’s one snapshot, not a real user’s messy reality.

A page can lab-test brilliantly (score 95) while its field data shows real users struggling (a slow LCP), if the lab run doesn’t reflect what most visitors actually experience: different geography, different devices, a cold cache versus a warm one. The reverse happens too. Use field data to answer “is there a problem”, and lab data to answer “what’s causing it”, which is exactly why this tool shows both, side by side, instead of picking one.

The usual suspects, metric by metric

• Slow LCP is almost always an unoptimised hero image, a render-blocking CSS/JS file sitting in front of it, or a slow server response time (TTFB) delaying everything downstream.
• Poor INP usually traces back to heavy JavaScript: a bloated framework bundle, a busy main thread, or third-party scripts (chat widgets, ad tech, analytics) competing for the same thread your visitor is trying to interact with.
• Bad CLS is almost always images or ads without a reserved width/height, web fonts swapping in late and reflowing text, or content injected above what’s already on screen (a cookie banner, a promo bar) after the initial paint.

The fix list on every scan is sorted by estimated time saved and rewritten in plain English, no “reduce your Cumulative Layout Shift by deferring non-critical resource hints,” just what’s slow and why.

Where the test runs

Every lab run happens in the Nitro Speed Lab, our own test machine. Each test gets a fresh copy of Google Chrome and the same Lighthouse release, with the same settings, that powers Google’s PageSpeed Insights: the same emulated phone (a Moto G Power), the same throttled 4G connection, the same scoring. The one thing we can’t copy is Google’s hardware, so before every run the lab benchmarks its own processor and scales the CPU slowdown until it matches Google’s test machines.

The lab tests one site at a time, so every score is measured on an otherwise idle machine and nobody’s result depends on who else happened to be testing. If other people are testing when you start, the tool tells you how many sites are ahead of you in the queue.

Two differences are worth knowing about:

• It runs from one fixed place, our own lab, every time. A site hosted on the other side of the world from its visitors really is slower for them, and the lab shows that distance honestly instead of hiding it behind a test machine that happens to sit next to the server.
• 3D and WebGL effects are switched off, because lab machines have no graphics card (see the FAQ below). The rest of the page is measured exactly as a visitor gets it.

How fast sites actually get built

Slow scores are usually a build problem, not a plugin problem: a heavy page builder, an unoptimised theme, unmanaged third-party scripts and cheap shared hosting compound into exactly the kind of numbers this tool surfaces. Nitro Sites builds lean from the ground up: no drag-and-drop page-builder bloat, no dozen-plugin stacks fighting each other. You don’t have to take our word for it: each result here shows the average score of our own live client sites in this same lab, measured the same way as yours, and puts your page next to one of those builds by name, so you can check it yourself.

For AI agents

This tool exposes a plain-text endpoint designed for language models and agents:

GET https://nitrosites.com/tools/speed-test/scan.php?url=<target>&strategy=mobile&format=agent

It returns a token-cheap digest of the same analysis shown on this page: lab scores, field-data verdicts, lab metrics, the top fixes ranked by estimated savings and the Nitro Sites portfolio benchmark from the same lab, so an agent can answer “how fast is this site, and what’s the biggest fix?” from a single GET. A fresh lab run takes 10 to 60 seconds; the endpoint waits up to 30 seconds, and if the run isn’t finished it answers RUNNING and asks you to repeat the same GET a little later, which then returns the finished result. Soft rate limits apply (20 new tests per 10 minutes per IP; every test is a real browser session in our lab); results are cached for 30 minutes. No key or login required on this side.

Frequently asked questions

What are Core Web Vitals?

Google's three user-experience metrics: LCP (how fast the main content shows), INP (how fast the page reacts to input) and CLS (how much the layout jumps). They're measured from real Chrome users and are an official Google ranking signal.

Why is my lab score different from my field data?

Lab data is one simulated load on a throttled device; field data is the 75th percentile of your real visitors over 28 days. A fast-for-users site can lab-test poorly (heavy first load, warm caches in the field) and vice versa. Trust field data for "is there a problem", lab data for "what's causing it".

What's a good LCP / INP / CLS?

Google's "good" thresholds at the 75th percentile are LCP ≤ 2.5 s, INP ≤ 200 ms and CLS ≤ 0.1. This tool chips every metric against those exact lines.

Why does my WordPress site score so low?

Usually theme and plugin JavaScript, render-blocking CSS, unoptimised images and cheap hosting TTFB: the fix list here names the exact files. Sometimes the honest fix is a leaner rebuild.

How often should I test?

After every meaningful site change, and monthly otherwise: field data moves on a 28-day window, so regressions show up slowly. Big redesigns deserve a before/after.

Is this the same as Google PageSpeed Insights?

Same engine, same settings, different machine. PageSpeed Insights is Google running Lighthouse; we run the same Lighthouse release with the exact configuration PageSpeed Insights uses, in our own test lab, with the CPU calibrated to Google's test machines. Most pages score within the swing PageSpeed Insights shows between two back-to-back runs of the same page (often 10 to 20 points), and our results repeat far more consistently. Pages with heavy 3D effects usually score better here, for the reason in the next answer. The real-visitor numbers come straight from Google's Chrome UX Report, the same data PageSpeed Insights shows.

Why do 3D and WebGL effects not show in the filmstrip?

Test machines have no graphics card, so a browser there has to draw 3D scenes in software, which ties it up for many seconds. That makes the page look far slower than it is on any real phone, and is why PageSpeed Insights often fails outright on pages with 3D effects. Our lab switches WebGL off, so the page loads the way it does on a device without it: the effect's fallback image instead of the animation.

Where does the "Nitro Sites builds average" number come from?

From our own portfolio, measured in this same lab. Every few hours the lab re-tests each live client site we have built, on mobile and on desktop, with exactly the settings your test gets: the same emulated phone or desktop, the same network, the same Lighthouse release and scoring. The average is the plain mean of each site's latest score, with no bonus and no adjustments, and those test runs only happen when nobody is waiting in the queue. The build shown side by side with your result is named and linked, so you can open it, or test it here yourself.

What's the Agentic Browsing score?

A new Lighthouse category Google added alongside Performance, Accessibility, Best Practices and SEO. It measures how well AI agents and browsing LLMs can navigate and use your page: whether it exposes a clean accessibility tree for an agent to read, whether it publishes an llms.txt file, and (where relevant) whether any WebMCP tools it registers are well-formed. It's a genuinely new signal, not a rebrand of an existing one; WebMCP itself is still rare, so most sites' scores here mainly reflect accessibility and llms.txt today.