Bug 243424

Summary:

Media conditions don’t affect CSS loading priorities

Product:

WebKit

Reporter:

Vadim Makeev <hi>

Component:

Page Loading

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED DUPLICATE

Severity:

Normal

CC:

achristensen, ahmad.saleem792, beidson, karlcow, koivisto, mjs, nicolas, simon.fraser, webkit-bug-importer

Priority:

Keywords:

BrowserCompat, InRadar

Version:

Safari 15

Hardware:

Unspecified

OS:

Unspecified

See Also:

https://bugs.webkit.org/show_bug.cgi?id=39455
https://bugs.webkit.org/show_bug.cgi?id=244154

Attachments:

Description	Flags
breakpoints demo	none

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

    http://localhost:8080/index.html

Comment 1 Radar WebKit Bug Importer 2022-08-01 19:02:57 PDT

<rdar://problem/97951015>

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