Bug 243424 - Media conditions don’t affect CSS loading priorities
Summary: Media conditions don’t affect CSS loading priorities
Status: RESOLVED DUPLICATE of bug 39455
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: Safari 15
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
Keywords: BrowserCompat, InRadar
Depends on:
Reported: 2022-08-01 13:37 PDT by Vadim Makeev
Modified: 2022-11-09 17:30 PST (History)
9 users (show)

See Also:

breakpoints demo (192.95 KB, application/zip)
2022-08-01 13:37 PDT, Vadim Makeev
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vadim Makeev 2022-08-01 13:37:47 PDT
Created attachment 461340 [details]
breakpoints demo

Imagine a simple situation, two CSS files linked in the head:

    <link rel="stylesheet" href="screen.css">
    <link rel="stylesheet" href="print.css" media="print">

Currently, WebKit will wait for both of them to be loaded before rendering anything at all. It makes sense since CSS is a render-blocking resource.

But the browser won’t use print.css for rendering because the implicit “screen” media type doesn’t match the “print” value. And it’s clear from the HTML parsing stage: this resource is not render-blocking.

Both Firefox and Chromium will keep loading print.css with lower priority and will start rendering once screen.css is available. It won’t save traffic but will make the page appear faster.

The same could be used not only for printing but for many different applications, that would make CSS performance better:

1. Color scheme: dark.css should not block rendering if the current scheme is light

<link rel="stylesheet" href="light.css" media="(prefers-color-scheme: light)">
<link rel="stylesheet" href="dark.css" media="(prefers-color-scheme: dark)">

2. It could be possible to split CSS into separate files based on breakpoints

<link rel="stylesheet" href="base.css">
<link rel="stylesheet" href="mobile.css" media="(max-width: 767px)">
<link rel="stylesheet" href="tablet.css" media="(min-width: 768px) and (max-width: 1023px)">
<link rel="stylesheet" href="desktop.css" media="(min-width: 1024px)">

3. It could be possible to offload some enhancements based on device properties or user preferences:

<link rel="stylesheet" href="retina.css" media="(min-resolution: 2dppx)">
<link rel="stylesheet" href="heavy.css" media="(prefers-reduced-data: no-preference)">
<link rel="stylesheet" href="animation.css" media="(prefers-reduced-motion: no-preference)">

Well, it’s currently possible, but not in WebKit.

Here’s the demo with breakpoints: https://pepelsbey.dev/pres/conditionally-adaptive/demo/

The same zipped demo is attached.

To make it easier to spot locally, I’d recommend using the slow-static-server:

    npx slow-static-server

And then

Comment 1 Radar WebKit Bug Importer 2022-08-01 19:02:57 PDT
Comment 2 Antti Koivisto 2022-08-02 07:58:22 PDT
Might be a worthwhile optimization. Do you know any real world sites that are affected?
Comment 3 Vadim Makeev 2022-08-02 08:48:20 PDT
(In reply to Antti Koivisto from comment #2)
> Do you know any real world sites that
> are affected?

There’s https://www.gov.uk/ website, for example. On the main page there are four CSS files linked, two of them with media="print":

    <link rel="stylesheet" media="print" href="https://www.gov.uk/assets/static/print-53da7f13c2fb1115b956c35ef5e0898aa48fd2e0457f82692fdf8d16ed2e2626.css">
    <link rel="stylesheet" href="/assets/frontend/print-4999bb4fdea0b565c697e98b104fb7bd59065c43de8ef05798bf71279618e981.css" media="print">

57 KB + 6 KB = 63 KB of styles that aren’t render-blocking.

In Chrome and Firefox, these are loaded with the Lowest priority and don’t block the rendering.
Comment 4 Karl Dubost 2022-08-30 16:18:34 PDT
Hey Vadim,
That looks like a duplicate or related to Bug 39455
Comment 5 Vadim Makeev 2022-08-30 16:43:36 PDT
Hi Karl :) Nice catch! Looks like the same issue to me. Feel free to close one in favor of another, whichever looks best for future work.
Comment 6 Maciej Stachowiak 2022-11-09 16:08:04 PST
Let’s dupe this to the older bug.
Comment 7 Ahmad Saleem 2022-11-09 17:30:46 PST

*** This bug has been marked as a duplicate of bug 39455 ***