To make this work, we'll need to extend the concept of "module content" (scripts, styles, messages, templates) to also account for headers (or, at least, Link headers; or perhaps specifically "Resource URLs to preload").

This meta information will need to be supported at a few different levels:

• ResourceLoaderModule: A new method that returns the information. And expose either as part of getModuleContent, or use directly in ResourceLoader::response.
• ResourceFileCache: We may need to change the file format for this if we want to store the meta data here too. Alternatively, if producing this information is "fast enough", we could just not cache this (or use object cache).
• ResourceLoader::sendResponseHeaders: To include the new Link headers.

Then to use it, we would declare in StartupModule that the getStartupModulesUrl() is a candidate for preloading.

Questions:

• Does a "304 Not Modified" response need to contain the Link headers?
• Should FileCache mode store these headers somehow? If we want to use these for preloading urls from a stylesheet (T120984), getLinkHeaders() will likely involve as much work as getStyles() would so it wouldn't make sense *not* to cache. On the other hand, I'd really like to avoid having to refactor FileCache to support headers instead of just a response body.

In T164299#3240236, @Krinkle wrote:

Questions:

• Does a "304 Not Modified" response need to contain the Link headers?

Hopefully not. But this should be easy to validate experimentally by making the preloaded resource must-revalidate, because then you'll be able to see exactly when the browser fetches it even if it's already got it in cache. (It makes little sense to do this in production though, I only suggest this for testing how preload works.)

Confirmed with an isolated example that browsers will use the Link headers from their cached response when receiving a 304 Not Modified response without re-sending the Link headers on the 304 response. Test case: https://gist.github.com/Krinkle/d39cd3d4bd30a10fad5e1ae7f60b4c11

Change 365888 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] [WIP] resourceloader: Add support for modules sending preload headers

https://gerrit.wikimedia.org/r/365888

Change 365889 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] [WIP] resourceloader: Preload base modules request from startup module

https://gerrit.wikimedia.org/r/365889

Change 365888 merged by jenkins-bot:
[mediawiki/core@master] resourceloader: Add support for modules sending preload headers

https://gerrit.wikimedia.org/r/365888

Change 365889 had a related patch set uploaded (by Krinkle):

[mediawiki/core@master] resourceloader: Preload base modules request from startup module

https://gerrit.wikimedia.org/r/365889

Timeline capture from Chrome (Network: Slow 3G) with and without this patch applied:

Change 365889 merged by jenkins-bot:
[mediawiki/core@master] resourceloader: Preload base modules request from startup module

https://gerrit.wikimedia.org/r/365889

If we have time at the offsite we could sit down and check how we test this locally with WebPageTest or Browsertime to get more reliable metrics (running X number of tests, taking the median etc) and write about it at Wikitech, it would be nice to have a work flow for testing things locally. Or maybe this should actually be task for us?

Using sitespeedio/browsertime (in Docker on Mac, with throttled connectivity), I did a couple of runs against local MediaWiki-Vagrant with git checkouts of mediawiki-core from before and after https://gerrit.wikimedia.org/r/365889.

I confirmed the same impact as from the manual comparison in Chrome. The JS startup/base requests now nicely overlap, and overall page load end is reduced by about 1.1s on slow connections. In case of the slow-3g throttle via browsertime, it went from ~30s to ~28s.