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

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