As far as I know, the reason for loading the site module in a separate request is that it needs to execute in global context, rather than in a standard module closure, but we can work around it by using $.globalEval.
Regardless of whether or not that is the reason, let's figure out how to load it along with other modules, and save ourselves a request in the critical path.
See also:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Krinkle | T65587 Performance issues with "site" module (tracking) | |||
| Resolved | Krinkle | T102077 Load bottom script "site" and "user" asynchronously | |||
| Resolved | Krinkle | T32358 Support loading legacy "site" and "user" modules with mw.loader |
In addition to being a separate request, it also an unversioned currently because it has to be hardcoded in the html. Loading it with mw.loader will provide better caching. Depends on T32358.
Using https://developers.google.com/speed/pagespeed/insights/ it currently complains about two uncacheable resources related this task. Namely the two requests for the site module (stylesheet and script).
Eliminate render-blocking CSS (1/3)
Leverage browser caching (2/5)
Closing since the remaining work isn't specific to the site module but part of T96797.