There are some forces at play in a web app that point to wanting to delay layout and rendering until a web app gives a signal that it should start:
* ECMAScript modules, and even developer constructed JS module systems today, rely on async loading of scripts. * Custom elements need their JS registered with the browser before they are fully useful. * Apps can have dependencies on async IDB operations to know what UI to first show. For instance, if the user does not have a saved account, show the sign in view instead of the app data view. * We want fast app startups in B2G/Gaia. Typically we lose layout/render/paint time while we wait for these async mechanisms to finish, and the paints are not useful for the user in the meantime. In addition, there is a possibility that custom elements may take a path of synchronous construction with no later upgrades, which means the JS for the custom element needs to be registered before any custom element is used in the DOM. A similar case surfaced a while back in the context of B2G, and at the time I filed bug 863499[2], which focused on a document.mozDelayLoadEvent / document.mozStopDelayingLoadEvent JS API around controlling the load event firing. At that time, the concern was about losing times to wasted renders and the effects on screen shots. However, I believe the main concern now is getting enough JS and app data loaded to allow layout to be effective in fewer passes than strictly about the final render and load event. So maybe the API should be more about delaying layout than about the load event? In talking to Wilson Page, he mentioned something like a document.pauseLayout() document.resumeLayout(), not sure if there are existing thoughts around that. If that seemed workable, maybe also a <html mozPauseLayout> type of attribute, so the browser knows as soon as possible to pause its work, instead of relying on a JS API. For Gaia apps, we use a CSP policy that does not allow inline scripts, so the attribute on a tag is more appealing for that reason. A nonced script might be a workable alternative for the CSP case, if an attribute was too much of a stretch. Happy to hear about any suggestions for the general goal, James [1] Service workers help a bit here, but do not help the other aync forces. [2] https://bugzilla.mozilla.org/show_bug.cgi?id=863499 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
