[Request for feedback] Adding shared performance insights to Lighthouse

[connorjclark]

A more detailed blog post about these upcoming changes: Lighthouse is moving to performance insight audits

---

The Performance panel in Chrome DevTools recently added insights to the trace view. These performance insights are powered by a trace analysis library that was designed to also run in Lighthouse. The performance insights are analogous to existing Lighthouse performance audits, but with some tweaks and consolidation. The goal is to offer the same performance advice across all our performance tools - Chrome DevTools, Lighthouse and PageSpeed Insights.

In Lighthouse, the set of performance audits that have been replaced by equivalent insight audits will be removed.

• v12.6.0 (soon to be released): display a toggle in the Performance section to switch from audits to insights. Defaults to existing audits
• v12.x (~June 2025): change the default from "audit mode" to "insight mode"
• v13 (~October 2025): remove the toggle and drop the original performance audits

If you have any questions of feedback, please add a comment here.

Related issue: #16323

[sardelich]

well.....first feedback I guess :D my site is fully http2 and http3 supported via cloudflare but I get modern http error and it seems that all page elements are loaded over http1.1 so its either lighthouse bug with new metrics or some weird cloudflare issue. but testing the webpage gives it a green on http2 :/

[PetrDedic]

Same issue with my site, but assets are served through Vercel DNS. For some reason, everything is shown as served through http/1.1, but I have checked Network tab and under Protocol column, everything is h2 or h3.

[connorjclark]

Thanks for the heads-up.

This issue is limited to PageSpeed Insights - we actually have some infrastructure limitations regarding accurate reporting of h1/h2/h3 for PSI. We had worked around that by disabling the original http2 audit, but didn't remember to do that for the new one.

So: you can ignore this insight when coming from PSI. I'll try to push a change soon to disable the insight audit in PSI until we can resolve the underlying issue.

[thebilalafsar]

Wow! This is a really great update—the only issue is that I’m seeing the HTTP error even though my site is fully supported with http2 and http3.

[masvil]

Same here, served through Cloudflare.

[connorjclark]

Thanks!

FYI I responded to the http thing here.

[webtrainingwheels]

Some of the language used on the new audits is much more developer-centric than before. Your tool is used by normal website owners, not just developers, so please don't alienate the average website owner even more.

Document request latency is more obtuse that "server response time"
forced reflow is worse than "layout shift"

Pagespeed insights is already hard for normal people to understand - please don't make it worse.

[tunetheweb]

Some of the language used on the new audits is much more developer-centric than before. Your tool is used by normal website owners, not just developers, so please don't alienate the average website owner even more.

Thanks for the feedback! Hopefully the documentation on these insights that we're working on will also help address this.

To specifically address the two examples you gave:

Document request latency is more obtuse that "server response time"

We will have a think about whether the audit name can be improved. However a key point is that "document request latency" is about more than just the "server response time". It also includes whether redirects were used, and lack of compression:

These both can also result in a slower download of that crucial initial HTML, in a very similar manner to the server being slow. Many people consider the "server response time" but don't think about those other parts—and they can often be the cause of the real issue, even if the server response time itself is reasonably fast.

Unlike individual audits, the insights attempt to group multiple similar pieces together, and this is a perfect example of that!

forced reflow is worse than "layout shift"

forced reflow is a new audit. And yes this one is quite technical in nature (more details on what exactly it is here), but basically it's about doing lots of layout calculations in JavaScript—even if it doesn't shift things about on screen.

So the "Layout shift culprits" audit still exists and is a separate thing.

But seems like we could do a better job on explaining this one to the more general audience who may not be familiar with that term.

Pagespeed insights is already hard for normal people to understand - please don't make it worse.

Do let us know if you have other examples like those two where you feel this is making it harder. But we are aiming to make it easier but grouping things together—rather than having a huge, long list of audits even when some are very related. I think those are good examples where we can make it clearer still, but that's the aim.

[mik3ca2]

I think the new audit is unfair.

I have a homepage that currently passes with flying colours (100% across the board). with the new insights, issues arise.

One issue it states is that I'm serving an oversized image in a small slot.

What I did was combine a couple of pictures together as one picture to minimize requests and used it as a CSS sprite. and despite it measuring my sprite with the correct dimensions, its claiming it can be optimized due to its "large size".

I did this deliberately because I'm using an HTTP/1.1 only server and I'm trying to minimize connection requests for pictures.

for reference, here's the sprite:

https://buy.ontariospeeddating.ca/r0/1/allvenues.jpg

and here's the website the sprite is loaded into:

https://buy.ontariospeeddating.ca/

If pagespeed continues this way, then the people (think baby boomers and gen-x) who don't have new computers that want websites that serve their needs won't be able to see them because google would hide them over these silly new "optimizations".