The PageSpeed Warnings Google Deleted (And What Replaced Them)

Someone sends you a PageSpeed report. It says "Defer offscreen images." You search the phrase, you find a dozen guides, you spend an afternoon adding lazy loading to every image on the site. Then you rerun the test and the warning is not there.

It was never fixed. Google deleted it.

On 20 October 2025, PageSpeed Insights switched over to Lighthouse 13, and that release quietly did the biggest reorganisation of the report in years. About thirty audits were merged into sixteen new ones. Six were removed completely. The old names disappeared from the report and, more importantly, from the JSON that every speed tool on the internet reads. If you have been following advice written before that date, some of it is now pointing at warnings that cannot appear anymore.

This page is the map. Every old name, what it turned into, and whether the fix behind it still matters.

What actually changed in Lighthouse 13

Lighthouse used to split its performance section into Opportunities and Diagnostics. Opportunities were things with an estimated time saving attached. Diagnostics were extra context. That split made sense in 2019 and made less sense every year after, because the same underlying problem often showed up in three or four places under different names.

Chrome's DevTools team had already built a better version of this in the Performance panel, where related findings are grouped into a single insight with the evidence attached. Lighthouse 13 adopted those same insights. The report now has an Insights heading, and a smaller Diagnostics heading for the checks that did not change.

Three things are worth being clear about, because this is where most of the confusion comes from.

The old audits are gone from the API, not just hidden in the interface. That is the part that broke tooling. Anything that read render-blocking-resources from the JSON response now gets nothing back. No error, no warning, just an absent key. We found this the hard way on our own analyser, which had three checks that had silently stopped firing months before we noticed. If your favourite speed plugin has been suspiciously quiet about images lately, this is very likely why.

Your score did not change. Google kept the scoring formula identical. Performance is still weighted Total Blocking Time 30 percent, Largest Contentful Paint 25 percent, Cumulative Layout Shift 25 percent, First Contentful Paint 10 percent and Speed Index 10 percent. If your number moved in October, that was your site or normal test variance, not the new version.

The thresholds did not change either. LCP under 2.5 seconds, CLS under 0.1, INP under 200 milliseconds, all measured at the 75th percentile of real Chrome users. Those are the numbers that decide whether you pass, and they were untouched.

You can check which version you are looking at yourself. Run any URL through the PageSpeed Insights API and read the lighthouseVersion field. At the time of writing it returns 13.4.1.

The full map: old name to new name

This is the table to bookmark. Left column is what you were told to fix. Right column is what the report calls it now.

One name that is missing from that table on purpose: "Defer parsing of JavaScript." It is one of the most searched performance phrases in the world and it has never been a PageSpeed audit. It comes from old GTmetrix reports and from WordPress plugins that kept the wording in their settings panels. The modern equivalent is render-blocking-insight, and the fix is covered in our guide to deferring JavaScript.

The six audits Google deleted, and what to do instead

Defer offscreen images

This is the big one. It generated more search traffic than any other audit name, and it is completely gone.

Google's stated reason is that browsers already deprioritise images outside the viewport. Chrome has been doing that for years through the fetch priority heuristics, so an image sitting three screens down does not compete with your hero for bandwidth the way it did in 2019. The audit had started flagging pages that had no real problem, which is the worst thing a diagnostic can do.

What that does not mean is that lazy loading became pointless. Skipping the download entirely is still better than downloading it at low priority, especially on long pages, image galleries, and anything with a hundred product thumbnails. The rule has not changed:

<!-- below the fold: skip it until it is needed -->
<img src="product-14.webp" alt="Blue running shoe" width="600" height="400" loading="lazy" decoding="async">

<!-- the hero: never lazy load this one -->
<img src="hero.webp" alt="Runner on a coastal path" width="1200" height="630" fetchpriority="high" decoding="async">

The mistake that survived the audit's death is putting loading="lazy" on the hero. Plugins that lazy load everything site wide still do this, and it is one of the most reliable ways to wreck your LCP. Lighthouse now catches it under lcp-discovery-insight instead, which is a better place for it. The full details are in our lazy loading guide.

Preload key requests

This one deserves a moment, because its removal carries a lesson. Google pulled uses-rel-preload with the explanation that it was being over-recommended.

Preload is a genuinely powerful hint, and that is exactly the problem. When a tool tells thousands of developers to preload things, people preload six fonts, four scripts and a stylesheet, and every one of those requests now competes with the others at the highest priority. Preloading everything is the same as preloading nothing, except you also delayed the thing that mattered.

The advice that survives: preload the one resource that the browser cannot discover early on its own, and usually that is your LCP image or the single font used above the fold. Then stop. Our resource hints guide covers when each hint helps and when it hurts.

First Meaningful Paint

Retired because LCP does the same job better. If you still have dashboards or client reports tracking FMP, that is a good afternoon of cleanup. It has not been part of the score since Lighthouse 6.

Avoid document.write

Removed because it is rarely a problem in first party code anymore. If a third party script is still calling document.write in 2026 you have a bigger conversation to have with that vendor, and third-parties-insight will surface it on cost grounds anyway.

Use passive event listeners

Removed for the same reason. Modern browsers treat touch and wheel listeners on the document as passive by default, so the audit was mostly noise. If you are debugging genuinely janky scrolling, it is still worth checking, just not something the report will nag you about.

Third party facades

The facade pattern means replacing a heavy embed with a lightweight placeholder that loads the real thing on click. A YouTube thumbnail instead of the full player is the classic example.

The technique is excellent and still recommended. The audit went away because it was recommending specific unaffiliated third party libraries, which is not something Google wants a first party tool to do. Keep using facades. The savings are real, often several hundred kilobytes per embed, and our third party scripts guide shows how to build one without a dependency.

The renamed audits, in plain language

The merges are mostly good news. Instead of four separate image complaints you get one, with all the evidence in a single place.

image-delivery-insight

Absorbs the four old image audits: next generation formats, optimised images, responsive images, and animated content. One entry now tells you which images are oversized, which should be WebP or AVIF, and roughly what you would save.

The fix has not changed in five years. Resize to the dimensions the image actually displays at, convert to WebP, quality around 80, and set explicit width and height so the layout does not jump. You can do the conversion in your browser with our free image optimizer, or follow the longer walkthrough in how to compress images for the web.

render-blocking-insight

Same audit, new suffix. Stylesheets and synchronous scripts in the head delay first paint. Add defer to scripts that are not needed immediately, load non critical CSS asynchronously, and inline only what the first screen needs. That last part is the trickiest, and it has its own walkthrough in our critical CSS guide.

document-latency-insight

This one merged three things that were always the same story: slow server response, unnecessary redirects, and missing text compression. All three are about how long it takes to get the HTML document into the browser's hands.

Under 200 milliseconds is excellent, under 500 is fine, and Google's guidance is to stay under 800 at the 75th percentile. Past that you are burning a third of your LCP budget before a single pixel appears, which is why server work has to come before front end work. See TTFB and server response time for the full treatment.

cls-culprits-insight

A real improvement. The old report told you your CLS score and left you guessing. This one names the elements that moved, which animations were not composited, and which images had no dimensions.

Most layout shift comes down to three causes: images and iframes without width and height, ads or banners injected above existing content, and web fonts swapping in at a different size. Our CLS fix guide covers each, and the CLS visualizer lets you watch the shifts happen side by side with the fixed version.

lcp-discovery-insight and lcp-breakdown-insight

Discovery answers one question: could the browser find your largest image early enough? It catches the hero that is lazy loaded, the hero that is injected by JavaScript, and the hero that is buried behind a slow CSS reference.

Breakdown splits your LCP into its phases so you can see whether the time went on the server, on the download, or on render delay. That distinction decides what to fix, and it is the single most useful thing in the new report. Our LCP finder will tell you which element is being measured on any URL.

inp-breakdown-insight and forced-reflow-insight

INP replaced First Input Delay in March 2024 and it is much harder to pass, because it measures every interaction rather than just the first. Breakdown shows where the delay sits: waiting for the main thread, running your handler, or painting the result.

Forced reflow is a new addition and a welcome one. It catches the pattern where a script changes something, then immediately reads a layout value like offsetHeight, forcing the browser to recalculate layout in the middle of a frame. Batch your reads before your writes and it disappears. More in how to fix INP and INP vs FID.

network-dependency-tree-insight

Combines critical request chains with the preconnect check. It shows you the chain of files that must load one after another before your page can paint. Long chains are usually a stylesheet that imports another stylesheet that references a font, and the fix is to flatten the chain and preconnect to origins you know you will need.

cache-insight, font-display-insight, third-parties-insight and friends

The rest are straight renames. Cache policy still wants fingerprinted assets with a long max age. Font display still wants swap so text is visible while the font downloads, covered in our font loading guide. Third parties insight still ranks external scripts by the main thread time they cost, and you can get the same view for any URL from our script auditor.

How to read the new report without getting lost

The layout confuses people who learned the old one, so here is the order that works.

Start with the field data at the top. That is real Chrome users over the last 28 days, and it is the only part Google uses for ranking. If the coloured bars at the top say you pass, you pass, whatever the score below says.

Treat the score as a diagnostic, not a target. The number underneath is a lab simulation on a throttled mid range phone. It is useful for finding problems and terrible as a KPI, because it moves several points between runs on the same page. If you want to know the difference in detail, we wrote Lighthouse vs PageSpeed Insights vs WebPageTest.

Then open Insights, not Diagnostics. Insights are sorted by estimated impact. The first two or three usually account for most of the loss. Everything below that is refinement.

Check mobile before desktop. Mobile runs with four times CPU throttling and a simulated slow connection, which is where nearly every failure lives. A site that passes on desktop and fails on mobile is the normal case, not a bug, and we covered why in passing desktop but failing mobile.

If you build tools, check your audit IDs

This section is for the developers. When Lighthouse 13 dropped the old audits from the JSON, every integration that looked up an audit by its exact key started returning nothing for those checks. There is no error and no deprecation notice. The key is simply absent, and a naive lookup treats absent as "no problem found".

The defensive pattern is to try the new key first and fall back to the old one, so your tool works across versions:

// Try the Lighthouse 13 insight first, then the legacy id.
function pickAudit(audits, ids) {
  for (const id of ids) {
    const audit = audits[id];
    if (audit && audit.score !== null && audit.score !== undefined) {
      return audit;
    }
  }
  return null;
}

const images = pickAudit(audits, [
  'image-delivery-insight',
  'uses-optimized-images',
  'uses-webp-images'
]);

Note the null check. A score of null means "not applicable", and in a loosely typed language a null compares as lower than any threshold you test against, so an audit that does not apply will happily report itself as a failure if you are careless. That is a false positive on a page that is doing nothing wrong.

We rebuilt our own analyser around exactly this pattern after finding that three of its checks had gone quiet. On one news site the old code reported a single issue and the corrected code reported seven, all of them real.

What this means if you run WordPress

Most WordPress performance plugins were built around the old audit names, and several still show them in their settings. WP Rocket, LiteSpeed Cache, Perfmatters, Autoptimize and FlyingPress all have toggles with wording that came straight from a 2019 Lighthouse report.

That wording is now out of step with what PageSpeed tells you, which produces a specific and very annoying situation: you tick "Defer offscreen images" in the plugin, you rerun the test, and the warning you were chasing is not in the report either way. Nothing you did shows up, so you cannot tell whether the setting worked.

The way through it is to stop matching plugin labels to report labels and start checking the metric instead. Turn on lazy loading, then look at LCP rather than looking for the old warning. Turn on critical CSS, then look at First Contentful Paint and render-blocking-insight. The plugin toggles are still doing real work, they are just labelled in a language the report no longer speaks.

Two settings deserve a second look while you are in there. First, any option that lazy loads all images, because it will include your hero unless you add an exclusion, and that single setting can cost you a second of LCP. Second, any option that preloads a long list of resources, since that was the exact behaviour Google retired the preload audit over. Our WordPress Core Web Vitals guide goes through the plugin settings one at a time.

How to tell if performance advice is out of date

Since a lot of what is published about PageSpeed was written before October 2025, it helps to have a quick test for whether a guide is current.

If an article talks about the Opportunities section, it predates Lighthouse 13. That heading does not exist anymore. If it lists First Meaningful Paint as something to optimise, it predates Lighthouse 6 and is genuinely ancient. If it tells you to preload everything above the fold, it is repeating advice that Google itself pulled for causing more harm than good. If it discusses First Input Delay as a current metric, it predates March 2024, when INP took over.

None of that makes the underlying technique wrong. Compression is still compression. But a guide that has not been touched in two years will send you looking for warnings that cannot appear, and that is how people end up doing an afternoon of work with nothing to show for it.

The most reliable habit is to check the date on anything performance related, then check whether the audit names in it still exist in a real report. If you cannot find the name in your own PageSpeed run, the article is describing a version of the tool you are not using.

The short version

• PageSpeed Insights has run Lighthouse 13 since 20 October 2025.
• Around thirty audits became sixteen insights. Six were retired.
• "Defer offscreen images" no longer exists. Keep lazy loading below the fold anyway, and never lazy load your hero.
• "Preload key requests" no longer exists. Preload one thing, not everything.
• "Defer parsing of JavaScript" was never a real audit. You want render-blocking-insight.
• Scores, weightings and the Core Web Vitals thresholds are unchanged.
• If you read the API by audit id, add fallbacks or your checks are already silently dead.

Questions people actually ask

Why can I no longer find "Defer offscreen images" in PageSpeed Insights?

Google removed the offscreen-images audit in Lighthouse 13, which reached PageSpeed Insights on 20 October 2025. The reason given was that browsers already deprioritise images outside the viewport, so the warning was firing on pages that had no real problem. Lazy loading below the fold is still worth doing, you just will not be told off for skipping it.

What replaced "Eliminate render-blocking resources"?

render-blocking-insight. Same advice, new name and new grouping in the report.

Is "Defer parsing of JavaScript" a real PageSpeed audit?

No, and it never was. The phrase comes from older GTmetrix reports and from WordPress plugin settings. The equivalent modern audit is render-blocking-insight.

Did Lighthouse 13 change my performance score?

No. The formula is untouched: Total Blocking Time 30 percent, LCP 25 percent, CLS 25 percent, First Contentful Paint 10 percent, Speed Index 10 percent.

Which Lighthouse version does PageSpeed Insights run now?

Lighthouse 13, currently 13.4.1. Check the lighthouseVersion field in the API response if you want to confirm it for yourself.

Do I need to redo work I already did?

Almost never. The two worth reviewing are blanket preload tags and any facade you added only because a tool told you to. Everything else still holds.