W3C home > Mailing lists > Public > public-web-perf@w3.org > October 2014

allow <link> in body + DOM position as a rendering hint

From: Ilya Grigorik <igrigorik@gmail.com>
Date: Wed, 29 Oct 2014 14:46:28 -0700
Message-ID: <CAKRe7JEzWUg8xj1sgXQvi+eAMWYh+gf5ccgS8b8-cW5yvo_FaQ@mail.gmail.com>
To: WHATWG <whatwg@whatwg.org>
Cc: public-web-perf@w3.org
(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 Wednesday, 29 October 2014 21:47:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:40 UTC