Bug 207698 - Defer execution of async scripts until until the document is loaded
Summary: Defer execution of async scripts until until the document is loaded
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Chris Dumez
URL:
Keywords: InRadar
Depends on: 208896
Blocks:
  Show dependency treegraph
 
Reported: 2020-02-13 08:49 PST by Chris Dumez
Modified: 2020-04-21 09:19 PDT (History)
15 users (show)

See Also:


Attachments
Patch (2.78 KB, patch)
2020-02-13 08:55 PST, Chris Dumez
no flags Details | Formatted Diff | Diff
Alternative (981 bytes, patch)
2020-02-17 11:19 PST, Chris Dumez
no flags Details | Formatted Diff | Diff
Alternative (983 bytes, patch)
2020-02-17 11:20 PST, Chris Dumez
no flags Details | Formatted Diff | Diff
Patch (13.05 KB, patch)
2020-02-17 13:05 PST, Chris Dumez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Dumez 2020-02-13 08:49:10 PST
Defer execution of async scripts until until the document is loaded by default to reduce time to first paint.
Comment 1 Chris Dumez 2020-02-13 08:49:32 PST
<rdar://problem/57625747>
Comment 2 Chris Dumez 2020-02-13 08:55:28 PST
Created attachment 390654 [details]
Patch
Comment 3 Antti Koivisto 2020-02-13 09:51:47 PST
Comment on attachment 390654 [details]
Patch

I suspect this is overly aggressive but worth trying.
Comment 4 Chris Dumez 2020-02-13 09:53:14 PST
Looks like there are some new passes and some new failures on EWS :/ Will need some investigation..
Comment 5 Chris Dumez 2020-02-17 11:19:54 PST
Created attachment 390945 [details]
Alternative
Comment 6 Chris Dumez 2020-02-17 11:20:58 PST
Created attachment 390946 [details]
Alternative
Comment 7 Chris Dumez 2020-02-17 13:05:30 PST
Created attachment 390962 [details]
Patch
Comment 8 WebKit Commit Bot 2020-02-17 17:04:25 PST
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: dbates@webkit.org)
editing/spelling/spellcheck-attribute.html bug 206178 (authors: g.czajkowski@samsung.com, mark.lam@apple.com, and rniwa@webkit.org)
The commit-queue is continuing to process your patch.
Comment 9 WebKit Commit Bot 2020-02-17 17:04:40 PST
The commit-queue encountered the following flaky tests while processing attachment 390962 [details]:

editing/spelling/spellcheck-async-remove-frame.html bug 158401 (authors: morrita@google.com, rniwa@webkit.org, and tony@chromium.org)
The commit-queue is continuing to process your patch.
Comment 10 WebKit Commit Bot 2020-02-17 19:12:48 PST
Comment on attachment 390962 [details]
Patch

Clearing flags on attachment: 390962

Committed r256808: <https://trac.webkit.org/changeset/256808>
Comment 11 WebKit Commit Bot 2020-02-17 19:12:50 PST
All reviewed patches have been landed.  Closing bug.
Comment 12 krinklemail 2020-03-05 18:39:33 PST
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.
Comment 13 Geoffrey Garen 2020-03-06 14:06:37 PST
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.)
Comment 14 peter 2020-03-10 01:41:42 PDT
I think you can try with https://en.wikipedia.org/wiki/Barack_Obama
Comment 15 Chris Dumez 2020-03-11 08:16:21 PDT
(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.