Bug 207698 – Defer execution of async scripts until until the document is loaded

• Component: Page Loading
• Status: RESOLVED FIXED

[Chris Dumez]

Defer execution of async scripts until until the document is loaded by default to reduce time to first paint.

[Chris Dumez]

<rdar://problem/57625747>

[Chris Dumez]

Created attachment 390654 [details]
Patch

[Antti Koivisto]

Comment on attachment 390654 [details]
Patch

I suspect this is overly aggressive but worth trying.

[Chris Dumez]

Looks like there are some new passes and some new failures on EWS :/ Will need some investigation..

[Chris Dumez]

Created attachment 390945 [details]
Alternative

[Chris Dumez]

Created attachment 390946 [details]
Alternative

[Chris Dumez]

Created attachment 390962 [details]
Patch

[WebKit Commit Bot]

The commit-queue encountered the following flaky tests while processing attachment 390962 [details]:

http/tests/security/contentSecurityPolicy/report-status-code-zero-when-using-https.html bug 197297 (author: [e-mail])
editing/spelling/spellcheck-attribute.html bug 206178 (authors: [e-mail], [e-mail], and [e-mail])
The commit-queue is continuing to process your patch.

[WebKit Commit Bot]

The commit-queue encountered the following flaky tests while processing attachment 390962 [details]:

editing/spelling/spellcheck-async-remove-frame.html bug 158401 (authors: [e-mail], [e-mail], and [e-mail])
The commit-queue is continuing to process your patch.

[WebKit Commit Bot]

Comment on attachment 390962 [details]
Patch

Clearing flags on attachment: 390962

Committed r256808: <https://trac.webkit.org/changeset/256808>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

What metrics will be used to decide the success of this experiment?

--

I'm concerned that this change removes an importanat primitive from the Web Platform. Wikipedia uses <script async> precisely to enable a fast first paint (compared to a synchronous script).

Waiting for document-content-loaded, as this change suggests and as <script defer> does already, is undesirable for us because because that means the page would remains *non-interactable* until after the entire HTML document has been downloaded and parsed.

For long-form HTML documents that are 1 MB or more in size, as most popular Wikipedia articles are, Safari and other major browsers today follow a well-optimised streamable rendering. When the above-the-fold HTML and first few screens below that arrive, they are natively parsed and rendered onto the screen as soon as the high-priority few KB stylesheets have arrived as well. this delivers a great user experience.

Then, as soon as the few KB async scripts arrive, they attach their delegate event listeners and the page is fully interactive, including metric instrumentation. Anything that continues to download and parse below the fold is naturally interactive from the get-go for when the user scrolls there.

*Before* – As I understand it, today, users can open pages in Safari, see them visually, read significant portions of content, interact with the page, and leave to go to another page, all before the bottom of the HTML has been downloaded and parsed!

*After* – With this change, I fear the scripts will be withheld in memory while valuable time is being wasted to download a megabyte of unimportant HTML down the pipes, spending lots of CPU cycles parsing that into a DOM when these cycles could've been spent making above-the-fold interactive.

Users would be staring for *multiple seconds* at an interactable pages while their browser is waiting for network transfers to arrive from the other side of the planet, and waiting for their device to pars irrelevant content far below the fold. Meanwhile the content they do see is lacking interactive components, and their fallbacks are offering less functionality (e.g no search suggestions, no sortable tables, clicking images would not open a lightboxes, etc)

For short pages, this might not make a big difference, but then again I suspect this change might not be aimed at short pages where documents would complete the DOM before scripts arrive regardless (given H2 priorities). And if not, web authors would have <script defer> at their disposal to tune it to their liking. However, by taking away <script async> an important primitive could be lost.

[Geoffrey Garen]

Can you suggest a good example article to test for this condition? (I believe your concern; but I also want to be able to test that a proposed fix really works.)

I think you can try with https://en.wikipedia.org/wiki/Barack_Obama

[Chris Dumez]

(In reply to peter from comment #14)
> I think you can try with https://en.wikipedia.org/wiki/Barack_Obama

Thanks, working on tweaking our behavior accordingly here: Bug 208896.