Lighthouse within Chrome and CLI both time out on a website during blocked CSS testing phase

[mb0000]

Provide the steps to reproduce

1. Run LH on https://www.utoronto.ca

What is the current behaviour?

The testing phases during which images and CSS resources are loaded work fine, but when entering the phase where CSS and other resources are blocked, Chrome becomes very CPU intensive, the loading spinner in the tab is continuous and LH finally times out.

What is the expected behaviour?

For such a "mainstream" page, I'd have expected LH to cope with irregularities and to complete its audit tests successfully.

Environment Information

• Affected Channels: CLI & DevTools
• Lighthouse version: 7.2.0 (within Chrome) and 7.3.0 when using CLI
• Chrome version: 90.0.4430.72 (Official Build) snap (64-bit)
• Node.js version: 15.12.0
• Operating System: Ubuntu 20.04 LTS

Related issues When using CLI with --verbose, there are a very large number of CDP Network events showing blockedReason Inspector. Also, when using CLI (not headless, (headless or not does not change the behaviour)), the DevTools panel shows thousands of issues - only during LH audits for the given page.

[adamraine]

LH does not time out on my end, but it does take extremely long on the offline pass due to the massive amount of blocked request issues being made (>50000).

The problem appears to be this element:

<img class="site-logo-large" src="/sites/all/themes/uoft_stark/img/U-of-T-logo.svg" onerror="this.src = &quot;/sites/all/themes/uoft_stark/img/U-of-T-logo.png&quot;" type="image/svg+xml" alt="University of Toronto">

When the logo fails to fetch because it's blocked, it will set src to reference a png version. This png version also fails to fetch, so src is set again which appears to force another fetch even though the URL is the same.

This may be specific to how DT blocks requests so we should investigate.

That being said, there be more elegant methods to define a fallback image, perhaps <picture> would work?

[mb0000]

LH does not time out on my end, but it does take extremely long on the offline pass due to the massive amount of blocked request issues being made (>50000).

Did you adjust any timeout parameters? I assume not, as you haven't said so - just thought I'd check

The problem appears to be this element:

<img class="site-logo-large" src="/sites/all/themes/uoft_stark/img/U-of-T-logo.svg" onerror="this.src = &quot;/sites/all/themes/uoft_stark/img/U-of-T-logo.png&quot;" type="image/svg+xml" alt="University of Toronto">

When the logo fails to fetch because it's blocked, it will set src to reference a png version. This png version also fails to fetch, so src is set again which appears to force another fetch even though the URL is the same.

This may be specific to how DT blocks requests so we should investigate.

At the risk of exposing woeful ignorance, what's DT?

That being said, there be more elegant methods to define a fallback image, perhaps <picture> would work?

Obviously LH can't be designed to cater for every "broken" page. It's certainly helpful to have someone with better knowledge than mine look at this instance - thanks, Adam

[adamraine]

Did you adjust any timeout parameters? I assume not, as you haven't said so - just thought I'd check

Nope, default settings.

At the risk of exposing woeful ignorance, what's DT?

DevTools :)

[connorjclark]

+1 to using a picture element, that's exactly what's needed here. Let us know if Lighthouse finishes after making that change.

[mb0000]

Apart from my being slow to realise DT meant DevTools, I must confess that suggesting I have someone else change their website in order to simply allow Lighthouse to complete it's run seems a bit ridiculous. There are 1.7 billion websites out there - sure, Lighthouse can't be expected to work with every site, but given that the UofT site works fine as a user experience (I'm not commenting on UX - outside my sphere of interest / expertise), i.e. when not running LH, it seems to me to make sense that LH should do the work of working with "difficult" sites.

[patrickhulce]

@mb0000 we certainly make a best effort to ensure Lighthouse works for all sites, but there's only so much we can do when a page misbehaves (in this case causing an infinite loop and hanging Chrome when a single image fails to load, a very realistic real-world scenario). It was hit or miss whether Chrome actually froze on my machine, but I would say this behavior is WAI (if a page completely hangs the browser while trying to load it with 1 image blocked, that is useful information already) and what Lighthouse should do is more clearly communicate this page has such a severe audit failure that the browser becomes unusable :)

@connorjclark @adamraine we should fix the bug that Lighthouse can die with PROTOCOL__TIMEOUT while checking if the browser is hung which kinda defeats the point of the graceful fallback with a better error message ;)

[connorjclark]

website in order to simply allow Lighthouse to complete it's run seems a bit ridiculous

Agreed, but using picture element here instead of... whatever the site is doing, is better in every regard. It isn't just for Lighthouse.