JavaScript is rarely dynamic

[grugnog]

Under: https://w3c.github.io/sustyweb/#success-criterion-avoid-dynamic-resources

Avoid using the service to host dynamic resources (such as JavaScript) as due to cache partitioning, any benefits are negated by weaker performance, and the potential introduction of security and privacy issues.

It's unclear if this is referring to Edge compute or CDNs (I assume the latter, but would be good to clarify).
JavaScript is considered a static asset and is highly cachable - the same as CSS, images etc. Dynamically generating JavaScript code on a per-request basis is very rare.

If this section refers to CDNs JSON or HTML could be an accurate example here, but only if the JSON or HTML contains highly request specific (e.g. keyword search results) or user data (e.g. a form submission).

[AlexDawsonUK]

The information regarding Edge compute / CDN's is being clarified in the next draft.

Regarding JavaScript: while it is indeed a static asset (we will make sure to correct that language) and highly cacheable (on the client-side), it's use within CDN's is poor for performance and especially for Web sustainability due to enforced cache partitioning introduced by browsers, and the notable additional issue of CORS and (again) the potential for security, privacy, and environmental issues which can be averted by simply hosting the scripts yourself. If you have evidence to cite which would change this perspective (regarding how browsers treat non-first party scripts) and taking into account the sustainability and additional variable impacts, please post the links and we will make any adjustments required.

Changes will be made to the wording as mentioned above (though feel free to provide updates below).

[AlexDawsonUK]

The changes have been made, this will be reflected once the next draft goes live.

Note: This issue connects to the resolved issues #24 and #17

[grugnog]

@AlexDawsonUK the guidance as it is written now reads (to me at least) as if "the" CDN service in use for serving the site should be specifically configured to exclude JavaScript from caching.

This situation involving 1st party hosted JavaScript served by the same CDN as the rest of the site does not have any of the cache partitioning implications you reference around security (as long as the CDN is trustworthy), privacy or environmental impacts. This is because the data and hostname should be indistinguishable from a browser perspective to serving without any CDN, except that it is cached nearer to the user.

This is a very different from including 2nd/3rd party JS from another hostname, such as cdnjs.com, which is impacted by cache partitioning issues (which break the oft-perceived benefit of a "shared cache"). This scenario is indeed more resource intensive, since it commonly requires setting up additional TCP connections to this other CDN (vs the first scenario, where a connection would already be present, it being used for HTML, CSS etc).

[AlexDawsonUK]

Note: Just an update, the changes are now visible within the latest version of the specification, and I've added in some extra supporting evidence links which will be reflected in the next draft.