Browser load and JavaScript research
 | This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date. |
Rough notes on Browser load concerns, and Clientside-JavaScript (?) questions.
Immediate to-do:
- Add overall-areas and questions that we should investigate now
- Add Specific metrics (time? memory?) we should track over the long-term.
- Add Links, if we're already are doing [some/all] of this somewhere
- Fix my terrible terminology misuses. :-) Very {Draft}. Please edit mercilessly.
End goal:
- To-do lists for analytics & developers
- Explanations for a lay-audience
Background
[edit]Over the years, and recently in person at Wikimania, I've heard comments that all the new (and accumulated old) tools/extensions/gadgets/etc, were making the client-side impact quite heavy, and the site more frustrating to use. Particularly for users with older hardware, or restricted corporate software-setups (old browsers), or poor-quality (erratic) internet connections.
Existing stats and research
[edit]- Something something graphite something?
- wikitech:Performance/Guides/Backend performance practices
- Site performance and architecture
- Architecture Summit 2014/Performance
Questions and Ideas for things to investigate or monitor
[edit]Ranked lists, in order of "Foo that causes the most page-load increase"
- Which preferences?
- Which gadgets?
- For example, syntax highlighting is fairly expensive, and the gadget is turned on by default at the Kannada Wikipedia (as of August 2016).
- Which extensions?
- Which lines in site.js?
- Which mediawiki-core features?
- ...
What are average page-loads for:
- anon user
- logged-in user, with default preferences
- logged-in user, with the 10 most popular Gadgets enabled
- ...
How does that change, given:
- Connection quality:
- broadband-connection,
- erratic connection,
- low-bandwidth-connection
- Browser variants (safari/chrome/firefox/IE/Opera)
- Old Hardware (old processor, small amounts of RAM, etc)
Why do some sites (like Trello) cause the browser to become sluggish when multiple tabs to it are open, and are we avoiding those problems?
- Hypothesis: The entire interface appears to be generated in JS upon page-load, and reflows/repaints the page for every card.
Desired outcomes
[edit]- Metrics. (bosses love metrics)
- Shiny graphs. (users love plummet/soaring graphs)
- long-term tracking. (devs love tracking)
- devs fixing the worst culprits. (priorities)
- better understanding for everyone, technical and non. (What we're here for)
- ponies. (tradition)
Notes
[edit]Wherein I trap devs against a wall, and demand explanations. (All errors from condensing and simplifying the developer mumblings, are probably my own. Quiddity (WMF) (talk))
- part 1
- "there are three kinds of "performance issues": there are
- a) things that actually run slow,
- b) things that are large and take a lot of time to download
- c) things that are loaded inefficiently
- (a) is uncommon. ULS was briefly an example of last year, because it was repainting (re-rendering) the flyout with every language addition. Nowadays, it doesn't render at all until completely loaded, hence no more screen freeze.
- (b) are things like navpopups and twinkle. Easy to measure.
- (c) in particular, scripts loaded with importScript() or some such from common.js (both user's and site), global gadgets loaded from meta or mw.org or whatever, and regular gadgets that don't use resourceloader. they are not minified by RL, and/or loaded in separate requests rather than with other scripts.
- tl;dr: look for importScript in site JS, and for gadgets without 'ResourceLoader' in their options. these are the things that take a long-ass time to load while they shouldn't.
See also
[edit]- phab:T105136 – Create a project to reduce page weight