Thanks for your comment, Ilya. Sorry that Ping is still on vacation, if you dont mind, I'd answer these questions.
The reason why an explicit meta policy is need, is because the structures of the webpages can be very varied. For some of them, the first part of the content doesn't require(to load or to run) any outer resources, while some others do. Although all browsers are trying to optimize the time to first paint, e.g. make the layout of the first part of the page a high priority, start painting ASAP. For all these varied webpages, following the same optimizing rule(even for our First Screen Paint In Advance) would not be the best practice, IMO. Those bad cases will introduce errors or exceptions. We suggest the developers should be given a chance to choose whether the First-Screen-Paint-In-Advance policy is the best practice for their pages, but these should be decided before we actually reach the content(body). That's why we use a Meta in the beginning of the page, ie. the head, to tell the browser whether it can actively apply this optimization to the current page. As for LazyLoading, I have to say that's a completely different way to handle resources, and I dont think there are any conflict between LazyLoading and First Screen Paint In Advance. 发件人: Ilya Grigorik [mailto:[email protected]] 发送时间: 2014年9月19日 2:43 收件人: Wu,Ping(Sumeru) 抄送: [email protected] 主题: Re: First Screen Paint In Advance-draft Hi Wu. On Thu, Jun 5, 2014 at 5:22 AM, Wu,Ping(Sumeru) <[email protected]<mailto:[email protected]>> 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
