New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 637505 link

Starred by 4 users

Issue metadata

Status: Fixed
Owner:
Closed: Nov 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Blocked on:
issue 638074

Blocking:
issue 637508



Sign in to add a comment

MD Settings work done before first paint

Project Member Reported by michae...@chromium.org, Aug 13 2016

Issue description

Some unnecessary work is done before first paint, like:

* calculations that require layout information
* non-critical work we'd like to defer

We use setTimeout, requestAnimationFrame, and Polymer.dom.flush to try to defer this work. But if the page has not completely loaded, the content may not be fully rendered. Neither setTimeout nor requestAnimationFrame waits for the page to load before calling their callbacks.

Polymer.RenderStatus and the "attached" method also don't wait for the page to load: https://github.com/Polymer/polymer/issues/3629

So we want to find a better way to defer work until the stuff we want is rendered.


Page load goes something like this:

While Element = ParseNext()
  If Element is a normal <script src> or <link rel=import>:
    Synchronously fetch and parse that URL
  If element is a normal <script src> or <script>:
    Synchronously execute any un-executed scripts inside previously imported pages, in order
    Synchronously execute Element's script
Set document.readyState = "interactive"
Synchronously execute any un-executed scripts inside previously imported pages, in order
Wait for some other resources to finish loading
Set document.readyState = "complete" and fire "load" event

During this process, the page can partially render whenever it wants to.

We can run our deferred work asynchronously after the "load" event, but we *could* be able to run it sooner if the page renders sooner.
 
Owner: michae...@chromium.org
Steve had a promising suggestion: Add a <script> to the bottom of the settings.html page (entrypoint). The script is run once all other blocking scripts and stylesheets have been fetched/parsed/executed, so everything is in the DOM and has the proper styles applied; we are free to consider the page "ready" here, and forcing a style recalc (e.g. settingsUI.offsetHeight) should work.

This seems to work. It delays attached() calls until the DOM is ready to be queried. It triggers well before the load event (which has to wait for other resources like images and fonts).

It creates new problems (mostly flickering, because paradoxically, we paint before getting Chrome API callbacks) but I think those are better problems to have than running too early or too late. I'm not sure how to measure the performance impact yet either.
Blocking: 637508
Labels: Hotlist-MD-Settings-Navigation
Status: Assigned (was: Untriaged)
The functional change of properly managing scroll position is a dev-blocker, but performance changes are not dev-blockers.
Blockedon: 638074

Comment 5 by dbeam@chromium.org, Aug 29 2016

 Issue 641800  has been merged into this issue.
Status: Fixed (was: Assigned)
A few changes have fixed this.

Sign in to add a comment