PageSpeed Insights and Lighthouse explained: what every score actually measures

What PageSpeed Insights actually is

PageSpeed Insights, usually called PSI, is a free tool from Google that analyzes a web page and reports how it performs for real users and under a simulated test. You paste in a URL, and it returns a report with a set of scores from 0 to 100 plus a long list of metrics and suggestions. It is the tool people mean when they say a site scores 90 or has all green ratings.

The tool matters for two reasons. First, it is the same measurement system Google talks about when it discusses page experience, so the numbers carry some authority. Second, it is free and public, which makes it the easiest way to compare how two websites are built. A potential customer can run it on your site in seconds, and so can you on a competitor's.

One honest caveat up front: PSI is a diagnostic, not a ranking promise. A high score does not guarantee rankings, and a low score does not doom a page that has excellent content. What it does do is expose real problems that frustrate real visitors, and frustrated visitors do not become customers.

Two kinds of data: field and lab

The top of a PSI report can show field data, which comes from the Chrome User Experience Report, known as CrUX. When real Chrome users visit your page, their browsers anonymously report how the page actually performed: how long the main content took to appear, how responsive it felt, and how much the layout jumped around. Field data reflects the last 28 days of real visits, on real devices, on real connections.

Below that is lab data, which comes from Lighthouse. Lighthouse loads your page in a controlled test environment with a throttled connection and a mid-tier simulated device, then measures what happens. Lab data is reproducible - run it twice and you get similar numbers - which makes it perfect for debugging, but it is still a simulation of one visit, not a summary of all of them.

The distinction matters because they answer different questions. Field data tells you what your visitors actually experience. Lab data tells you why. A page can also have no field data at all if it does not get enough Chrome traffic, in which case only the lab test appears. This is why a brand new site shows Lighthouse scores only, and why the lab score is the one most people quote.

Why there are two scores: mobile and desktop

Near the top of every PSI report is a pair of tabs: Mobile and Desktop. These are not two views of one test - they are two completely separate analyses. Lighthouse loads your page once under mobile conditions and once under desktop conditions, and because performance depends so heavily on the device and connection doing the loading, the two runs usually return different numbers. Sometimes dramatically different.

The mobile run simulates a mid-tier Android phone - a Moto G Power profile with a 412-pixel-wide viewport - on a deliberately degraded connection: about 150 milliseconds of network latency, roughly 1.6 megabits per second of throughput, and a processor throttled to a quarter of its normal speed. The desktop run uses a 1350-pixel-wide viewport on a much faster simulated connection, around 40 milliseconds of latency and 10 megabits of throughput, with no processor slowdown at all. Same code, same page, very different test conditions. That is why a site can score 95 on the desktop tab and 65 on the mobile tab.

The split exists because your visitors are split. Someone finding your business on a phone over a cellular connection has a very different experience than someone browsing at a desk on office wifi. A page that feels instant on a developer's workstation can still crawl on a three-year-old phone. Measuring only the easy case would hide exactly the problems that cost you the most visitors - and for most small business sites, phone visitors are the majority.

Field data gets the same treatment. The real-user numbers from the Chrome User Experience Report are segmented by device, so the report can show that real phone visitors are having a poor experience even when desktop visitors are fine. The other categories can differ between the two tabs as well - some accessibility and SEO checks only apply on mobile, like whether tap targets are big enough for a thumb.

Mobile appears first because it is the version that counts. Google uses mobile-first indexing, which means its crawler visits and ranks your pages the way a phone sees them - the mobile experience is the canonical one for search. Showing the harder test first also puts the honest number in front of you by default: if a page performs well under the mobile simulation, the desktop run almost always passes too. The reverse is not true, and that asymmetry is the whole reason the mobile tab leads.

Core Web Vitals: the three numbers Google cares about

Core Web Vitals are Google's three user-experience metrics, and they are the heart of the field-data section. Each has a threshold that separates good from needs improvement and needs improvement from poor, measured at the 75th percentile of real visits - meaning at least 75 percent of visits need to hit the good threshold.

Largest Contentful Paint, or LCP, measures loading: how long the biggest visible element takes to appear. Good is 2.5 seconds or less. This is usually your hero image or main heading, and it is the metric most directly tied to the feeling of a fast site.

Interaction to Next Paint, or INP, measures responsiveness: how quickly the page reacts when someone taps, clicks, or types. Good is 200 milliseconds or less. INP replaced First Input Delay as the official responsiveness metric in March 2024, because FID only measured the first interaction while INP watches the whole visit.

Cumulative Layout Shift, or CLS, measures visual stability: how much the page jumps while it loads. Good is 0.1 or less. This is the score that punishes ads that shove content down, images without dimensions, and buttons that move just as a visitor goes to tap them.

How the performance score is calculated

The big 0-to-100 number on a PSI report is the Lighthouse lab performance score, and it is a weighted average of five measured metrics. Each metric is scored against a statistical curve derived from real web performance data - a log-normal distribution - so improvements near the middle of the pack move the score more than refinements at the extreme ends.

In current versions of Lighthouse, the weights are:

• Total Blocking Time (TBT): 30 percent - how long the main thread is too busy to respond
• Largest Contentful Paint (LCP): 25 percent - loading speed of the main content
• Cumulative Layout Shift (CLS): 25 percent - visual stability
• First Contentful Paint (FCP): 10 percent - when anything first appears
• Speed Index (SI): 10 percent - how quickly the visible parts fill in

Why INP is missing from the lab score

Sharp-eyed readers notice that INP, one of the three Core Web Vitals, has zero weight in the lab score. That is deliberate. INP measures responsiveness to real interactions - taps, clicks, typing - and a lab test that never interacts with the page cannot observe it. TBT is the lab stand-in for responsiveness, which is why it carries the heaviest 30 percent weight: a page with a quiet main thread is a page that will respond quickly in the real world.

This also explains a common confusion: a site can ace its lab score and still show a poor INP in field data. Heavy JavaScript, long event handlers, and third-party scripts only reveal their cost when real people start clicking. When the two disagree, the field data is the truth.

The other three classic categories

Performance is the category everyone quotes, but a PSI report is actually four category scores plus an expanding list of detailed audits. The other three classic categories are simpler: they are checklists of pass or fail audits rather than weighted metric scores.

Accessibility runs a battery of automated checks, powered by the axe rules engine, against your markup: do images have alt text, do form fields have labels, do buttons and links have accessible names, is color contrast sufficient, are ARIA attributes used correctly. A perfect score means the page passes every automated check - it does not certify the site is fully accessible, because many real accessibility issues need human judgment, but it is a strong baseline.

Best Practices checks for modern, safe development habits: HTTPS, no browser errors in the console, no deprecated APIs, images at proper resolutions, safe third-party code. SEO runs a shorter checklist of basics: a title, a meta description, indexable content, crawlable links, valid structured data, legible text sizes, and tap targets that are not cramped together.

These three are worth maxing out because they are entirely within a developer's control. A page that loses points here has an objectively fixable problem, and unlike performance, the fixes rarely involve trade-offs.

The fifth category: Agentic Browsing

Lighthouse 13 added a new category called Agentic Browsing, and it is scored differently from everything else. Instead of a weighted 0-to-100 score, it shows a fraction - passed checks out of applicable checks, like 3/3 - because the standards for the agentic web are still emerging and Google says the focus is on actionable signals rather than a definitive ranking. The category is experimental, requires Chrome 150 or later to test, and is explicitly marked as subject to change.

The premise is new: AI agents increasingly browse the web on users' behalf, and a site that works well for a human can still be confusing for a machine. The category checks whether a page is navigable, stable, and discoverable for automated agents. There are seven audits in total, organized into four groups.

The agent accessibility audit

The largest check is a filtered set of accessibility rules - about 33 axe rules - that matter specifically for machine navigation. An AI agent does not see your page visually; it works from the accessibility tree, the structured map of elements, roles, and labels that assistive technology uses. If your buttons have no programmatic names, your links have no text, your form fields have no labels, or your ARIA roles are invalid, the agent's map is broken.

This is the same reason semantic HTML matters for screen readers. A div that looks like a button is invisible to an agent unless it has a real role and an accessible name. Passing this audit means every interactive element is identified and labeled well enough for a machine to find and use it.

Layout stability for agents

Cumulative Layout Shift appears again inside this category, and the reason is mechanical rather than cosmetic: an agent typically locates an element first, then acts on it moments later. If an ad slot pops in or a late-loading image shoves the layout down in between, the agent's target is no longer where it calculated it should be. The same shift that makes a person tap the wrong button makes an agent act on the wrong element.

This is one more reason the fix is the same everywhere: give images and embeds explicit dimensions, reserve space for late-loading content, and avoid injecting elements above the fold.

Discoverability: llms.txt and the AI catalog

The discoverability group currently holds two audits. The llms.txt check fetches your site's /llms.txt file - a machine-readable summary of your site written in Markdown. If the file is missing entirely, the audit is simply not applicable rather than failed. If it exists, it must meet the community recommendations: an H1 heading, at least one Markdown link, and real content, or it fails.

The second audit, newer and less known, validates an ai-catalog.json manifest - part of the emerging Agent Resource Discovery work. Lighthouse looks for the catalog at /.well-known/ai-catalog.json, or a pointer to it via an Agentmap line in robots.txt, a link element in the page, or a Link response header. If you have no catalog and no pointer, the audit does not apply. If a catalog exists, its schema is validated against the spec, with errors failing the check.

The three WebMCP audits

The final group validates WebMCP, a proposed standard that lets a website explicitly expose its tools and workflows to agents - essentially a formal contract for what an agent may do on your site. The three audits check whether tools are registered, whether forms that could be tools have declarative WebMCP coverage, and whether the registered schemas are valid.

WebMCP is early: it sits behind an origin trial and requires registration, so nearly every site today shows these three audits as not applicable. They are in the report now so the ecosystem can start measuring readiness before the standard lands.

Why the report shows 3/3, or 4/4

The fraction is the part that confuses people. The denominator counts only the audits that apply to your page - not the seven total. Audits that return not applicable drop out of both the numerator and the denominator, so the fraction always shows passed out of applicable.

On a site with a valid llms.txt, three audits typically apply: the accessibility tree, layout stability, and llms.txt. Pass all three and the report reads 3/3 - the score this site scores. A site with no llms.txt sees only 2/2, because a missing file makes that audit not applicable rather than failed. The WebMCP audits do not apply without WebMCP, and the AI catalog audit does not apply without a catalog or a pointer to one.

So where does 4/4 come from? Add a valid ai-catalog.json and a fourth audit becomes applicable - pass it and you get 4/4. Each additional applicable audit raises the denominator. If WebMCP ships and your site registers tools, the fraction could climb toward 7/7. The fraction is best read as a coverage report: more applicable audits means more agent-readiness surface exists on the site, and the numerator tells you whether what exists is correct.

Why scores fluctuate

Two runs of the same page rarely match exactly, and the causes are well documented. Lab tests run on simulated hardware and a throttled connection, so timing jitter shows up as score noise - a point or two between runs is normal, which is why we judge by the median of several runs rather than any single run. Field data shifts more slowly because it is a rolling 28-day window of real visits.

The agentic category adds its own variability. Tools registered through JavaScript may or may not be captured depending on when they register during the test. DOM size and complexity change the shape of the accessibility tree. And layout shifts that happen between an element being identified and acted on are, by nature, timing-dependent.

What actually drags a score down

After auditing enough sites, the same handful of problems account for most lost points. None of them are mysterious:

• Images that are too large, uncompressed, or missing dimensions - the single most common LCP and CLS problem
• Third-party scripts loading early: chat widgets, analytics stacks, tag managers full of legacy pixels
• Render-blocking CSS and JavaScript that delay first paint
• Slow hosting with a long server response time, which delays every metric downstream
• Heavy JavaScript bundles that keep the main thread busy and inflate TBT
• Web fonts that swap late or block rendering

How to read a report without overreacting

Read field data first - it is the truth about your visitors. If your Core Web Vitals pass in the field, the page experience is fine regardless of what the lab simulation says. Then read the lab metrics to find the biggest weighted losses: a bad LCP is usually an image or a slow server, a bad TBT is usually JavaScript, a bad CLS is usually missing dimensions or injected content.

The opportunities and diagnostics sections below the scores list the specific audits that failed, roughly ordered by estimated savings. Work the top of that list, retest, and judge progress by the median of a few runs. And keep the whole thing in proportion: the goal is a site that feels instant to your visitors, not a perfect number for its own sake. Scores in the 90s mean the site is genuinely fast; the difference between 97 and 100 matters far less than the difference between 60 and 90.

What we do with it

We build every site to score 90 to 100 in every category on both mobile and desktop, and we verify on a clean production build rather than a development server, because dev-mode tooling artificially lowers scores. The agentic browsing category is newer, so our bar there is a full pass of whatever audits apply - 3/3 today, with an eye on the AI catalog work as it matures.

If you want to see how your current site holds up, run it through PageSpeed Insights and compare it against the numbers in this article. Or book a free call and we will walk through the report with you and explain what each finding would take to fix. You can also see how this thinking shows up in real builds on our website development page and in our portfolio.