Issue metadata
Sign in to add a comment
|
Priority is too low for Async Scripts |
||||||||||||||||||||||
Issue descriptionAsync scripts (injected by js or using the async/defer tags) currently load with a "Low" priority which is the same as non-visible images and lower than late-body scripts. For the common pattern of js that loads other js (i.e. tag managers, analytics, ads, etc) this results in the subsequent js files getting queued behind ALL of the images in the page because the preload scanner would have discovered them before the second js gets discovered. This is true for both js added using an inline script block (like most analytics tags) as well as js loaded by external js. Late-body blocking scripts are currently given a "Medium" priority which still defers them after the layout-blocking phase but loads them before non-visible page images so that the parser can quickly make it to the end of the document (and fire DOM Content Loaded). Async scripts are given a lower priority because they don't block DCL from firing and the tracked metrics look better as a result but that has a pretty serious downside too. The only way to chain js requests and not have the js files load later is to document.write them in a blocking script which is the worst pattern on the web for performance. Boosting the priority of async scripts to Medium will give them the same priority as late-body scripts so their loading can better be controlled by where they are in the document (relative to other scripts) but more importantly also doesn't penalize them by putting them behind all of the images.
,
Feb 10 2017
For #1, a separate bug should be filed for the actual execution of async scripts. The resource priority at fetch time shouldn't have anything to do with scheduling when it comes out of cache, only for network-bound requests. It does right now just because resource scheduler sits in front of the cache (and service worker) but that is about to be fixed by other work the net team is doing so all discovered resources will be returned immediately if they are in cache regardless of the priority. That said, the async scripts will only execute immediately on load if the main html parser has already parsed the script tag that inserted it which means the timing for the execution is already somewhat under the control of the content author. If they want to make sure it doesn't execute before the bulk of the DOM has been built (FMP) they can put the async script tag at the end of the page.
,
Apr 5 2017
,
Apr 12 2017
,
Apr 19 2017
,
Apr 20 2017
,
Apr 4 2018
,
Apr 12 2018
I think the changes outlined here sound good. This makes sense to me because it further differentiates <script async> and <script defer>, because it is likely (IMO) that a developer uses async *chiefly* to ensure that _loading_ doesn't block DOM construction, but still anticipates the execution to (or at least is OK with it) block parsing. If they wanted both loading and execution to be guaranteed to not block the parser (closer to what we have now since they load with such low priority) they'd just use defer.
,
Jul 30
This is being addressed through priority hints (issue 821464) where the priority for individual async scripts can be increased as needed.
,
Jul 30
Would it also be worth adjusting the default (non-priority-hinted) priority of async scripts aside from letting developers do this with Priority Hints, or is letting developers control this by means of a hint sufficient?
,
Jul 30
I think the default priority is as good as it is going to get and the exceptions can be handled through hints. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by lizeb@chromium.org
, Feb 9 2017