A Non-Technical Guide to Reading Your Lighthouse / PageSpeed Report

You ran your site through Google's PageSpeed Insights (or its underlying engine, Lighthouse), got back a score and a long list of warnings, and now you're staring at terms like "Time to Interactive" with no idea whether it's a real problem or noise. Here's the plain-English walkthrough.

The overall score

The 0–100 score at the top is a weighted combination of several underlying metrics, most importantly the three Core Web Vitals — see Core Web Vitals Explained for Non-Technical Founders for what those specifically measure. A score above 90 is generally considered good, 50–89 needs improvement, and below 50 is poor. That said, the score is a summary, not the full picture — a site can score "good" overall while still having one specific issue worth fixing, or score lower than expected due to one fixable problem that's dragging down an otherwise solid page.

The Core Web Vitals section

This is usually the first detailed section, showing your Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP) scores individually, each marked good, needs improvement, or poor. This is the section worth paying closest attention to, since these three specifically factor into Google's ranking and directly reflect real user experience.

The "Opportunities" section

This lists specific, actionable fixes the tool detected, usually with an estimated time savings next to each one — things like "Properly size images," "Eliminate render-blocking resources," or "Reduce unused JavaScript." These are generally worth acting on roughly in order of their estimated impact, since the tool is specifically flagging what's costing you load time on this exact page.

The "Diagnostics" section

This section is more technical and often less immediately actionable — things like "Avoid large layout shifts" or "Serve static assets with an efficient cache policy" without as clear-cut a fix as the Opportunities section. Worth reviewing, but often best interpreted alongside whoever maintains your site rather than acted on directly, since some diagnostic warnings require judgment calls about trade-offs rather than a simple, safe fix.

What's usually worth fixing first

In rough priority order for most sites:

1. Anything under Core Web Vitals marked "poor" — these directly affect both ranking and real user experience, and are usually the highest-impact category.
2. Image-related opportunities ("Properly size images," "Serve images in next-gen formats") — these are almost always safe, high-impact fixes with minimal risk of breaking anything. See Image and Asset Optimization for the specifics.
3. Render-blocking resources — scripts or stylesheets preventing the page from displaying quickly, often fixable by deferring non-critical scripts.

What's often safe to deprioritize

• Diagnostic items with very small estimated time savings (a few milliseconds) — chasing every last diagnostic warning has diminishing returns compared to fixing the handful of larger opportunities.
• Warnings tied to third-party scripts you don't control (an embedded widget or ad script flagged for its own inefficiency) — these are often outside your ability to fix directly without removing the third-party tool entirely, which is a business decision, not just a performance one.
• Small differences in overall score month to month — some fluctuation is normal due to network conditions during the test itself; look for consistent trends rather than reacting to a single test run.

A practical way to use this report

Rather than trying to fix every single item listed, share the report with whoever maintains your site and ask specifically: "which of these are quick, safe wins, and which would need more work or a trade-off decision?" Most sites see the majority of their realistic performance improvement from a small number of the highest-impact items — chasing a perfect 100 score is rarely worth the time investment past a certain point of diminishing returns.

If you want a full breakdown of what gets checked and fixed in a proper performance pass, see Accessibility and Performance Audit: What I Check Before Launch, or the performance optimization services page.