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.

EDIT: this audit should now be hidden in PSI.

Note the workaround to disable the modern HTTP test from PageSpeed Insights rolled out a while ago so you shouldn't see any false positives for that now.

So I'm kinda a noob and developing on my own I got lighthouse running a cloud phone but not sure what it has accomplished.

Same here, served through Cloudflare.

Thanks!

FYI I responded to the http thing here.

Note the workaround to disable this particular test from PageSpeed Insights rolled out a while ago so you shouldn't see any false positives for that now.

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 by 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.

I'm not seeing an issue with images when testing this site with PageSpeed Insights. Do you still see the issue? Did you change something? Or perhaps we fixed this false alert on the Lighthouse side.

I can't tell if its lighthouse or if its servers because if a server is doing poorly then numbers would naturally be unfavorable regardless of if you use lighthouse or webpagetest.org

@dymoo I like numbers too. This info will certainly be added back here, thanks for bringing it up.

I literally logged in just to speak to this!

I don't just like numbers, I need numbers. Whether it passes or fails, I really need the exact response time measured, like audits currently does. This is a HUGE deal for sites with this issue. In order to tell if one is making headway on the issue or not, or are testing if a new server performs the same as the old ones etc., details are a must. Otherwise, I wouldn't know if I made any headway on the issue. Getting 3.2s vs later getting 1.8s is a big deal but I can't see that on this new Insights mode. No dumbing the UI down please!

Lighthouse 12.6.1 fixes this. It will roll out to PSI soon.

I think his point is that we have a nuance that we we don't flag pages with less than 6 resources (since HTTP/2 wouldn't really benefit the site in that case). And maybe that nuance should be expanded to also included pages that don't fetch more than 6 resources at once.

I don't think a change is necessary here as, as far as I know, Lighthouse only looks at in-flight resources for page load. So already excludes the lazy-loaded issue.

Plus if you're dancing that close to the edge, then I'm happy for Lighthouse to be a bit more proactive in suggesting HTTP/2. Like even in the lazy-loading example scrolling down quickly (or deep-linking down the page) then they could be hit with the issue.

Tunetheweb understands my idea, but this:

"Lighthouse only looks at in-flight resources for page load. So already excludes the lazy-loaded issue."

isn't accurate.

On one of my pages, I have 6 images loaded from the main HTML of which at least 1 is marked as lazy-loaded (loading=lazy set in the IMG tag). So that means 5 should be factored when determining the need for HTTP/2 because the 6th one wouldn't load until the user scrolls to it.

How far offscreen is the image? If it's within the threshold, then it may be downloaded anyway. Especially on throttled connections where the thresholds are even higher.

Some images are at least 1500 CSS pixels (DPR 1) away from the top. think regular desktop PCs.

That could easily be in-scope for mobile Lighthouse test which uses Slow 4G emulation as per the thresholds I linked above. It may even be that this triggers the HTTP warning for mobile test, but not for desktop.

Anyway, since this has not changed between the old audits, and the new insights-based audits, I think this is a getting a little off topic. I'd suggest you raise an issue if you want to discuss this further but if it's OK with you we'd like to keep this discussion on the move between the old audits and the insights.

If your page size is large, its more data that needs to be downloaded. More data to download would naturally result in reduced page loading speed, provided that you're using the exact same 100% reliable (preferably wired) internet connection setup everytime.
Your paragraph suggests to me that you're testing your webpages from different wifi hotspots where one month ago, you were on a slow internet connection and now today you're on a blazing fast internet connection.
You may want to use webpagetest.org to test your pages every month and use the exact same connection metrics (same upload speed, same download speed, and same latency) for all your tests. then you'll see what happens to speed.

I'm using pagespeed.web.dev, so it's a controlled test environment using Google's servers, not based on my connection or device. What I’m saying is that page size can keep creeping up even while loading speeds improve. You can optimise for speed, sure, with lazy loading, better server response, compression, but still end up with a bloated site. Perhaps because sometimes things really are being optimised for the tests and not user experience.

My own sites are tiny, so I rarely see much variation on PageSpeed/Lighthouse. It's always 100-100-100-100. The bigger concern is how this plays out at scale - larger, heavier pages can still impact user experience, especially on mobile, and contribute to the general problem of internet bloat and sustainability. The common solution of throwing more power at our connections, along every part of the chain, just isn't very efficient.

Hey Juan, yes there are some audits that will remain even after the switch to Insights as per the post:

The other Performance audits not included in the previous tables won't be affected by this change. Similarly, the audits for Accessibility, SEO, and Best Practices also won't be affected by this change.

In most cases these are audits that make less sense in the Performance Panel as they are either already covered in a different way (like bootup-time), or because they cannot be as easily replicated in a way that suits that platform (e.g. bfcache test), or because they are very Lighthouse-specific (e.g. the screenshot "audits").

For the main part however, we're aiming to keep these to the minimum and have parity as much as possible between Lighthouse and Performance Panel.

Are you preloading your CSS? That stops it from being a render-blocking resource.

link rel="preload" as="style" href="path/to/css.css" media="screen"
link rel="stylesheet" href="path/to/css.css" media="screen"

@monkeysdocode yes i tried that already but it broke the website unfortunately

Can you provide the site so we can check this out? It shouldn't be doing that.

Hey @FahemCH! With all due respect, how does your issue relate to this topic (i.e., Performance Insights Beta)? I would create a separate topic to prevent further confusion. Note: To solve your issue, use FlyingPress for caching, Perfmatters for performance optimization, and the recently-released 5-star plugin CompressX for image optimization and delivery. Our team uses all three. Our PSI and other performance tools scores are 98 (Mobile) and 100 (Desktop). You're welcome :)

@Generosus hello, thank you for your reply, to be honest i left everything as it is, because it consumed lot of my time, thanks again for the solutions you provided (i'll try them out in my future projects) 🫡

Thanks - I filed an internal issue and will provide an update here when we have one.

I am having very inaccurate and inconsistant results in performance. I am working on www.catalogoenlinea.shop and I have made several changes to the site, even removing images that were marked as the LCP (small webp image of 20k) and the metrics are always the same, it never changes.
Now that I have removed all images, the LPC it is supposed to be some text, which is quite incoherent.
At the same time, the LCP is informed at least 3 different times with 3 different measurements, and they are all ridiculous, informing at some pinto 4,7 sec, which is absolutelly impossible.
I have optimized it to the minimum, you can check just by yourself getting insede the website. It is a lightweight site, instant render, static site, it is impossible for it to take 4 seconds to load anything.
If you go to Chrome Inspector Tools Lighthouse, the performance is 99.
I am adding screenshots, and I hope you can fox this, because it affects Google metrics for indexing and search results. Thanks!

A lot of your JavaScript is third-party and blocking. If that is delivered slowly during a test, it's going to have a big impact on performance scores. So it's quite possible to see large variations in pagespeed.web.dev results.

For your real user experience, is your server located close to your visitors? What are the network connection speeds like for your visitors? Do your visitors tend to opt for budget phones or high-end phones? Are you on shared hosting with potentially quite variable server response times?

These are the kinds of factors that can differ dramatically between sites. And it's not something that testing with Lighthouse is going to give you a clear picture of.

For the UK-based site I linked to above, ~90% of UK visitors are using mobile phones. It has very, very few Chrome + Windows desktop visitors from the UK contributing to CrUX data. The majority of its desktop users are from the US, Australia, and New Zealand. This is making the desktop CrUX data look far worse than mobile, whereas you would expect it to be the other way around. That's not something that Lighthouse testing could pre-empt.

For your site, try to make the CSS non-blocking. Google Tag Manager's JavaScript is not doing the site's performance any favours either. Fix those two things, and you should see quite an improvement.

I've identified the issue, and it should be resolved in the next Lighthouse release (12.7). That should be in PSI by the end of the month.

https://crbug.com/416580500

Apologies for ignoring you. I agree the Insight seems to be over estimating the savings here (which is why it's failing this audit). We'll investigate why.

Thanks for the reply @tunetheweb

Hey Sean, sorry for not replying earlier. I think this may be resolved? We had some issues with network sizes being wrong (we accidentally were ignoring compression), which would cause an issue like what you saw.

Do you still have the URL that showed this issue?

Not the same url, but here is a new one using the same domain for the test: https://pagespeed.web.dev/analysis/https-fylgja-dev/8ei91stgqf?form_factor=mobile

I am still seeing a error, instead of a warning, for render blocking CSS.
So not sure if it is fixed @connorjclark

The image is preloaded without fetchpriority=high:

<link rel="preload" as="image" href="https://d1csarkz8obe9u.cloudfront.net/posterpreviews/blank-wanted-poster-template-design-37a9a451cb794713d8bba77bd3c0ca6f_screen.jpg?ts=1698190633">

So it initially starts as low until the <img> element is seen and it's upgraded. You should also add fetchpriority=high to the preload so it starts from high immediately.

The Insight could do a better job of making this clearer so I raised https://issues.chromium.org/issues/419817756 to track this.

Most of the audits have links to more information and we're also working on documenting the insights. However if there is a particular section that you think could benefit from more links then let us know.

Now there is going to be some point whether this does get technical unfortunately no matter how much we try to explain. And non-technical people may have to defer to their platform or other experts for a lot of this. However, the fact you're able to tell from a glance if there is a problem is a great first step! Even if the next step of how to actually fix it is a little harder...

Are you able to share your URL?

Link is here

I also have in my HTTP header output:
Link: <(url to LCP image)>;rel=preload;as=image;fetchpriority=high

You'd think I'd get brownie points for putting the Link in the HTTP header instead of the compressed HTML code because no decompression is needed to determine what image needs to be urgently loaded.

I'm not seeing a LCP request discovery issue for that site on PageSpeed Insights?:
https://pagespeed.web.dev/analysis/https-buy-ontariospeeddating-ca/1952lxfvi1?form_factor=mobile

Sometimes it shows an LCP issue but other times it doesn't. Your test shows it doesn't.
I just don't know why there should be one anyway when all major tests turn up as green (100%)

Your pagespeed insights suggests I should add "fetch-priority=high" but how does that work with data URI's

That's weird! We shouldn't do that. I created an issue here.

Yes we've noticed false positives with this "Server responded slowly" in some cases. We're investigating why this happens...

uh oh

re: the "Server responded slowly", I shared this in another thread on this page but FYI: we've since included the actual server response time here, and we fixed a bug that caused us to use the wrong time here.

EDIT: today (Oct 1) I found that there was still a bug with how the server response time was being reported for the new document latency insight audit. I've resolved it for Lighthouse v13.

Do you have any more specific feedback?

The name of what?

This is resolved for the next Lighthouse release. https://crbug.com/416580500

Hey Eric, so yeah there's nothing directly in the "LCP breakdown" insight that highlights what could be the cause of a high render delay. There's a few things it could be other than render blocking requests – long tasks blocking the main thread is probably the most common.

I created an issue for us to explore how this insight can better highlight where to look to further debug a high render delay (without resorting to docs).

Would you happen to still have a URL that presents a high render delay that you had trouble determining the cause of?

Hey Connor, thanks for the reply! I've been doing a ton of testing over the last month and we're getting somewhat different results now, but I'm happy to provide some examples. The main change we've made on this site is to eliminate all render blocking resources by inlining critical CSS and deferring everything else. We eliminated render blocking JS a couple years ago.

Here are a couple tests run in relative close proximity:

• https://pagespeed.web.dev/analysis/https-drreynoldsdev-wpenginepowered-com/y2e8yemwb9?form_factor=mobile
• https://pagespeed.web.dev/analysis/https-drreynoldsdev-wpenginepowered-com/w94nvd2oa0?form_factor=mobile

Subsequent tests can vary anywhere from low 60s to upper 90s. This is the case for most of our sites, even when removing all render blocking resources. A couple noteworthy observations:

• When viewing the first test in "audits" mode, the bulk of the LCP is in load delay, whereas in the second test it's almost entirely in render delay. This is typical of our tests post-optimization: LCP tends to still be long, but the reason jumps around from test-to-test. Prior to our elimination of all render blocking resources, render delay was the problem 99% of the time. It's like we're just shifting the issue elsewhere.
• In both tests, when viewing in "insights" mode, the "LCP breakdown" does not even come close to adding up to the total LCP time.
• Generally speaking, I expect LCP load time to vary based on network conditions. But I'd expect load delay and render delay to be fairly consistent. I'm not sure why they seem to vary so wildly.

My best theory for why we might be getting long load or render delay is because I'm using some kind of really expensive CSS property or something that ends up causing long or repeated layout calculations, but I haven't really been able to find a way to suss that out.

No impact on the performance score. That's always determined from just the metric results.

Thanks for the clarification!

@connorjclark or @tunetheweb any chance of getting your feedback on this conflict between network dependency warning vs LCP metric? Thanks! ☝️

I kinda agree that, due to display: swap this is no longer a "critical" chain. Plus, given the excellent LCP, a red "error" seems unnecessary and a warning at worst seems better.

Ultimately we definitely don't want to encourage things that make page load slower!

WDYT @connorjclark ?

I think, but don't remember the details, we might be able to detect how the font is being displayed (IIRC in other insights we do this). I'm not sure if it would tell us exactly if the font is display: swap, but we might be able to detect cases like this where the font is not critical and exclude them. But I will defer to @connorjclark for how feasible this is or not.

As we're only discussing the Performance insights for this discussion, could you raise a separate issue for that?

Done. Thank you.