Page MenuHomePhabricator

Consider using hashed module names in RL startup module
Closed, DeclinedPublic

Description

It would probably be enough to have hashed module names in the RL startup module. Whenever something is requested via mw.loader.load it is referred to by name, so we can easily resolve this client side. For loading dependencies (which the caller to mw.loader didn't explicitly ask for), we would need to alter load.php so that it can serve things by hashed module name.

I very briefly tested this and it seems we could save around 9% in post-gzip file size (for this test I used the first five chars of md5(module name), see P9484 and P9485 for details).

Potential problems:

  • mw.loader.getModuleNames which returns a list of all module names (not used much it seems)
  • Getting a reasonable safe hash function into the clients also costs bandwith (+ some CPU time… hashes need to be computed)

This hasn't been proposed/ discussed before as far as I can tell, so I just wanted to bring it up so that we can evaluate it.

Event Timeline

Based on the goals and budget we've set out for the first "startup module" payload last quarter (see blog post), we don't have a strong incentive to reduce it further. At about ~20 KB it is essentially "small enough".

From today's featured article:

  • HTML payload: 63 KB transferred,
  • CSS payloads (2): 58 KB transferred,
  • JS payloads (3), 256 KB transferred.

From the 256 KB in JS payloads, 25KB is the startup module, of which 9% would be about 2KB. We will instead focus our efforts on the second and third payloads ("page modules"), which are significantly larger where improvements have a much bigger impact. See T233676 for example. I am also continuing (small) efforts that reduce the startup size by simply eliminating modules from it entirely (T233675, T219604, etc.).

Declining for now because changing the registry in the manner proposed would significantly complicate maintenance and debuggability of the system. As such, it is unlikely to be worth the cost of implementing. I speculate there will always be other things we can do that have more value to end-users for the same cost. See also RL Principles.

I am generally open to ideas like this and would be open to revisiting this in the future.