Re: First Screen Paint In Advance-draft

Hi Wu.

On Thu, Jun 5, 2014 at 5:22 AM, Wu,Ping(Sumeru) <wuping02@baidu.com> wrote:

> To provide a better user experience on mobile devices, browser can adjust
> the scheduling policy for phase transition, which helps to make a complete
> and correct full screen content rendered in advance. Before painting the
> complete first screen content, browser can reduce the parsing tokens number
> for one parsing phase, and also the time slice allocated for parsing phase.
> While entering layout phase, browser tracks the height of layout content to
> check whether it has reached the full screen height. Before reaching the
> screen height, browser can suspend paint and continue the iteration of
> parse and layout. After a full screen layout height is detected or a
> timeout is reached, browser can trigger the first paint operation
> immediately. When first screen content is painted, browser can change back
> to the default phases scheduling policy.


This is all good, but I'm wondering why we need an explicit meta policy for
this? 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? How the
browsers actually implement this under the hood is a whole different story
- everyone's architecture is a bit different and we all have our own bag of
tricks.

The underlying problem, as you identified, are the blocking critical
resources: CSS, JS, etc. We need better primitives (like lazyload, etc)
that can take them out of the critical path and allow the browser paint the
pixels more quickly.

ig