mirror of
https://git.sr.ht/~seirdy/seirdy.one
synced 2024-11-10 00:12:09 +00:00
Introduce css containment for deferring rendering
As alternative to lazy loading.
This commit is contained in:
parent
c21a21ea99
commit
a5b8b5acc9
2 changed files with 49 additions and 6 deletions
|
@ -162,10 +162,6 @@ Users on poor connections have better things to do than idly wait for pages to l
|
|||
|
||||
Unfortunately, pages with lazy loading don't finish loading off-screen images in the background. To load this content ahead of time, users need to switch to the loading page and slowly scroll to the bottom to ensure that all the important content appears on-screen and starts loading. Website owners shouldn't expect users to have to jump through these ridiculous hoops.
|
||||
|
||||
A similar attribute that I *do* recommend is the "decoding" attribute. I typically use `decoding="async"` so that image decoding can be deferred.
|
||||
|
||||
=> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Img#attr-decoding <img> decoding on MDN
|
||||
|
||||
### Would pre-loading or pre-fetching solve the issues with lazy-loading?
|
||||
|
||||
Pre-loading essential resources is fine, but speculatively pre-loading content that the user may or may not request isn’t.
|
||||
|
@ -197,6 +193,25 @@ A hybrid between the two is paginated content in which users click a "load next
|
|||
|
||||
I've discussed loading pages in the background, but what about saving a page offline (e.g. with Ctrl + s)? While lazy-loading won't interfere with the ability to save a complete page offline, some of these related issues can. Excessive pagination and inline scrolling make it impossible to download a complete page without manually scrolling or following pagination links to the end.
|
||||
|
||||
### Other ways to defer content
|
||||
|
||||
Deferring network requests is a bad idea, but there are other ways to improve large-page performance.
|
||||
|
||||
A similar image attribute that I *do* recommend is the "decoding" attribute. I typically use `decoding="async"` so that image decoding can be deferred.
|
||||
|
||||
=> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Img#attr-decoding <img> decoding on MDN
|
||||
|
||||
Long pages with many DOM nodes may benefit from CSS containment, a more recently-adopted part of the CSS spec.
|
||||
|
||||
CSS containment allows authors to isolate sub-trees of the DOM. When combined with a property like "content-visibility", it enables browsers to defer rendering of less essential below-the-fold content. Try to avoid the "hidden" parameter when "auto" is better:
|
||||
|
||||
> content-visibility: auto is a more complex value than hidden; rather than being similar to display: none, it adaptively hides/displays an element’s contents as they become relevant to the user. It also doesn’t hide its skipped contents from the user agent, so screen readers, find-in-page, and other tools can still interact with it.
|
||||
|
||||
=> https://drafts.csswg.org/css-contain/#using-cv-auto CSS Containment Module
|
||||
|
||||
Leveraging containment is a progressive enhancement, so there aren't any serious implications for older browsers.
|
||||
|
||||
|
||||
## Beyond alt-text
|
||||
|
||||
Expect some readers to have images disabled or unloaded. Examples include:
|
||||
|
|
|
@ -185,8 +185,6 @@ Users on poor connections have better things to do than idly wait for pages to l
|
|||
|
||||
Unfortunately, pages with lazy loading don't finish loading off-screen images in the background. To load this content ahead of time, users need to switch to the loading page and slowly scroll to the bottom to ensure that all the important content appears on-screen and starts loading. Website owners shouldn't expect users to have to jump through these ridiculous hoops.
|
||||
|
||||
A similar attribute that I _do_ recommend is the [`decoding`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Img#attr-decoding) attribute. I typically use `decoding="async"` so that image decoding can be deferred.
|
||||
|
||||
### Would pre-loading or pre-fetching solve the issues with lazy-loading?
|
||||
|
||||
Pre-loading essential resources is fine, but speculatively pre-loading content that the user may or may not request isn't.
|
||||
|
@ -216,6 +214,35 @@ A hybrid between the two is paginated content in which users click a "load next
|
|||
|
||||
I've discussed loading pages in the background, but what about saving a page offline (e.g. with <kbd>Ctrl</kbd> + <kbd>s</kbd>)? While lazy-loading won't interfere with the ability to save a complete page offline, some of these related issues can. Excessive pagination and inline scrolling make it impossible to download a complete page without manually scrolling or following pagination links to the end.
|
||||
|
||||
### Other ways to defer content
|
||||
|
||||
Deferring network requests is a bad idea, but there are other ways to improve large-page performance.
|
||||
|
||||
A similar attribute that I _do_ recommend is the [`decoding`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Img#attr-decoding) attribute. I typically use `decoding="async"` so that image decoding can be deferred.
|
||||
|
||||
Long pages with many DOM nodes may benefit from CSS containment, a more recently-adopted part of the CSS spec.
|
||||
|
||||
<dfn>CSS containment</dfn> allows authors to isolate sub-trees of the DOM. When combined with a property like "content-visibility", it enables browsers to defer rendering of less essential below-the-fold content. Try to avoid the "hidden" parameter when "auto" is better:
|
||||
|
||||
<figure itemscope itemtype="https://schema.org/Quotation">
|
||||
<blockquote>
|
||||
|
||||
`content-visibility: auto` is a more complex value than `hidden`; rather than being similar to `display: none`, it adaptively hides/<wbr>displays an element's contents as they become <a href="https://drafts.csswg.org/css-contain/#relevant-to-the-user">relevant to the user</a>. It also doesn’t hide its <a href="https://drafts.csswg.org/css-contain/#skips-its-contents">skipped contents</a> from the user agent, so screen readers, find-in-page, and other tools can still interact with it.
|
||||
|
||||
</blockquote>
|
||||
<figcaption>
|
||||
—
|
||||
<span class="h-cite" itemprop="citation" role="doc-credit">
|
||||
<span itemprop="isPartOf" itemscope itemtype="https://schema.org/TechArticle">
|
||||
<cite itemprop="name" class="p-name">CSS Containment Module Level 2</cite>, section 4.2:
|
||||
<a class="u-url" itemprop="url" href="https://drafts.csswg.org/css-contain/#using-cv-auto">Using <code>content-visibility: auto</code></a>
|
||||
</span>
|
||||
</span>
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
Leveraging containment is a progressive enhancement, so there aren't any serious implications for older browsers.
|
||||
|
||||
Beyond alt-text
|
||||
---------------
|
||||
|
||||
|
@ -885,3 +912,4 @@ A special thanks goes out to GothAlice for the questions she answered in `#webde
|
|||
|
||||
[^4]: <p>Consider disabling the JIT for your normal browsing too; doing so removes whole classes of vulnera­bilities. In Firefox, navigate to `about:config` and toggle these options:</p><pre><code>javascript.options.ion<br>javascript.options.baselinejit<br>javascript.options.native_regexp<br>javascript.options.asmjs<br>javascript.options.wasm</code></pre><p>In Chromium and derivatives, run the browser with `--js-flags='--jitless'`; in the Tor Browser, set the security level to "Safer".
|
||||
|
||||
|
||||
|
|
Loading…
Reference in a new issue