A founder in a city that does not exist once forwarded me a report titled "is this bad??" with eleven red numbers highlighted in yellow. Here is the short version: a web performance report is a health checkup for your site, and you can read one without a CS degree by learning about six numbers and what a good, mediocre, and bad value looks like for each.
That is the whole trick. The tools throw a hundred metrics at you to look thorough. You need about six. Once you know which six and where the lines are, you can decide what to fix yourself, what to hand a developer, and what to ignore.
What is a web performance report actually measuring?
A web performance report measures how fast your site loads and how stable it feels while it loads. Most reports you will see come from one of two places: Lighthouse (the audit built into Chrome and the engine behind PageSpeed Insights), or Core Web Vitals, which is Google's specific set of three user-experience metrics.
The distinction matters because they answer different questions. Lighthouse runs a test on demand, in a lab, on a simulated device. Core Web Vitals are measured on your real visitors over the previous 28 days, which Google calls field data. Lab data tells you what could happen on a controlled run. Field data tells you what actually happened to real people on real phones.
When the two disagree, trust the field data. I have seen sites score 74 in Lighthouse but pass all three Core Web Vitals in the field because most visitors were on decent connections. The lab was pessimistic. Real users were fine.
What do the Core Web Vitals numbers mean?
Core Web Vitals are three metrics, each with a plain job. Here is what they measure and where the lines fall, straight from Google's own thresholds:
| Metric | What it measures in plain terms | Good | Needs work | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | How long until the biggest thing on screen shows up | under 2.5s | 2.5s to 4s | over 4s |
| INP (Interaction to Next Paint) | How fast the page reacts when you tap or click | under 200ms | 200ms to 500ms | over 500ms |
| CLS (Cumulative Layout Shift) | How much stuff jumps around while loading | under 0.1 | 0.1 to 0.25 | over 0.25 |
LCP is your loading speed. If it is over 4 seconds, visitors are staring at a mostly blank page long enough to leave. Usually the culprit is a giant hero image or a slow server.
INP is your responsiveness. You tap a button and nothing happens for half a second. That lag is INP. It replaced the old metric FID in March 2024, so if you see an older report mentioning FID, it is out of date.
CLS is your visual stability. You go to tap a link and an ad or image loads above it, shoving everything down, and you tap the wrong thing. That is layout shift. A score of 0 means nothing moved. Anything over 0.25 feels broken.
What is a good Lighthouse score?
A good Lighthouse performance score is 90 or above out of 100. Lighthouse colour-codes it so you do not have to memorize the bands: 0 to 49 is red, 50 to 89 is orange, 90 to 100 is green.
The score is a weighted blend of several lab timings, so treat it as a rough grade rather than a precise measurement. It will bounce five or ten points between runs on the same page because it depends on network conditions and server load at test time. Do not panic over a single number. Run it three times and look at the average.
One thing worth knowing: Lighthouse also grades Accessibility, Best Practices, and SEO in separate scores. Those are genuinely useful and often easier to fix than raw speed. A 100 in performance with a 60 in accessibility is not a healthy site.
What is server response time and why does it matter?
Server response time, usually labeled TTFB (Time to First Byte), is how long your server takes to send back the very first piece of the page after a browser asks for it. Google considers under 800 milliseconds good.
Think of TTFB as the kitchen, and everything else as plating the dish. If the kitchen takes four seconds to even start cooking, no amount of fast plating saves the meal. High TTFB drags LCP up with it, because the browser cannot paint anything until the server responds.
When I see a bad TTFB, it usually points at one of three things: cheap or overloaded hosting, a database doing too much work per page, or no caching. This is the one metric where the fix is almost always on the server side, which means it is a developer job, not a content tweak.
The most useful thing a founder ever sent me was not a screenshot of red numbers. It was one line: "LCP is 5.1 seconds on mobile, everything else passes." That told me exactly where to dig. A whole report screenshot tells me you are worried. One bad number tells me where to start.
Which numbers should you fix yourself and which need a developer?
Some performance problems have non-technical fixes. Most do not. Here is the honest split:
- You can often fix yourself: oversized images you uploaded (a 4MB photo pushing up LCP), too many marketing scripts and tracking pixels, an autoplay video, a chat widget loading on every page.
- Hand to a developer: high TTFB, layout shift from fonts or ads, slow JavaScript causing bad INP, render-blocking code, anything involving caching or hosting.
A rough sense of cost: swapping heavy images for compressed ones is often a same-day fix. Chasing a bad TTFB down to its cause can be a few hours to a couple of days depending on the stack, and might end in a hosting change. If a report shows every metric in the red at once, that is usually a hosting or build problem, and it is worth getting a developer to look before you spend money on plugins that promise to fix speed.
How do you turn a report into a brief for a developer?
You turn a report into a good brief by naming the specific metric, the specific number, and the specific page, on mobile or desktop. That is it.
Comparing bad briefs to good ones:
| Vague brief | Useful brief |
|---|---|
| "The site feels slow" | "LCP is 4.8s on mobile on the homepage, field data" |
| "Google says my score is bad" | "Lighthouse performance is 48, mostly from unused JavaScript" |
| "Things jump around" | "CLS is 0.31 on the blog, looks like the header images" |
The right column gets you a fast answer and an accurate quote. The left column gets you an hour of back-and-forth while someone figures out what you meant. You do not need to know the fix. You just need to point at the exact symptom, and the report already gives you the words to do it (see What Makes Working With a Web Developer Work Long-Term).
If you want a second read on a report before you brief anyone, I am happy to look at one. That is part of what we do at Subsecond Studio when we take on a build or a rescue.
FAQ
What is the difference between lab data and field data?
Lab data is a single test run in a controlled, simulated environment, like Lighthouse in your browser. Field data is measured from your actual visitors over the past 28 days. When they disagree, field data reflects real experience and should win.
Is a Lighthouse score of 100 necessary?
No. Chasing a perfect 100 has sharply diminishing returns. Anything in the green band, 90 or above, is a healthy site. Passing all three Core Web Vitals in field data matters more than a perfect lab score, because it means real users are having a good experience.
Why does my score change every time I run the test?
Because Lighthouse measures a live run that depends on your network speed, your device, and how busy the server is at that moment. Variation of five to ten points between runs is normal. Run it a few times and use the average rather than reacting to any single result.
Get your website designed before you pay. Subsecond Studio designs and builds websites, web apps, and AI tools, and you approve the design before any payment. Get an estimate