[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 (released Apr 30): display a toggle in the Performance section to switch from audits to insights. Defaults to existing audits
• v12.7.0 (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.

EDIT: this audit should now be hidden in PSI.

[tunetheweb]

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.

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

[tunetheweb]

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.

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

[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".

[tunetheweb]

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.

[dymoo]

Dumbing the UI down is never good, my initial server response time went from 1.2s to just 'server responded slowly'...? I like numbers.

[mik3ca2]

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

[connorjclark]

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

[MacHeritage]

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!

[connorjclark]

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

[mik3ca2]

I think the HTTP/2 suggestion can be improved.

Looking through the insights code, it suggests that it flags a page if it has 6 or more static resources via HTTP/1.1, but it does not factor how they are loaded.

Picture this:
If a website had one picture above the fold,
20 pictures are 2 pages down and off-screen (must scroll to see),
Everything was served over HTTP/1.1
All pictures were set to be lazily loaded

That shouldn't be flagged, because only 2 resources are immediately needed: the HTML page itself, and the 1 picture above the fold. It would take the user to scroll to load the remaining pictures.

[tunetheweb]

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.

[mik3ca2]

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.

[tunetheweb]

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.

[mik3ca2]

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

[tunetheweb]

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.

[codewordcreative]

A bit more emphasis on and perhaps accurate tracking of page size (network activity can sometimes be a lot more) would be great. We are currently seeing a month-on-month increase in page size despite a month-on-month increase in page loading speed. An excessive focus on speed may cause people to be cavalier about something that can be a source of instability and poor user experience.

Related, I'm starting to wonder if Lighthouse needs to adapt its metrics a little. The real-life user experience can vary enormously between a site that scores 93-100-100-100 and one that scores 100-100-100-100. Meanwhile, the difference between something in the 70s and high 80s or even low 90s is often not so tangible.

I love the general direction of these insights. It gives people things to improve even when they are getting top results. It's also good to focus more on standards and quality in light of the general internet bloat. I can see this applying good, subtle pressure on organisations to up their game a bit. Nice work.

[mik3ca2]

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.

[codewordcreative]

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.

[juanferreras]

Once v13 (~October 2025) releases – will it show exactly what PageSpeed Insights shows today when toggled in Insight Mode? E.g. all the audits with id ending in -insight, and all the diagnostics that are not mentioned in any audits' replacesAudits[] array?

When reading the blog posts I thought only the new insights would remain, but after reading the code I understand that, for example, bootup-time (Reduce JavaScript execution time), would still remain as-is in Lighthouse v13.

[tunetheweb]

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.

[FahemCH]

Hello lighthouse and thank you for this exchange

I have a recurring issue with image optimization. for example, I had an image that was originally 88kb. PageSpeed suggested compressing it to 60 kb. Great I did that. But after retesting, it suggested compressing it further to around 35 kb. I compressed it again, but it didn’t stop there!! next suggestion was 9kb. every time I optimize, it keeps flagging the image and asking for more compression, without any clear "endpoint" 🙄 (the same problem for every image on the website)

The problem is that each time I compress further, the image loses more quality (especially if the image is the image of the CEO XD), and I don't know when I’ve “done enough to satisfy the tool". we can't just keep squeezing quality forever. speed is important, but so is the look of the site.. especially when the site is already fast. it would be great if there were clearer guidelines or a point where page speed acknowledges "good enough" 🫡

---

Secondo, i’m using a wordpress block theme, and i noticed page speed always flags the navigation and cover blocks (which are default core blocks) under render blocking requests and network dependency tree issues to test, i completely removed those blocks and just used my own custom min.css which is super lightweight.. only 4.7kb minified, and it’s the only css file i’m using now for the whole website to run far a way from "Network dependency tree" as much as i can. even with that, it still flags it under both categories. the other day it flags even a file with .9kb!!!!!!!!!!!

Honestly, i’m wondering.. do you want us to stop using css completely? 😅😅 because i don’t see how i can possibly get lighter than that without turning the whole site into plain html! 🤔

---

Lastly also, for LCP by phase flag “each phase has specific improvement strategies…”, it always flags the logo (an svg in my case) as the LCP by phase. maybe you could exclude typical logos from this check 🤗 since 99% of websites have their first image as a logo i think.

If you fix the first two issues at least i will thank you forever, anyway iam thanking you in advance for reeding this comment, good luck and have mercy on us (developers) i spend more hours to fix google page speed insights instead of building other websites 😭

[monkeysdocode]

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"

[FahemCH]

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

[tunetheweb]

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

[Generosus]

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 :)

[FahemCH]

@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) 🫡

[monkeysdocode]

A great addition, but there may be a small issue with the tool recognising all types of responsive images.

The corresponding HTML uses picture -> source elements with media queries. For a Moto G4 size screen, the browser should choose the appropriate image size based on the 'sizes' attribute and image widths listed in the 'srcset' attribute, whilst accounting for the display pixel density.

It seems that the Insights tool is only accounting for the displayed dimensions (399x300) and not screen pixel density.

The existing Lighthouse audit does seem to get this right - or at least it never throws a warning for mobile image sizes.

Link to the site in question: https://creativetouchrotherham.co.uk/

[connorjclark]

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

[Roma-it]

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!

[monkeysdocode]

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.

[connorjclark]

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

[GrimLink]

While the improved user experience and clear explanation are appreciated,
I have a concern regarding the Lighthouse Insights.

Why is a render-blocking CSS resource now flagged as an error on a site scoring 100?

Previously, this was often a warning, and as I understand it, CSS is inherently render-blocking.

I've consistently explained to developers and merchants that this isn't necessarily an issue if the CSS is necessary and efficiently sized.

This new error classification feels problematic to me,
suggesting a persistent issue regardless of CSS optimization.

Audit	Insights

[GrimLink]

@connorjclark and @tunetheweb I am one of the comments being ignored here 😞
Will one of you pick this up or can you give me a good reason for this change.

[mik3ca2]

you could transfer some of the CSS into CSS generated from within javascript and embed that entire code near the bottom of the HTML, provided the CSS code doesn't change element positions.

[tunetheweb]

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.

[GrimLink]

Thanks for the reply @tunetheweb

[hashim-pmw]

It complains about fetchpriority="high" not being applied even when it is.
Website link where this error occurs: https://www.postermywall.com/index.php/art/template/37a9a451cb794713d8bba77bd3c0ca6f/blank-wanted-poster-template-design

[tunetheweb]

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.

[Website-Doctor]

I use the https://pagespeed.web.dev/ website to test websites and pages and most of the time the numbers I can achieve are in the Green but I do have a life outside creating websites and it would be good if there was more explanation / links. When there is a problem I struggle to understand what I should do to improve the score. Please think of those who are interested in creating better websites but are not experts in every topic.

[tunetheweb]

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

[mik3ca2]

I got an LCP request discovery issue where I think I shouldn't.

On my website, what generates the LCP is a background image generated in-line from a data URI, and that generation is in a javascript tag right after the HTML body tag. Your pagespeed insights suggests I should add "fetch-priority=high" but how does that work with data URI's and why would that be needed if the image can be pulled from the HTML itself. Also, the data URI is within the first 20K of code (uncompressed).

[tunetheweb]

Are you able to share your URL?

[mik3ca2]

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.

[tunetheweb]

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

[mik3ca2]

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%)

[mik3ca2]

I ran my site again through page speed insights and the stats are awfully confusing. What I show here is the desktop results. It states the LCP element loaded in 0.3 seconds (same time as FCP). It also states Speed index is 0.9 seconds. However, the new stat "Document request latency" goes red claiming the response was served slowly. How is that claim true when pretty much everything loaded in 0.3 seconds and the rest of the indicators are green?

I also did manage to get the reported TTFB value through the pagespeed API which is roughly 160mS (which is below the 800mS threshhold).

So now I'm completely lost.

[tunetheweb]

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

[web-software-developer]

What about Fake Spoof PageSpeed Performance and Core Web Vitals?

There are many Agencies, Developer, Persons, Apps & Plugins are providing Fake Spoof PageSpeed score by bypass actual speed result and showing false score. They are just SPOOF the scores by server side code and client side code. The result will be websites face Bad User Experience, Less Conversions, No Trustworthy, Consumes server resources, ruin SEO/AI SEO and ruin every efforts of website owners.

Ultimately, it will loss of website's owners.

This is a pernicious Scam that impacts every website's owner and industry.

[benschwarz]

To be 100% clear, the way these hacks work is to detect lighthouse, then offer a faster code path (e.g. load less things, or have hidden/obstructed elements that paint quickly etc). To my knowledge, no one is "faking" or "spoofing" by bypassing the actual speed result and displaying a false score. The score is calculated based on the observed metrics — the hacks work by gaming the metrics used for the overall performance score.

To clarify on some points:

• "Core Web Vitals" by definition are not recorded by Lighthouse, but instead Chrome Browser (surfaced publicly the Chrome User Experience Report). Lighthouse records "Web Vitals".
• "Core Web Vitals" are used as a page ranking signal, but "Web Vitals" (from Lighthouse & PageSpeed) are not ranking signals.

This is a pernicious Scam that impacts every website's owner and industry.

This is inaccurate. The ruse here is that some website owners are using plugins (e.g. in the shopify, wordpress plugin ecosystem) that claim to increase page speed. Some plugins have legitimate performance improvements, and some rely on hacks. However, this certainly does not impact "every website's owner".

If you are wanting to see Google's assessment of website performance, look at CrUX data — you can do so using this free Core Web Vitals test tool (Full disclosure: I built this tool & own this company).

If your website doesn't have enough traffic to have data in the CrUX dataset, then it can be helpful to use Lighthouse or other synthetic page speed testing to audit performance.

As a technical expert @website-speed-expert, you will need to stay vigilant to detect plugins using these aforementioned hacks. I agree that this is not an ideal situation, however I also believe that website marketplaces (like Shopify and Wordpress) need to apply some standards to their marketplaces, as they're profiting from misdirection on customers.

It's a difficult spot, but there isn't much that can be done by the Lighthouse team to circumvent this abuse. If you have genuine recommendations or ideas, please start a new thread to discuss.

[web-software-developer]

I've seen reviews written on people's websites themselves which may or may not be scam, but website scores? just wow. Perhaps what the Lighthouse team could do is allow iframe embedding of website score into the website itself so that every hour a webpage is visited, people are connected to the lighthouse website to get the true pagespeed scores.

Btw, where did you find such spoof scores anyway?

You can see here:
https://performance.shopify.com/blogs/blog/don-t-get-scammed-by-fake-performance-experts-and-apps

and many more...

[web-software-developer]

This is a pernicious Scam that impacts every website's owner and industry.

"every website's owner and industry" means which are getting fake spoof page speed score,

[masvil]

Btw, where did you find such spoof scores anyway?

We had a drama with WP-Optimize WordPress plugin having an option to cheat PageSpeed scores based on user-agent/browser. The story

[web-software-developer]

Yes, cheat PageSpeed scores based on user-agent/browser.

[mik3ca2]

POSSIBLE BUG

I updated my website so it loads fresh stats after loading the entire page. Now the new lighthouse audit complains about a network dependency tree which I think is a bug.

So I rolled off simple HTML code to showcase what I'm trying to achieve.
Click here to view it as text

When running it through Pagespeed Insights, it mentions the same URL twice in its complaint.

So why does it claim I'm chaining requests when:

1. I specifically marked the script as async, and
2. I specifically set the 3rd parameter to true to the XMLHttprequest open method to force an async operation?

[connorjclark]

This is WAI.

This audit shows the dependency chain for a page's most critical resources. If a resource is needed for rendering the main content, it ideally should be preloaded or discoverable by the main document declaratively - this means via image element, or script src, or link tag, etc. In this example, the browser has to run the script to know that a XML http request is needed, which is why it shows here as a dependency chain.

The linked documentation will explain further.

[OrionInfo]

I use https://pagespeed.web.dev/ website to test my website and pages and most of the time the numbers I can achieve index page are in the Green in Desktop but I do have a life outside creating websites and it would be good if there was more explanation / links. When there is a problem I struggle to understand what I should do to improve the score in mobile. Please think of those who are interested in creating better websites but are not experts in every topic.

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

https://www.orioninfosolutions.com/

[michalc]

Hello! Thanks for a great tool - Lighthouse/PageSpeed insights have been very helpful (and for a good few years now I think)

Am trying the newish "insights", but I'm wondering: should the level(s) for the warning on DOM size be tweaked a bit? On https://delivervaluedaily.dev/ I get a warning with 141 elements, a node with 35 children, and DOM depth of 6:

I can't help but suspect only the most trivial of pages would not show this warning, and at least in this case, techniques to decrease DOM size feel somehow unjustified - I would class it as a really simple page.

Or if not tweaked, maybe document what the limits are? The warning seems to be showing at much lower limits than described at https://developer.chrome.com/docs/lighthouse/performance/dom-size/?utm_source=lighthouse&utm_medium=lr

But oddly, the warning doesn't happen every time.

Also, sometimes there is an "[unattributed]" Forced reflow warning, but odd because there is no Javascript in the page

Edit: I have now added a bit more to the page, so the numbers above are now slightly higher when running the test

[connorjclark]

Thanks for the feedback! totally agree. I've begun discussions about how to resolve this - you can track the issue here: http://crbug.com/425710510

[masvil]

Also, sometimes there is an "[unattributed]" Forced reflow warning

The same is happening to me on several pages, similar framework. Example. Let me know if you need more examples.
Any chance to have this insight more descriptive than "[unattributed]"?

I'm commenting because the issue linked by @connorjclark doesn't seem to cover this too.

[connorjclark]

The DOM size part of this should be resolved for the next Lighthouse release.

Sorry I missed the reflow part. I'll address it in two parts:

1. Seeing a forced reflow w/ no JS on the page is unexpected. I couldn't reproduce that–if you see it again @michalc could you please export a trace for us to debug?
2. I'm trying to get to the bottom of "unattributed" in general. It may be unavoidable due to attribution being somewhat based on heuristics, but perhaps it's a fixable hole in our instrumentation.

bug: https://crbug.com/428015268

[michalc]

@connorjclark

On the DOM size - thank you!

On the reflow thing, I have seen it a few times since, including just a few minutes ago (e.g. from the below screenshot). But: only when using https://pagespeed.web.dev/ and never locally from Lighthouse in Chrome (so a trace from my local machine I suspect won't give much)

The only thing that's crossing my mind - something to do with fonts and/or emojis? As it goes through the font stack and finds available font(s), could that essentially be doing something reflow-y?

[thadeu220v]

hi there, to be honest i did not liked the new insights experience. i definitelly prefer the audits version because the insights does not give data savings hints, not even the ammount spend on each task, as the audits does. and to be honest i really would like to have the audits mode not deactivated. cause i preffer the things as is

[connorjclark]

Can you explain what you mean by "data saving hints"?

[Generosus]

Overall Assessment:

Insights -- if implemented -- is going to permanently disrupt the internet ecosystem, annoy many people, and steer the majority towards using website performance tools other than PageSpeed Insights. Performance Audits works well for everybody. It took countless years to learn and adapt to it. "If it ain't broke, don't fix it."

To assist with your decision-making process, why not release a poll to gather the necessary go/no-go votes? Do it "Elon Musk" style. It works well.

Thanks for reading!

[connorjclark]

Do you have any more specific feedback?

[cyrilsxxx]

The name of the new version is more difficult for me to understand than the old version. At least I knew the cause and solution in the old version, but the new version leaves me at a loss.

[connorjclark]

The name of what?

[paul-muckypuddle]

I seem to be having issues with 'Improve image delivery' - in mobile mode, it's highlighting picture elements with sources and a base img tag that are deliberately double width / double height for 2x DPI screens, claiming the image is (exactly double) the dimensions. See https://share.muckypuddle.com/6qup655A, and the correspoding element:

<picture class="d-block">
    <source media="(min-width: 1400px)" srcset="//REDACTED/cdn/shop/files/BNR-DESKTOP-MAIN-BANNER_02_1600x.jpg?v=1747136814 1x, //REDACTED/cdn/shop/files/BNR-DESKTOP-MAIN-BANNER_02_1600x@2x.jpg?v=1747136814 2x"><source media="(min-width: 1200px)" srcset="//REDACTED/cdn/shop/files/BNR-DESKTOP-MAIN-BANNER_02_1400x.jpg?v=1747136814 1x, //REDACTED/cdn/shop/files/BNR-DESKTOP-MAIN-BANNER_02_1400x@2x.jpg?v=1747136814 2x"><source media="(min-width: 992px)" srcset="//REDACTED/cdn/shop/files/BNR-DESKTOP-MAIN-BANNER_02_1200x.jpg?v=1747136814 1x, //REDACTED/cdn/shop/files/BNR-DESKTOP-MAIN-BANNER_02_1200x@2x.jpg?v=1747136814 2x"><source media="(min-width: 768px)" srcset="//REDACTED/cdn/shop/files/BNR-DESKTOP-MAIN-BANNER_02_992x.jpg?v=1747136814 1x, //REDACTED/cdn/shop/files/BNR-DESKTOP-MAIN-BANNER_02_992x@2x.jpg?v=1747136814 2x"><source media="(min-width: 576px)" srcset="//REDACTED/cdn/shop/files/BNR-MOBILE-MAIN_BANNER_768x.jpg?v=1747136814 1x, //REDACTED/cdn/shop/files/BNR-MOBILE-MAIN_BANNER_768x@2x.jpg?v=1747136814 2x">
    <img src="//REDACTED/cdn/shop/files/BNR-MOBILE-MAIN_BANNER_412x.jpg?v=1747136814" srcset="//REDACTED/cdn/shop/files/BNR-MOBILE-MAIN_BANNER_412x.jpg?v=1747136814 1x, //REDACTED/cdn/shop/files/BNR-MOBILE-MAIN_BANNER_412x@2x.jpg?v=1747136814 2x, //REDACTED/cdn/shop/files/BNR-MOBILE-MAIN_BANNER_412x@3x.jpg?v=1747136814 3x" loading="lazy" class=" img-fluid " alt="">
  </picture>

[connorjclark]

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

[eric-michel]

I would love to get more insight regarding what resources are causing the render delay phase of LCP. We regularly get very high LCP scores that have 80-90% of their duration in the render delay phase. That number doesn't necessarily correspond in any meaningful way to the estimated time of the Render blocking requests. Sometimes it's significantly higher, sometimes significantly lower.

I have tried using Chrome devtools to give me a waterfall graph so In diagnose the issue, but even when I set the CPU and network throttling to match Lighthouse, I can't ever seem to recreate the long LCP times. I regularly get ~half of the LCP in Chrome.

Getting either a waterfall graph or just a list of resources causing the render delay would be incredibly helpful!