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

发件人: Ilya Grigorik [mailto:igrigorik@gmail.com]
发送时间: 2014年10月31日 5:26
收件人: Ben Maurer
抄送: WHATWG; public-web-perf
主题: Re: [whatwg] allow <link> in body + DOM position as a rendering hint

On Thu, Oct 30, 2014 at 1:25 AM, Wu,Ping(Sumeru) <wuping02@baidu.com<mailto:wuping02@baidu.com>> wrote:
 I have three comments on the summary and the previous discussion:

1.    There are many questions about “After all, all browsers are after the same goal and want to optimize their time to first paint, regardless of whether its a mobile site or not... Why would we gate something like this on an opt-in policy?”

I’d like to say. Yes, browsers are optimizing their time to first paint, but at least on latest webkit and blink, we don’t see any specific optimization on the displaying speed of the first screen content. Applying this kind of user experience optimization by giving the highest priority of the first screen content, we can see significant speedup of the first screen paint. Below is the displaying time before optimization and after optimization, on webkit and blink kernel.
(snip...) Thanks for the numbers! A good indicator that we can, indeed, deliver a faster experience.

2.       In the first edition of our “first screen paint in advance”proposal, we also want to define a div element with “first Screen paint”property, Which can help define the tokens number that is needed to parsed for a full screen. But on different devices with different screen size， it is hard for developer to define such varying position. On the other hand, for a modern browser kernel, it can calculate and judge whether current layouted content height has reached the screen height or not.
Defining "first screen" is a tough exercise, both for developers, and for the browser: as a developer you have to deal with a lot of different dimensions+orientations, and as a browser, we don't know what you intend to show within first screen (DOM content does not necessarily map to display order, etc). However, perhaps we don't need to either...

I think we can get pretty far by using the location of the <link> element in the DOM as a marker+hint for unblocking paints for content above it -- similar to how <scripts> behave. The benefit of this approach is that you can define multiple markers in the page by linking to different stylesheets. This way, we don't have to define or talk about "first screen" at all.


Yes, agreed. Two proposals do have similarity.

The difference of these two proposals may be : First Screen Paint proposal is focused on the browser side optimizing policy and emphasis on user experience improvement.
Allowing <link> element in body is more relied on the web  developer side to “define multiple markers in the page by linking to different stylesheets”.

Since CSS loading or blocking is an important factor for rendering speed,  late loading css element can help accelerate rendering speed.
But, even all css elements are lazy loading or late loading like <link> in body,  experiment shows we can still optimize first screen content rendering speed by using browser kernel technique described in our proposal.

I also have a problem  that you have already mentioned that “other.css my impact rendering of the content above it( it’s applied against global context)”, if web developer do this carelessly,
Do we have solution for avoiding unnecessary reflow & painting ?

Thanks,
Wu Ping


3.    Our proposal is different with lazy load.
Yes, agreed.

On Thu, Oct 30, 2014 at 12:17 PM, Ben Maurer <ben.maurer@gmail.com<mailto:ben.maurer@gmail.com>> wrote:
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).

Right, the problem with previous proposals for async stylesheets is that it is really hard to reason about how+when they will be applied, which would force you to manually hide most of the content and then modify the visibility when stylesheet is ready... at least, if you want to avoid FOUC. The proposal here is an in-between solution that's much simpler to deploy: the position of the <link> in the doc acts as a hint that DOM-content before it does not have to block paints on it, so the UA can do the bookkeeping for what can be painted vs what should remain hidden. All the developer has to do is move the <link>'s in right positions in the doc.

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).

Depends on what you mean by parity? If you mean async, etc, then personally I'd prefer that we keep that as a separate discussion (and I'm not convinced we need async for stylesheets). What we're proposing here requires minimal change to the spec and reflects the (already) implemented patterns both in markup and in some rendering engines... a simple update that could pay high perf dividends.

ig


On Wed, Oct 29, 2014 at 2:46 PM, Ilya Grigorik <igrigorik@gmail.com<mailto: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/