Re: [whatwg] allow <link> in body + DOM position as a rendering hint

We talked a bit before about the idea of async stylesheets (like async
scripts). That kind of functionality could implement something similar to
this proposal (though in a bit more of a clunky way -- you need to have an
inline visibility:hidden style for the content you want to hide then
override that in css).

It seems like there's a consistency problem between script loading and
stylesheet loading. Would it be worth trying to ensure there is parity
between those two things. Script tags already implement the behavior you
are suggesting (a <script> can be inside the document body and will only
block content that occurs after it).

On Wed, Oct 29, 2014 at 2:46 PM, Ilya Grigorik <igrigorik@gmail.com> wrote:

> (based on discussion at the webperf group meeting at TPAC... hopefully I
> captured the discussion correctly. If not, please jump in!)
>
> HTML5 spec: "If the rel attribute is used, the element is restricted to the
> head element." [1]
>
> Above language is too restrictive, allowing link element to be present in
> the body (as many sites already do, and all browsers support), would enable
> useful performance optimizations for stylesheets in particular - e.g. IE
> treats stylesheets in <head> as render blocking and will hold page
> rendering until they are downloaded and executed, however a <link
> rel="stylesheet"...> within body is treated as render blocking for
> DOM-content before its declaration (although, this behavior is only
> triggered as an error condition based on some additional timeouts).
>
> Above IE behavior enables faster first-paint for "above the <link> content"
> and is already in use by some developers - i.e. sites are *forcing* the IE
> error condition to deliver faster paints.
>
> <html>
>  <style> /* critical css */ </style>
>  <body>
>  <header>...</header>
>
>   <style rel=stylesheet href="other.css"/>
>   <section>...</section>
>   </body>
> </html>
>
> In above example <header> content may be painted by the browser before
> other.css is downloaded and processed. Effectively, the position of the
> <link> element in the document acts as a hint to the UA that it may (not
> must) paint the DOM-content before it without blocking on it.
>
> To be clear, this proposal does *not* change any existing semantics of CSS.
> Once processed, other.css *may* impact rendering of the content above it
> (it's applied against global context), which may cause reflows, etc.
> However, a well implemented site can avoid unnecessary reflows+paints by
> splitting relevant styles in a way that minimizes interaction between
> various sections.
>
> Baidu team has prototyped something similar via their "First Screen Paint
> In Advance" proposal [2] and saw significant improvement in rendering times
> on mobile devices.
>
> tl;dr: proposal is...
>
> 1) allow link tags in the body
> 2) add a note to implementors: consider treating link tags in body as a
> hint to the UA that what is above the link tag (in DOM order) should not be
> blocked on painting
>
> Above behavior is already deployed in the wild (both on sites and
> implemented in some browsers), and helps deliver faster first paints, as
> evidenced by Baidu and IE experience. Based on discussion at the TPAC
> meeting, there was interest from IE, Chrome, and Safari (we didn't have
> anyone from Mozilla to comment) in exploring this further... However, that
> would require some spec updates on HTML front.
>
> Thoughts?
>
> [1] http://www.w3.org/TR/html5/document-metadata.html#the-link-element
> [2] http://www.w3.org/Submission/first-screen-paint/
>

Received on Thursday, 30 October 2014 19:18:17 UTC