Print stylesheet picked for "Reduce unused CSS"

[aarfing]

FAQ

• Yes, my issue is not about variability or throttling.
• Yes, my issue is not about a specific accessibility audit (file with axe-core instead).

URL

https://tv2.dk

What happened?

Taking the lighthouse test here or in Chrome, results in our print stylesheet being 'tagged' as unused CSS.

What did you expect?

As stylesheets with media="print" are considered non-renderblocking - and browsers are free to delay load of them untill needed - it seems wrong, that they are treated as "reducedable". Print-stylesheets should not impact performance, as I see it - but I might be wrong, though.

What have you tried?

Running the same test on https://www.smashingmagazine.com/ which also has a print-stylesheet doesn't give the same result - ie. the print css is excluded from the "Reduce unused CSS" results.

How were you running Lighthouse?

Chrome DevTools

Lighthouse Version

8.4.0

Chrome Version

95

Node Version

No response

OS

Mac

Relevant log output

No response

[connorjclark]

Thanks for the report! totally agree that we should not be flagging print stylesheets here.

Unfortunately the CDT protocol does not tell us the media attribute for a given stylesheet
(

lighthouse/lighthouse-core/gather/gatherers/css-usage.js

Line 66 in 36b2106

session.off('CSS.styleSheetAdded', this._onStylesheetAdded);

/ https://chromedevtools.github.io/devtools-protocol/tot/CSS/#type-CSSStyleSheetHeader ). That's not a huge barrier as we can just query document.styleSheets for sheets with a truthy href (ignores internal styles) and media.mediaText. Ignoring the print sheets in CSSUsage is possible in this manner.

It get's tricky when you consider the more complex values for the media attribute. Example:

media="print and (max-width: 10em)"

This is how it looks in document.styleSheets:

I'd expect us to ignore this too. Also, we should ignore stylesheets like (max-width: 10em) that don't match the loading conditions (I assume these are always not-render blocking). But I'm not sure how to determine over the protocol / via the page if a given stylesheet is applicable ... given my browser is wider than 10em, and I'm not currently printing, I hoped that disabled would be set to true, but apparently that's unrelated to the media conditions.

Of course we could parse the media attribute and do a bunch of shenanigans to determine applicability, but it is not trivial (see https://www.w3schools.com/tags/att_link_media.asp).

Maybe we can look at the trace to determine if the stylesheets were loaded as render blocking requests (#2065 (comment)). Circumvents the complexity and uses what we care about directly: ignoring the CSS if reducing it wouldn't reduce the amount of render blocking bytes.

[brendankenny]

Blocking render isn't the only downside, though. A low(est) priority stylesheet can still interfere with downloading other more important resources that are triggered or discovered after the download for the stylesheet has begun.

IOW, the audit isn't just a measure of unused bytes; it attempts to only report on unused bytes that Lighthouse believes are competing with bytes that are used.

Running the same test on https://www.smashingmagazine.com/ which also has a print-stylesheet doesn't give the same result - ie. the print css is excluded from the "Reduce unused CSS" results.

One big difference is that smashingmagazine has it at the bottom of their HTML. That reduces the likelihood of network contention with other resources declared in the page and is likely why it's not showing up in the report.

[brendankenny]

Also FWIW the reports I get have "Reduce unused CSS" under Passed audits for your site.

This run, for instance, does mention that all of the print style sheet could be saved because it isn't used, but doing so would only have saved something like 30ms of the overall load, so isn't worth bringing up and so it's placed under "Passed audits". I see the same thing in reports from web.dev/measure

[paulirish]

While we could specifically omit print stylesheets from this audit, it is still downloaded. So we think it's worthwhile to continue to flag. It's up to you if you want to take action on it.