93% of reports say to remove unused JavaScript. On the same 440 sites, what we could change was the order of delivery

What is actually in the report

The performance section of a PageSpeed report is a list, and a list arriving in order reads as a priority order. Here is what that list contains across 440 audited sites, counted by how often each named hint appears with a saving attached.

Hint	Sites	Share
unused-javascript	410	93%
unused-css-rules	377	86%
bootup-time	344	78%
mainthread-work-breakdown	342	78%
long-tasks	342	78%
render-blocking-insight	333	76%
layout-shifts	237	54%
cache-insight	215	49%
image-delivery-insight	206	47%
font-display-insight	168	38%
legacy-javascript-insight	129	29%
unminified-javascript	117	27%
unminified-css	94	21%
server-response-time	59	13%
redirects	30	7%

The median report carries eight of these. Two observations follow from the shape of the table rather than from any single row.

Eight hints, fewer than eight problems

bootup-time, mainthread-work-breakdown and long-tasks appear on 78%, 78% and 78% of sites, and the near-identical shares are not a coincidence. They are three measurements of the same thing: JavaScript occupying the main thread. Add unused-javascript and legacy-javascript-insight and a site that ships one oversized bundle collects five of its eight hints from a single cause.

This is not a flaw in the tool. Each of those audits answers a different question and each is useful when you are looking at that question. It is a flaw in reading the list as a to-do list, which is what a numbered list of eight items invites. Google’s own note on the reorganisation of these audits says the direction of travel is the opposite: in some cases advice from many audits is consolidated into a single insight.

The top of the list is the part nobody outside the code can take

The two most common entries, on 93% and 86% of sites, are unused JavaScript and unused CSS. Both are answered the same way: rebuild the site’s bundles so they ship less. That requires the source, the build, and the ability to test what breaks.

The condition Lighthouse checks is documented plainly: Lighthouse flags every JavaScript file with more than 20 kibibytes of unused code. A file counts if any 20 KiB of it went unexecuted during one load. A component library that loads a date picker the visitor did not open on this particular page satisfies that, and so does a genuinely bloated bundle, and the report shows the same line for both.

We are on the outside of the code as well, and we make no attempt at either one. Nothing our proxy does removes a byte of unused JavaScript from a site’s bundle, and we do not rewrite CSS files to drop rules the page did not use. When the top two items on nine reports out of ten are items we do not touch, that is worth writing down rather than working around.

What was available to change on the same 440 sites

The same audits carry our change log. Each line records a component that rewrote something in the page, so the share below is the share of those 440 sites where the component found something to do.

What was changed	Sites	Share
Scripts given a defer or a later moment to run	312	71%
Stylesheets moved out of the blocking path	289	66%
Small stylesheets inlined instead of fetched	271	62%
First-screen image and logo given priority	266	61%
Off-screen sections marked skippable for layout	265	60%
Resource hints that pointed nowhere useful removed	256	58%
Images given a declared aspect ratio	249	57%
Body scripts moved to a later load	239	54%
Third-party widgets deferred	211	48%
Fonts inlined into the document	179	41%
CSS background of the first screen preloaded	175	40%
Critical CSS extracted	94	21%
font-display added to declarations in the markup	92	21%

Nothing in that column removes code from the site. Every line is about when and in what order the browser is told about something that was going to load anyway. That is the entire class of change available to anyone who cannot edit the source, and it maps onto exactly one of the top six report entries: render-blocking requests, at 76%.

The two lists answer two different questions

Lighthouse sorts by what it can measure. Everything on its list is a condition observable from one instrumented page load, and the conditions that are easiest to observe — bytes shipped and not executed, milliseconds of script — sit at the top because they are the most measurable, not because they are the most available.

A fix list sorts by what can be changed, and for anyone who is not the site’s developer that is a much shorter list: order, priority, timing, headers. The two lists overlap in the middle and diverge at both ends. That is the answer to the question this study opened with, and it is not a criticism of either list.

It does have a practical consequence, and it is the reason the report frustrates people who follow it. If your site sits at 40 and your report opens with unused JavaScript, then either the work is in your build system or it is not going to happen. Nothing you install in front of the site addresses that line, ours included. What the outside layer can address is the sixth line down, and how much that is worth depends entirely on the page: on 76% of these sites, the browser is being told about the render-blocking work before it is told about the image the visitor came to see.

What we would check first

Not in the report’s order, and not in ours either.

Look at whether the top hint is repeating itself. If unused JavaScript, bootup time, main-thread work and long tasks are all present, that is one finding with four labels, and the first question is what the scripts are, not which of the four to open.

Read the saving, not the presence. The insight entries report estimated milliseconds per metric. A hint present with 30 ms attached and a hint present with 1,200 ms attached occupy the same amount of space in the report and are not the same news.

Separate what needs the source from what does not. It is a short exercise and it usually splits an eight-item report into two lists of three and five. Everything in the first list is a scheduling decision for your team; everything in the second can be done at the edge, by you or by anyone else.