How to read a website speed report (for non-developers)
A website speed report in plain language: the three numbers that matter, what a poor result means for your visitors, which warnings to ignore first.
In this guide
Why reports look so scary
A speed report is written for developers. It has dozens of rows, units in milliseconds, red and orange everywhere, and recommendations with technical names. A page can have 40 warnings and still be fine, or two warnings and a real problem. The way through is to ignore most of it, at first, and look only at three things.
The ten-minute read
- Open the mobile result. Most visitors are on phones, and phones are slower. If the report has a mobile and a desktop tab, start on mobile.
- Find the real-visitor result. It is usually at the top and labeled something like "real users" or "field data". It says passed or failed. This decides whether the page passes Google's Core Web Vitals, and it is based on the last 28 days of actual visits. See lab data versus field data for why this is different from the big score below it.
- Note which of the three numbers fails. There are three: loading, responsiveness and stability. Each has a green, orange or red mark.
- Find the cause the report gives for that number. If loading fails, look for the main image, the server response and anything that blocks the page. If responsiveness fails, look for JavaScript. If stability fails, look for images and banners without a set size.
- Write down the numbers. You will want them for comparison after the fix.
If you do only this, you will already know more than most site owners.
The three numbers, in words
| Name | What a visitor feels | Good | If it is poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | "How long until the main thing on the page is here?" | 2.5 seconds or less | They stare at a blank or half-empty page and some leave |
| Interaction to Next Paint (INP) | "When I tap, does it respond right away?" | 200 milliseconds or less | Menus open late, buttons feel dead, people tap twice |
| Cumulative Layout Shift (CLS) | "Does the page jump around while I use it?" | 0.1 or less | They hit the wrong button, lose their place, get annoyed |
Google measures each at the 75th percentile: three out of four visits must be at least as good as the mark. The Core Web Vitals guide explains the rules.
Other numbers you will see
These are not the pass or fail numbers, but they explain them.
- Time to First Byte (TTFB). How long the server took to start answering. A slow one means the server or the hosting is the bottleneck.
- First Contentful Paint (FCP). When the first thing, anything, appeared. It is the first sign that the page is alive.
- Total Blocking Time (TBT). How long scripts kept the page busy while it loaded. It is a test number that stands in for responsiveness.
- Speed Index. How quickly the visible page filled in.
- The score from 0 to 100. A summary of one test, made from five of the numbers above. It is handy for comparing two tests, and it is not the pass or fail result.
Words you will meet, in plain language
| Word | What it means |
|---|---|
| Render-blocking | A file the browser must finish before it shows anything |
| Main thread | The one worker in the browser that runs scripts and draws the page |
| Third-party | Code from another company, such as chat, ads or analytics |
| Cache | A saved copy, so the same work is not done twice |
| CDN | A network that keeps copies of your files near your visitors (more) |
| Compression | Making files smaller for the trip over the network (more) |
| Minify | Removing spaces and comments from code to make it smaller |
| Lazy loading | Loading images only when the visitor scrolls near them |
| Preload | Telling the browser early about a file it will need |
| DOM | The structure of the page; a very large one is slow to update |
| WebP and AVIF | Image formats that are smaller than JPEG for the same quality |
| Bundle | The file or files that contain a site's JavaScript |
What to ignore at first
- Warnings that do not relate to the failing number. If loading is the problem, a note about unused JavaScript is worth later, not now.
- Estimated savings of a few hundred milliseconds. Savings overlap, and the estimates are rough. Look at the largest items.
- The scores for accessibility, best practices and SEO. They matter, but they are different jobs from speed. Handle them separately.
- The "passed" list. Open it once to see what is already good. Then forget it.
- A perfect score as a target. Passing for real visitors is the target.
Signs of a report that is not helping you
- A single number and nothing else. A good report has real-visitor data and lab data, for mobile and desktop.
- A promise of a perfect score or a top ranking. Nobody outside Google can promise a ranking, and a perfect lab score is not the goal.
- Recommendations that do not match the problem. A page that fails on loading, and a list of fixes about layout shift.
- Only desktop numbers. Phones are slower and are where most sites fail.
- No before and after. If the report does not show what will be compared, you cannot tell afterwards whether it worked.
- Dozens of equal-weight items. A good report ranks the problems: what to fix first, and why.
Questions to ask whoever will fix it
- Which of the three numbers fails on mobile, and what is the main cause?
- What will you change first, and how will we know it worked?
- How long until the real-visitor numbers improve? (Expect about four weeks, because the data covers a rolling 28 days.)
- Which fixes could break something, and how will you test them?
- Will you work on a copy of the site first, and keep a backup?
- Which parts of the problem are not in your control, such as third-party tools or my hosting?
Comparing two reports
To judge a change, compare like with like. Use the same page, the same device setting and the same tool. Run each test three times and use the middle result. Do not compare a test from Monday morning on your office wifi with one from Friday on your phone. For the real-visitor numbers, wait four weeks after the fix, because that is how long the data takes to catch up.
Check your own page
Run the free audit. The report is written for the reader who is not a developer: the pass or fail result first, the one or two causes that matter, and the fixes to start with. Keep the first version, then run it again after your changes to see what moved. If you want to see the full technical report, PageSpeed Insights explained walks through every section.
Sources
- Web Vitals on web.dev: what the three numbers measure and the marks.
- Lighthouse performance scoring: how the 0 to 100 score is made.
- Chrome UX Report methodology: where the real-visitor result comes from.
Start here
Free website audit
Live Google data for any public page: mobile and desktop.
Mobile + desktop · Lighthouse lab test · Real-user Chrome data when Google has it
Rather have this done for you? Speed optimization · Book a call