-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Review request on blocking=render
attribute for scripts and stylesheets
#727
Comments
How does the corresponding IDL attribute work? Would |
No. |
@cynthia and I took a look at this this week and we have some concerns about what user need this is actually serving? The explainer list a uses case of wanting to block on font loading, which can already be controlled via CSS, is generally considered a bad thing to do by the CSSWG, and usually leads to a very bad user experience. The other use cases seem somewhat questionable. This feature also goes against one of the TAG's design principles. Is there really a need to add more render blocking? |
Thanks for the review! My response is as follows:
CSS
I believe the other use cases are also as strong. For the second use case (script-inserted style & script): In practice many web developers struggle to properly pre-process their blocking style sheets and scripts, which is one reason CLS is quite common. This is especially true for individual, educational or indie developers, who don't have the resources to build & maintain fancy server-side templating and serving systems. The linked educational example is one such example, which is served from raw sources without any build step, has many constituent pages, and a loader script to avoid duplication of common resources (& corresponding mistakes) across these pages. There is no advantage at all to the multi-render progressive loading for this site, it just looks jarring and ugly. For the third use case (async script),
The principle allows adding such features “only in cases when the overall user experience is improved”, which I believe is exactly the case for |
Bumping this issue until Sangwhan is available, IIRC some of his concerns were about how this feature can be abused (either intentionally or unintentionally) causing significant delays for users on slow connections or who need to download very large resources (like CKJ fonts) that the page author may not take into consideration. |
Regarding the concern:
|
Hi TAG, Due to whatwg/html#7896, we have removed |
blocking=render
attribute for scripts, stylesheets and link resourcesblocking=render
attribute for scripts and stylesheets
Friendly ping, as this now has a pending intent :) |
We're OK with adding this to script tags as that usage can be interpreted as adding the ability to add async processing to already blocking scripts, so this is an enhancement. However, we still have concerns about adding additional blocking to stylesheets, particularly for the purpose of blocking on font loading (and as @cynthia mentioned, CKJ fonts can be large and connections can be slow). In the past webkit blocked for up to 30 seconds on webfont loading and the user experience was horrible. CSS added mechanisms to control rendering with webfonts, adding an additional mechanism to achieve this seems bad. |
Thanks for the review!
Adding this to stylesheets will not block page rendering on web font loading. It will only block on critical subresources, which is currently underdefined, but so far no implementation includes web fonts as critical subresources. We are indeed pursuing CSS-based approaches to for rendering control with web fonts, which however should be orthogonal to this |
Thanks for the response, we're going to close this review as satisfied, but we still have some concerns. Mainly, new mechanisms to block rendering need to be used very carefully by developers or they can easily fall into traps that result in a worse user experience (e.g. not realizing how slow user's devices and connections may be in the wild), so developers need to tread very carefully when using this and the additional complexity needs to be carefully explained. Furthermore, some of the use cases seem to be replicating existing capabilities that would be better handled declaratively. For example, using script to inject links to stylesheets in certain situations should rather be handled by CSS mechanisms like feature and media queries so the UA can scan for preloading opportunities, handling is not gated by script execution, etc. We do like the possible future extensions of being able to relax blocking in situation that are currently blocking. |
Braw mornin' TAG!
Edit: This feature now affects scripts and stylesheets only. The behavior on preloads have been removed due to whatwg/html#7896.
I'm requesting a TAG review of
blocking=render
attribute for scripts and stylesheetsand link resources.All current browsers already have a render-blocking mechanism: after a navigation, the user agent will not render any pixel to the screen before stylesheets and synchronous scripts are loaded and evaluated (or a UA-defined timeout is reached), to prevent a Flash of Unstyled Content and ensure that critical scripts are evaluated. We extend this idea by introducing the
blocking=render
attribute, which can explicitly mark other resources (script
,style
andlink
of typesmodulepreload
,preload
andstylesheet
) as render-blocking, so that a flash of undesired contents can be prevented in more use cases (see explainer).blocking="render"
attribute on <link>, <script> and <style> whatwg/html#7131Further details:
We'd prefer the TAG provide feedback as (please delete all but the desired option):
💬 leave review feedback as a comment in this issue and @-notify xiaochengh@
The text was updated successfully, but these errors were encountered: