Closed xiaochengh closed 7 months ago
foolip
commented
10 months ago From State of HTML preliminary results, blocking="render" was among the features that respondents expressed the most interest for. Note that this wasn't freeform, it's based on the features the survey asked about experience and sentiment for.
LeaVerou
commented
10 months ago From State of HTML preliminary results,
blocking="render"was among the features that respondents expressed the most interest for. Note that this wasn't freeform, it's based on the features the survey asked about experience and sentiment for.
It was actually about halfway: that graph only shows main features which had corresponding Interop 2024 proposals. I just checked the numbers for overall ranking, and it was 22nd, among 42 main features.
Here’s some more data:
14355 respondents responded about their experience with blocking="render", broken down to:
nairnandu
commented
7 months ago Thank you for proposing blocking="render" attribute on scripts and style sheets for inclusion in Interop 2024.
We wanted to let you know that this proposal was not selected to be part of Interop 2024. This is because we got many more proposals than we could include in this year's project. Note that individual vendors may nevertheless choose to advance work in this area during the forthcoming year. We would welcome this proposal being resubmitted again next year, if necessary.
For an overview of our process, see proposal selection. Thank you again for contributing to Interop 2024!
Posted on behalf of the Interop team.
Description
Putting 'blocking=render' as an attribute and value to a
<script>,<style>or stylesheet<link>makes it explicitly render-blocking. The main usage is to avoid a flash of unstyled content or user interactions with an immature page caused by script-inserted scripts/stylesheets, client-side A/B testing and etc.Specification
https://html.spec.whatwg.org/#blocking-attributes
Open Issues
No response
Tests
https://wpt.fyi/results/html/dom/render-blocking, except
document-render-blocking-*.htmlwhich are for document render blocking.Current Implementations
Standards Positions
Gecko: No signal (but maybe interested?) https://github.com/mozilla/standards-positions/issues/608
WebKit: No signal https://lists.webkit.org/pipermail/webkit-dev/2022-January/032088.html
Browser bug reports
No response
Developer discussions
Client-side A/B testing defacto standard across the web works today by inserting a parser blocking script into the HEAD of the document, which applies a style to the document to hide it from being rendered, prior to A/B modification having taken place. This is a significant negative impact to LCP and page performance/vitals, due to both the parser-blocking script implementation, and the page being hidden until script has had a chance to apply changes. If the A/B script can be deployed as non-parser-blocking, but render-blocking, it will result in better performance for pages employing client A/B testing today.
However, this feature is difficult to roll out to current A/B testing implementation since a fallback isn’t available. Since scripts are embedded by clients during integration time, A/B providers cannot verify platform feature availability per request. Deploying this attribute without a fallback can result in a broken experience (Flash of unstyled/non-Ab tested content) in unsupported browsers.
If available across all major browsers, A/B vendors could rely on this attribute with minimal breakage and convert parser-blocking A/B scripts into render-blocking instead.
Polls & Surveys
No response
Existing Usage
0.03% as of Sep 2023. https://chromestatus.com/metrics/feature/timeline/popularity/4183
Workarounds
A polyfill may set
display: noneon the root element and remove it when all the resources that should block rendering are loaded, potentially with a lot of issues. See the developer discussions for details.Accessibility Impact
No response
Privacy Impact
No response
Other
No response