Page MenuHomePhabricator

Performance issues with "site" module (tracking)
Closed, ResolvedPublic

Description

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:

Details

Reference
bz63587

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:18 AM
bzimport set Reference to bz63587.
bzimport added a subscriber: Unknown Object (MLST).
ori created this task.Apr 6 2014, 3:26 AM

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.

Krinkle renamed this task from ResourceLoader: Avoid making a separate request for the site module to Performance issues with "site" module (tracking).EditedJul 12 2015, 11:31 AM
Krinkle updated the task description. (Show Details)
Krinkle edited projects, added Performance-Team; removed Performance Issue.
Krinkle set Security to None.
Krinkle removed a subscriber: wikibugs-l-list.

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)

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 21 2015, 9:07 AM
Krinkle closed this task as Resolved.Sep 18 2015, 10:39 PM
Krinkle claimed this task.

Closing since the remaining work isn't specific to the site module but part of T96797.