If you’ve ever run your website through a free testing tool and gotten back a score, you’ve probably had two reactions in a row: a little jolt at the number, and then no real idea what it means. This is a complete, plain-language guide to the three tools worth knowing — what each one measures, what every score and term actually means, and, just as important, what they don’t. They’re three of the good free ones, not the only tools out there, but together they cover most of what matters. Nothing here assumes you already know the jargon; every term gets explained the first time it comes up.
The three tools at a glance
Three different inspectors, three different questions. They barely overlap — a site can ace one and fail another, which is exactly why it’s worth running all three.
- PageSpeed Insights (from Google) — how fast and well-built is it? Returns four scores, on both mobile and desktop.
- WAVE (from WebAIM) — can everyone actually use it? Returns counts of accessibility issues rather than a single grade.
- HTTP Observatory (from Mozilla) — is it set up to protect visitors? Returns a letter grade, A+ down to F, based on security settings.
All three are free, run in your browser with no login, and are read-only — they don’t change anything on your site. All three test one web address at a time, so it’s worth scanning your important pages, not just the homepage. (With one exception, noted under HTTP Observatory below.)
1 · PageSpeed Insights
Google’s performance inspector, and the one most people have heard of. You paste in your address at pagespeed.web.dev and it measures how quickly your page loads and becomes usable. Behind the scenes it runs an open-source testing engine called Lighthouse, and then adds a layer of real-world data on top. The single most important thing to understand is that it shows you two different kinds of data, and they answer different questions.
Lab data vs. field data — the thing everyone confuses
Lab data is a fresh test the tool runs right now, in a controlled simulation — one fixed pretend-device, one fixed connection speed, every time. It’s consistent and repeatable, which makes it good for pinpointing problems. This is what produces the big 0-to-100 Performance score, and it appears lower down in the report.
Field data is different: it’s measurements from real people who actually visited your page over the past 28 days, collected by Chrome (Google calls this the Chrome User Experience Report, or CrUX). It’s a little noisy — real visitors are on all kinds of devices and connections — but it’s the truth about how your site really behaves. It appears at the top, and it only exists if your page gets enough traffic; a brand-new or quiet page simply won’t have any.
The big 0-to-100 score is lab data only — the simulation. The field data is what Google actually uses when it decides how to treat your site in search. So a page can score 95 in the lab and still show “Poor” in the field, if real visitors are on slower connections than the simulation assumed. When the two disagree, the field data is the truth about your visitors, and the lab data is the truth about the code. Both are worth reading — they’re just answering different questions.
Mobile and desktop — two separate tests
PageSpeed runs everything twice, with different simulated conditions, and grades them on different curves (the same load time scores lower on mobile than on desktop, on purpose).
- Mobile pretends to be a mid-range phone on a throttled cellular connection. This is the harder, more important number — most visitors are on phones.
- Desktop uses a standard computer on a fast connection, and almost always scores higher. Don’t let a green desktop score reassure you if the mobile score is red.
The four category scores
Each is scored 0–100, with the same color bands throughout: 0–49 red (poor), 50–89 orange (needs improvement), 90–100 green (good).
Performance — a weighted blend of five speed measurements. This is the one people mean when they say “PageSpeed score.” The five pieces are broken down just below.
Accessibility — an automated check of common issues like labels, contrast, and structure. Important catch: this is a partial automated check. It can come back green on a page that WAVE (the next tool) then flags with real problems. A green accessibility score here does not mean your site is actually accessible — that’s WAVE’s job, not this one’s.
Best Practices — whether the site is built using sound, current methods: served securely, no outdated code, images at correct proportions, no errors in the background. A rough proxy for “was this built carefully.”
SEO — whether the technical basics that let search engines read your page are present: a title, a description, links they can follow, valid structure. Important: this checks that the foundations exist. It is not a ranking score and not a promise of traffic. A perfect 100 means “nothing technical is stopping Google from reading this,” nothing more.
The five Performance metrics
The Performance score is a weighted average of these five. The percentage is how much each one moves the overall number — worth knowing so you can tell which problems actually matter. The first two together are more than half the score.
| Measurement | What it means | Good | Needs work | Poor |
|---|---|---|---|---|
| LCP (25%) | Largest Contentful Paint: when the biggest visible thing — usually the main image or headline — finishes appearing. The “the page is here” moment. | ≤2.5s | 2.5–4s | >4s |
| TBT (30%) | Total Blocking Time: how long the page was frozen and couldn’t respond to taps or clicks while loading. Carries the most weight, and is almost always caused by heavy code (JavaScript). | ≤200ms | 200–600ms | >600ms |
| CLS (25%) | Cumulative Layout Shift: how much the page jumps around as it loads — text reflowing, images shoving content down. A lower number means a steadier page. | ≤0.1 | 0.1–0.25 | >0.25 |
| FCP (10%) | First Contentful Paint: when the very first piece of content appears. The “something is happening” moment. | ≤1.8s | 1.8–3s | >3s |
| SI (10%) | Speed Index: how quickly the page visually fills in overall during loading. | ≤3.4s | 3.4–5.8s | >5.8s |
The field-data terms at the top (Core Web Vitals)
Core Web Vitals are Google’s three headline real-visitor measurements: LCP, INP, and CLS. To “pass,” 75% of real visits need to rate “Good” on all three. This is the set that’s relevant to search.
INP (Interaction to Next Paint) measures responsiveness across the whole visit — every tap and click, not just the first — and good is 200 milliseconds or less. It replaced an older measurement called FID in 2024, so if you see FID referenced somewhere, that source is out of date. (The lab test can’t measure INP directly, which is why it uses TBT above as a stand-in.)
TTFB (Time to First Byte) is how long your server takes to send the very first piece of the response. It isn’t one of the Core Web Vitals, but it underlies everything: if the server takes 1.2 seconds to answer, the page physically can’t start loading faster than that, no matter how well everything else is built. Slow hosting, no content-delivery network, and redirect chains are the usual causes.
Why the scores wobble
Run the same page twice and the lab score can swing 5–15 points, just from normal fluctuations — network jitter, server load, the test routing through a different data center, a cold start. This is expected. Run it a few times and trust the middle result rather than reacting to any single number.
2 · WAVE
The accessibility inspector, at wave.webaim.org. Where PageSpeed gives accessibility a single rough score, WAVE shows you the actual issues, laid right over your page so you can see where they are. It reports counts in several categories — there’s no single grade.
Some visitors can’t see the screen and have it read aloud; some can’t make out faint text; some navigate by keyboard instead of a mouse. Accessibility is simply whether your site works for them too — and they’re real customers. Beyond being the right thing to do, it widens who can reach you, and for a business an inaccessible site can carry real legal exposure. WAVE looks at your page through those visitors’ eyes.
The categories
- Errors — things that will actually block someone using assistive technology. For example: an image with no text description for a screen reader to announce, a form field with no label, or an empty link or button. These are the ones that matter most.
- Contrast Errors — counted separately because they’re the most common issue by far: text too faint against its background to read comfortably. Easy to fix, and it helps far more people than you’d expect — including anyone reading on a phone in bright sun.
- Alerts — not necessarily broken, but worth a human look: a skipped heading level, a redundant link, alt text that’s oddly long. Judgment required; not every alert needs action.
- Features — things that are present and good: alt text that exists, labels that exist, correct structure. Confirmation, not problems.
- Structural Elements — the page’s skeleton that WAVE detected: headings, lists, and the header / navigation / main / footer regions. Used to check the page’s outline makes sense.
- ARIA — counts of a special set of labels that describe interactive elements to assistive technology. Powerful, but easy to overuse — more isn’t automatically better.
A few terms underneath WAVE
- WCAG — the Web Content Accessibility Guidelines, the international standard WAVE checks against. It has levels A, AA, and AAA; AA is the practical and legal target for most sites.
- Alt text — the written description attached to an image that a screen reader reads aloud, and that also shows if the image fails to load.
- Screen reader — software that reads a page aloud (or drives a braille display) for blind and low-vision users. A lot of what WAVE checks comes down to “will this make sense read aloud.”
- Contrast ratio — the measured difference in brightness between text and its background, written like 4.5:1. Higher is easier to read; 4.5:1 is the minimum for normal text.
WAVE isn’t perfect. It can flag a contrast problem that isn’t really there, when it can’t quite work out the colors a page is using. So the counts are a starting point a person still has to read, not a final verdict. The big picture it gives you, though, is real — and it’s the kind of thing that stays invisible until someone points it out.
3 · HTTP Observatory
The security inspector, from Mozilla, at developer.mozilla.org/observatory. It checks the security headers your site sends — invisible instructions your server passes to the browser telling it how to behave safely. It does not test for hacks or hunt for weaknesses in your code; it checks whether the standard browser-level protections are switched on and set up well. It grades the result from A+ down to F.
This is a security inspector — but not the kind that checks whether your locks can be picked. It checks whether you remembered to set the locks in the first place.
And the misconception to clear first: the padlock in your address bar is not the whole story. That padlock (HTTPS) means the connection is encrypted — good, necessary, but it’s only the front door. A site can have a perfect padlock and still score an F here, because the padlock and these security settings are two different things. Most sites have the first. Far fewer have the second.
One convenience: unlike the other two tools, you usually only need to scan once. These settings are typically applied across your whole site at the server level, so what’s true on your homepage is generally true everywhere. (Speed and accessibility genuinely change from page to page; this doesn’t.)
How the grading works
- Every site starts at 100 points.
- Points come off for missing or misconfigured protections — for example, no content-security policy, no forced-HTTPS setting, no clickjacking protection each cost a chunk.
- Bonus points for especially strong setups only count if your base score is already 90 or above — so you can’t make up for a weak foundation with one strong setting.
- The final number maps to a letter grade, A+ down to F, across a 13-step scale. Below a C means meaningful gaps.
The protections it checks — in plain terms
- Content-Security-Policy (CSP) — the most powerful and most complex one. It’s a guest list telling the browser which sources of scripts and content it’s allowed to run, so an attacker can’t sneak their own code onto your page. The main defense against a common attack called cross-site scripting.
- Strict-Transport-Security (HSTS) — forces browsers to always use the secure HTTPS connection for your site, even if someone types plain “http.” Prevents a class of attacks that quietly downgrade the connection.
- X-Frame-Options / frame-ancestors — stops other websites from loading your pages inside a hidden frame. The core defense against clickjacking, where a visitor is tricked into clicking something invisible.
- X-Content-Type-Options — stops the browser from “guessing” a file’s type and, say, running an uploaded text file as code. Cheap, and always worth setting.
- Referrer-Policy — controls how much of your page’s address is shared when a visitor clicks a link to another site.
- Permissions-Policy — controls which device features (camera, microphone, location, payment) the page is allowed to use. Turning off the ones you don’t need shrinks the ways a site could be misused.
A few terms underneath it
- HTTP headers — invisible bits of information sent with every page, before the visible content. Security headers are the subset that concern safety.
- Cross-site scripting (XSS) — an attack where malicious code gets injected into your page and runs in a visitor’s browser. A content-security policy is the main thing that stops it.
- Clickjacking — layering something invisible over your page so a visitor’s click does something they didn’t intend.
An A+ here means “A+ on the security-headers scan.” It doesn’t mean “this site can’t be hacked” — no tool can promise that, and no honest grade tries to. What a good grade really tells you is that the standard, sensible precautions are in place — the same way a deadbolt is a smart thing to have without turning your house into a vault.
What the numbers are really for
Notice the thread running through all three: a score is a measurement, not a verdict, and not a promise. A speed score is a summary of a list — the list is the part worth reading. An accessibility count is a starting point a person still has to look at. A security grade tells you the locks are set, not that nothing can ever go wrong. And one green number is never the whole picture: a passing accessibility score can hide real problems WAVE catches, and an A+ can sit on top of a weaker setup than the letter suggests. Read past the headline.
None of these are a grade on you, and a low one isn’t a sign you did something wrong — they’re a to-do list, and most of what they turn up is more fixable than it looks. The real value in learning to read them is that your own website stops being a black box. You can run all three yourself, for free, this afternoon, and understand exactly what comes back — what’s solid, what’s worth a closer look, and what each number is and isn’t telling you. That understanding is yours to keep, whether you ever change a thing or hand it to someone else.
These three tools are part of how every Soltheia site gets built — checked for speed, accessibility, and security before it ever goes live. If you’re curious where your own site stands, I’m always happy to run it and share what I notice — useful whether we ever work together or not.