View source for User:SD0001/Making user scripts load faster

User scripts can be made to load faster with the help of caching. However, this is '''experimental''', let me know if you face any issues on the talk page.

Add the following snippet of [[Minification (programming)|minified code]] to the '''''top''''' of your {{yourjs}} page:
{{#tag:syntaxhighlight|{{User:SD0001/userscript-load-caching.min.js}}|lang=javascript}}

If you don't like this ugly blob of incomprehensible code, you can instead add the fully and pretty version (but this takes up a lot of lines):
{{collapse
|1={{#tag:syntaxhighlight|{{User:SD0001/userscript-load-caching.js}}|lang=javascript|line=1}}
|2=Unminified full code (readable version)
}}
(The two code snippets are functionally the very same).

Note that the code block necessarily needs to be at the top of your common.js page for it to take effect. 

It replaces the existing implementations of <code>mw.loader.load</code>, <code>mw.loader.getScript</code>, <code>importScript</code> and <code>importStyleSheet</code>. No changes are needed in the way you normally add new user scripts.

== Impact ==
The effect can be seen by keeping the network tab of your browser dev tools open and navigating through different pages. (Don't reload the same page – that's seen as a hard reload in some browsers and causes bypassing of cache.) Also ensure you have the "Disable cache" option unchecked in the devtools. In Chrome, you should see that most script fetches are resolved by the [https://www.chromium.org/developers/design-documents/network-stack/disk-cache disk cache] itself which is very fast. 

[[File:Impact of userscript-load-caching (before).png|thumb|700px|Without caching. Each script takes 400–500ms. A particularly large script takes 1.11 s! Internet download speed is 50 Mbps.|centre]]
[[File:Impact of userscript-load-caching (after).png|thumb|700px|With caching enabled. Each script takes just 1-2 ms to load.|centre]]

== Caveats ==
*The snippet above makes all scripts and stylesheets cached by your browser for up to one day (86400 seconds).{{pb}} If any of the scripts are updated, it may take you up to 1 day to see the updates. Doing a hard reload will clear the caches. On Google Chrome, just hitting the "reload" button on any page causes a hard reload. On other browsers, you may need to use {{Keypress|Ctrl|F5}}.

== Technical details ==
loadResource function:

* The API is used instead of index.php because requests to the latter never appear to be cached for logged-in users. With the API's caching parameters, responses get the Cache-Control header <code>s-maxage=86400, max-age=86400, public</code> while the one set by index.php is <code>private, max-age=0, s-maxage=0</code>.
* The <code>uselang=content</code> attribute enables public caching in [[Varnish (software)|Varnish]], etc. See [[phab:T97096]]. However, no public caching takes place for requests by users with ability to view revision-deleted or suppressed content (ref: [https://github.com/wikimedia/mediawiki/blob/1f55624dd2aedfaeb4dc3979bf74e33b6e12b685/includes/api/ApiQueryRevisionsBase.php#L664]). 
* The <code>origin=*</code> causes the API to set the <code>Access-Control-Allow-Origin: *</code> header to avoid CORS issue while loading cross-wiki scripts.
* The contentmodel of the page is checked before the js/css code is evaluated. Non-javascript contentmodel pages won't be evaluated as JS, consistent with a call to index.php for non-JS page with ctype=text/javascript failing with a 403 error.
* Using mw.loader.getScript to load a missing page gives a resolved promise. This is consistent with index.php call to load JS from a non-existent page with a protected title (i.e, a userspace title ending with ".js" or a mediawiki namespace title)  giving a 200 response. 
** However, using index.php to load JS from a non-existent page but with non-protected title gives a 403. loadResource() will give a resolved promise instead.