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

On Wed, 29 Oct 2014 23:46:28 +0200, 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>

The spec currently allows <style scroped>@import "other.css";</style> in  
body (at least at the start of an element). I don't know if it has the  
properties you want in existing impls. I also don't know if scoped is OK  
or not for your use case.

IIRC, <link rel=stylesheet> or <style> without scroped is not currently  
allowed in body since it requires the browser to re-evaluate earlier  
elements when loading a page. (You can end up with that when using script  
anyway though.)

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


-- 
Simon Pieters
Opera Software

Received on Thursday, 30 October 2014 23:56:41 UTC