W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2014

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

From: Simon Pieters <simonp@opera.com>
Date: Thu, 30 Oct 2014 16:56:00 +0200
To: WHATWG <whatwg@whatwg.org>, "Ilya Grigorik" <igrigorik@gmail.com>
Message-ID: <op.xokh3mmaidj3kv@simons-mbp>
Cc: public-web-perf@w3.org
On Wed, 29 Oct 2014 23:46:28 +0200, Ilya Grigorik <igrigorik@gmail.com>  

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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:25 UTC