Improve loading of 3P scripts

[mgechev]

🚀 Feature request

Command (mark with an x)

• new
• build
• serve
• test
• e2e
• generate
• add
• update
• lint
• extract-i18n
• run
• config
• help
• version
• doc

Description

Loading third-party scripts in a suboptimal way can cause performance regressions. A typical example is adding an SDK as script tag directly to the page head, which will block the loading of first-party scripts and delay hydration/CSR if done incorrectly.

Describe the solution you'd like

Expand scripts the functionality already available in angular.json, allowing developers to configure different script loading strategies. Project Aurora identified three script loading strategies that we can reuse:

• afterInteractive - this strategy would prioritize first-party scripts by executing third-party scripts after the page has been hydrated or client-side rendered.
• beforeInteractive - execute third-party scripts before first-party scripts. This strategy is particularly important for loading polyfills. Since we already have polyfill.ts, I'm a little hesitant to include it in the Angular CLI as part of the first feature iteration. I'd suggest keeping it out of scope and collecting feedback in the meantime.
• lazyOnload - lowest priority. We load these scripts and execute them in requestIdleCallback. Examples for libraries using this strategy for prefetching are quicklink, ngx-quicklink, and guess-js.

We'd sometimes need a hook after the script has been loaded and executed if we load it asynchronously (afterInteractive or lazyOnload). For example, rendering a payment dialog after we've downloaded a third-party SDK.

Using angular.json does not provide an evident approach that would let us accomplish this. A lower-level API that would provide the necessary functionality is to allows developers to specify id's in the script declaration. Using the id, developers will discover the script element in their code and hook to its onload event.

This way, the scripts property in angular.json would change from an array of strings or objects to an array of strings or objects with the following properties:

• input - the source URL or path of the script. The CLI will perform different actions depending on whether input is a local path or a remote URL
• strategy - afterInteractive, beforeInteractive, or lazyOnload
• inject - specifies if the script should be injected or not. We preserve the current semantics of the inject property in the script object
• bundleName - applicable for local scripts only. For external scripts, we can throw an error
• id - an optional identifier that the developer can use to get a hold of the script and hook to its onload event

Suppose we find a string rather than an object for a given script. In that case, we can treat it as a script object with an input the specified string, strategy equal to beforeInteractive for the current major, or afterInteractive for the next major. Ideally, we'd want the default strategy to be afterInteractive to prevent folks from causing performance regressions, but since this would be a breaking change, we don't want to do this until v13.

In v13, we can migrate all the scripts from objects to strings using the beforeInteractive strategy.

Describe alternatives you've considered

Project Aurora considered using a script component for alternative frameworks. Their approach easier accommodates the onLoad callback use case but seems to fit less naturally in the Angular CLI model.

[mgechev]

Based on our discussion today, I want to add a few more details.

Motivation

Currently, folks can accomplish the same by updating index.html manually and adding script references. This technique, however, doesn't guarantee that people will be following best practices. Many application developers add blocking scripts to the page head, which causes regression of CWV.

Additionally, best practices for loading scripts evolve, which means that to get the best from CWV, developers will have to be constantly following the progress of these low-level browser APIs.

Conformance

As part of the solution, we can introduce a conformance rule that will fail the build if folks are loading blocking scripts in the application head. Even though this would be helpful, we still don't provide a solution that aligns with the best set of practices for script loading.

Ideally, we'd want to have both:

• Functionality for properly loading scripts with proper defaults
• Conformance to ensure that index.html is free of blocking scripts

[dgp1130]

After some discussion with the Web SDK team, there are some concerns about not optimizing scripts which are directly authored in the index.html file. We'll need conformance tooling to enforce this anyways, so the main question is around how we want to evolve the angular.json script loading.

After some evaluation of the API, we're not entirely sure how this should continue to fit in to Angular tooling and how we should evolve the API over time. So we're planning to write an RFC to gather additional information about how devs currently use angular.json script loading to better understand how we can optimize those scripts and how script loading should fit into Angular tooling. @clydin offered to write an initial RFC proposal for this.

[alan-agius4]

@mgechev, is this still something we want to do?