Section 1
The first thing to understand: field data vs. lab data
The single most important thing to grasp about the report, and the thing that confuses people most, is that it shows you two different kinds of data, and they mean different things. Field data ("real user" data) is the truth that matters. At the top, the report may show how actual visitors experienced your site over the recent past. This is real-world data from real people, and it's what Google uses for ranking and what reflects your genuine user experience. If you only look at one thing, look here. (Note: this section only appears if your site has enough traffic for Google to have collected real-user data; smaller sites may not show it.) Lab data is a simulated test of one page load. The rest of the report is a single, simulated test run in a controlled environment, useful for diagnosing problems and testing fixes, but it's one lab run, not real users. A bad lab score on a fast-feeling site, or vice versa, is possible. Use lab data to find and fix issues; trust field data for the verdict. The report shows you a doctor's lab simulation and a record of how real patients actually felt. Both are useful, but when they disagree, the real patients win. Read the field data for the truth; read the lab data for the diagnosis.
Section 2
The numbers that matter (and the one that distracts)
The report throws a lot of numbers at you. Here's what to actually look at. The three Core Web Vitals, your real grades. In the field-data section, find LCP (loading speed, good under 2.5s), INP (responsiveness, good under 200ms), and CLS (visual stability, good under 0.1). Each is color-coded: green (good), orange (needs improvement), red (poor). These three are what matter for both rankings and real experience. A red on any of them is a real problem worth fixing. (These are explained fully in the companion Core Web Vitals piece.) The Opportunities and Diagnostics, your to-do list. Below the scores, the report lists specific issues and estimated time savings, "properly size images," "reduce unused JavaScript," "eliminate render-blocking resources." You don't need to understand each technically; you need to note the ones with the biggest estimated savings (usually shown in seconds) as your priority list to hand to whoever fixes your site. The report literally ranks your problems by impact. The one number to mostly ignore: the big 0–100 score. The large performance score at the top (often a circle with a number) is the most eye-catching and the most misleading for a founder. It's a single lab-based composite that fluctuates between tests and obsesses people unnecessarily. A score of 100 is not the goal, and a score of 70 is not a crisis. Don't optimize for the number; optimize for the three Core Web Vitals (in field data) being green and the high-impact opportunities being addressed. (This "ignore the headline score" guidance is my practitioner judgment, aimed at preventing the common mistake of chasing a vanity number.)
Section 3
How to read the report in five minutes
The reading order matters: start with the real-user verdict (field data), check mobile specifically (where most of your traffic is and where sites are usually slowest), then collect the highest-impact opportunities as your fix list, and don't get hypnotized by the headline score. In five minutes you go from an intimidating wall of technical output to a clear answer to two questions: is my site experience actually good or bad (field data), and what are the top three things to fix (opportunities)? That's everything a founder needs from the report, the rest is for whoever implements the fixes.
Section 4
Execute This With AI
Here is a workflow to turn your PageSpeed report into a plain-English action plan with any capable AI model. Step 1, Run the test. Go to PageSpeed Insights (free), enter your homepage and a key page, and check both the Mobile and Desktop tabs. Copy or screenshot the results, the field-data scores (if present), the Core Web Vitals, and the Opportunities list. Step 2, Run the translation prompt: You are a web-performance translator helping a non-technical founder read a Google PageSpeed Insights report. Key context: FIELD data (real users) is the truth that affects rankings; LAB data (one simulated run) is for diagnosis; the three Core Web Vitals (LCP <2.5s, INP <200ms, CLS <0.1) are what matter; the big 0–100 score is a fluctuating composite to mostly ignore. Here's my report data (mobile + desktop): """ [PASTE scores, Core Web Vitals, and Opportunities] """ Do five things: 1. Tell me plainly whether my REAL user experience is good or bad (from field data), and on which metrics. 2. Translate my top 3 Opportunities into plain English and what each would feel like to a visitor if fixed. 3. Prioritize the fixes by impact (use the estimated savings). 4. Tell me which fixes are easy (images, scripts) vs. need a developer. 5. Write a short brief I can hand a developer or freelancer with the priorities. Don't let me obsess over the 0–100 score; focus me on the Core Web Vitals. Step 3, Re-test after fixes. "After I make these changes, what should I re-check in PageSpeed to confirm they worked, and how long until field data updates?" Tools and expected output. Google PageSpeed Insights (free) plus any frontier chat model. Expect a plain-English verdict on your real experience, translated priorities, an impact-ranked fix list, and a developer brief. The QA discipline: remember field data updates slowly (it reflects weeks of real users), so don't expect the real-user scores to change the day after a fix, re-test the lab data to confirm the fix worked, and watch field data improve over the following weeks. The model translates the report; the field data is your eventual ground truth. Google hands you a free, honest, detailed report on exactly what's slowing your website down, and most founders never use it because it's written in a language they don't speak. The translation is simpler than it looks: read the real-user field data for the verdict, check mobile, grab your top three opportunities as a fix list, and ignore the hypnotic headline score. Spend an hour learning to read this report and you can diagnose one of the most monetizable problems your site has, for free, whenever you want, without ever calling a developer to ask "is my site slow?"
Section 5
Keep reading
Keep reading in the Performance & Core Web Vitals cluster and across the library: [Core Web Vitals in the INP Era: What Changed and Why It Matters](/blog/core-web-vitals-in-the-inp-era-what-changed-and-why-it-matters), [The Performance Cost of Animation (and How to Keep Motion From Slowing the Sale)](/blog/the-performance-cost-of-animation-and-how-to-keep-motion-from-slowing-the-sale), [Cumulative Layout Shift: The Jumpy Page That Quietly Loses Trust](/blog/cumulative-layout-shift-the-jumpy-page-that-quietly-loses-trust). Also relevant: [Speed-to-Lead: Why Page Speed and Reply Speed Are the Same Conversion Lever](/blog/speed-to-lead-why-page-speed-and-reply-speed-are-the-same-conversion-lever), [The Service-Business Website Priority Stack: What to Fix First When Everything Needs Work](/blog/the-service-business-website-priority-stack-what-to-fix-first-when-everything-needs-work), [How to Run a Website Project Without Being a Designer: The Operator's Process](/blog/how-to-run-a-website-project-without-being-a-designer).