Page MenuHomePhabricator

[SPIKE, 16hrs] We should not need 164kb of JS and 4.89kb of CSS (gzipped) to render a blank page in safemode
Closed, ResolvedPublic0 Estimated Story PointsSpike

Description

As part of the desktop refresh it is important that we think about the performance of the new experience. Our users deserve a performant desktop site. Given the changes we are planning, we are likely to add to the problem with new widgets. T235712 flagged various libraries that may cause us issues in this area.

The Apiout skin is a great benchmark for desktop performance. It doesn't add any styles or scripts so ships only the styles+scripts from Wikimedia extensions.:
https://en.wikipedia.org/wiki/Special:BlankPage?useskin=apioutput&safemode=1

We should audit the scripts and styles being added to the page and :

  • Identify modules that are not marked with targets desktop+mobile (this has been flagged by T235712)
  • create tickets identifying steps to reducing CSS/JS as subtasks of T235712 with a loading strategy from T235712 and tagged with Readers-Web-Backlog
  • Determine what potential savings to CSS and JS to desktop are possible from reviewing the list of modules flagged in T235712.

Example output task

Event Timeline

Restricted Application changed the subtype of this task from "Task" to "Spike". · View Herald TranscriptOct 17 2019, 7:14 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Is there a particular user scenario and/or numerical objective you have in mind to focus on? I'm busy with other things for 2-3 weeks to come, but after that we could set up a meeting to discuss some ideas around what to measure, who else to involve and who does what etc.

Jdlrobson renamed this task from We should not need 178kb of JS and 10.8kb of CSS to render a blank page to [SPIKE] We should not need 178kb of JS and 10.8kb of CSS to render a blank page.Oct 22 2019, 9:36 PM
Jdlrobson renamed this task from [SPIKE] We should not need 178kb of JS and 10.8kb of CSS to render a blank page to [SPIKE, 16hrs] We should not need 178kb of JS and 10.8kb of CSS to render a blank page.
Jdlrobson assigned this task to ovasileva.
Jdlrobson moved this task from Incoming to Needs Prioritization on the Readers-Web-Backlog board.
Jdlrobson set the point value for this task to 0.Oct 29 2019, 4:23 PM
Jdlrobson renamed this task from [SPIKE, 16hrs] We should not need 178kb of JS and 10.8kb of CSS to render a blank page to [SPIKE, 16hrs] We should not need 164kb of JS and 4.89b of CSS to render a blank page in safemode.Oct 31 2019, 9:12 PM
Jdlrobson renamed this task from [SPIKE, 16hrs] We should not need 164kb of JS and 4.89b of CSS to render a blank page in safemode to [SPIKE, 16hrs] We should not need 164kb of JS and 4.89kb of CSS (gzipped) to render a blank page in safemode.
Jdlrobson updated the task description. (Show Details)

Change 547653 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[operations/mediawiki-config@master] Do not load page previews on Special:BlankPage

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

Conclusion

There are some small wins - T235796, T236943, T236946
We should arrange time to talk to the editing team about: T236944
and the maintainers of ULS (which offers the biggest opportunity - up to 26kb savings) about T237061. Given we are planning to make changes to the languages button, we could work on this alongside that activity. We may possibly want to explore sharing code between UniversalLanguageSelector and Page previews popup feature.

Even after all these optimisations, we will still be left with an additional 42.4kb of jQuery - we should talk to the performance team and frontend working group about the future of that. I am a little concerned that if we are told to build components in React.js we will be shipping React and jQuery together. However, this can wait till later.

Styles

Blank skin renders the following style modules:

  • ext.3d.styles (recommended fix in T235796)
  • ext.uls.interlanguage (T236943)
  • visualEditor.desktopArticleTarget.noscript (recommended fix in T236944)
  • ext.wikimediaBadges (recommended fix in T236946)

The following modules are loaded by all skins unless the skin opts out of it (e.g. Minerva). They are not worth worrying about right now:

  • mediawiki.legacy.commonPrint
  • mediawiki.legacy.shared
  • mediawiki.skinning.interface

This CSS is 5kb on its own. It likely requires audits of its own. Some of which are proposed in https://gerrit.wikimedia.org/r/546733

JS

For comparison, a vanilla MediaWiki instance loads 57.2kb of JavaScript. 42.4kb of this is jQuery. It seems strange to load jQuery unconditionally, and personally I would like to see us moving towards making jquery a dependency like everything else. It seems the only reason it isn't is because mediawiki.base uses jQuery for $.Deferred, $.ajax and $.Callbacks - I've moaned about this before in T200868 and would like to see a plan moving us in that direction.

So with 57.2kb as the minimum possible JS payload, lets' look at the rest...

Unavoidable

We want to check if somebody is logged in and to continue to support ResourceLoader there is no way to cut down the size of the startup module. Moving on..

Page previews

This is loaded via requestIdleCallback and avoidable using wgPopupsPageBlacklist see gerrit patch ). If we wanted to go further - we could not load page previews on pages without links on them, however this seems a little extreme. The code to ship this feature is warranted IMO.

The module loading at start (popups) is as minuscule as it can be.

VisualEditor

Recommendation: T236944
My gut says the module is probably larger than it needs to be, but this payload may be warranted if it's doing some kind of prefetching to improve edit speed later on. It is smaller than page previews and just as important. I defer to more knowledgeable people.

The rest of the JS: (110kb)

    1. CentralNotice
  • ext.centralNotice.geoIP
  • ext.centralauth.centralautologin

Analytics (data gathering)

  • ext.cx.eventlogging.campaigns
  • ext.eventLogging
  • navigationTiming
  • wikimediaEvents

These seem unavoidable since we need user data.

ULS

  • ext.uls.common
  • ext.uls.compactlinks
  • ext.uls.init
  • ext.uls.interface

*ext.uls.preferences

  • ext.uls.webfonts
  • jquery.uls.data

Disabling ULS saves 26kb after Gzip and in my opinion is where we can squeeze out most of the performance improvements. The ULS feature loads more JavaScript than Popups or VisualEditor feature. It's equally important, but given it requires a click to be displayed, it should be loaded later.

Libraries pulled in by above features

These modules relate to dependencies above. The only way to reduce these modules is to target improvements to Popups, ULS and VisualEditor.

  • jquery
  • jquery.client
  • jquery.cookie
  • jquery.textSelection
  • mediawiki.String
  • mediawiki.Title
  • mediawiki.Uri
  • mediawiki.api

*mediawiki.api.base

  • mediawiki.cldr
  • mediawiki.cookie
  • mediawiki.experiments
  • mediawiki.jqueryMsg
  • mediawiki.language
  • mediawiki.notify
  • mediawiki.storage
  • mediawiki.template
  • mediawiki.user
  • mediawiki.util
  • mediawiki.editfont.styles
  • mediawiki.libs.pluralruleparser
  • mediawiki.template.regexp
  • mediawiki.ui.button
  • user.defaults

Modules pulled in by skins

  • mediawiki.page.ready
  • mediawiki.page.startup

Change 547653 abandoned by Jdlrobson:
Do not load page previews on Special:BlankPage

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

Some really interesting findings here! I had some questions about how these were measured via slack but no need to hold up the sign-off process. Definitely seems like we could do some more lazy loading of ULS to save KB