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.

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, which is why a Nitro-built site tends to open this tool’s own report and see green across the board.

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 and the top fixes ranked by estimated savings, so an agent can answer “how fast is this site, and what’s the biggest fix?” from a single GET. Soft rate limits apply (10 tests per 10 minutes per IP; each run costs real Google API quota); results are cached briefly. 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.

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.