CentralNotice runs on every pageview, on (nearly?) every WMF wiki. This makes it a prime target for performance improvements. It also makes any CN performance issues especially important.
As part of the refactoring of campaign and banner selection code (T100686) we should determine exactly where the RL modules that provide this code should load (top or bottom) and when selection logic should execute (before or after the DOM is ready). See this patch for the most recent version the refactored code.
Previous (currently deployed) code is top-loaded but only executes after the DOM is ready. This seems likely not to be the best option.
We should seek the best overall performance, balancing the gains and losses we'd get in different scenarios. The scenarios to consider are the feasible combinations of following criteria:
- RL modules fetched from the server or from the LocalStoarge module cache.
- Possible campaigns available or not in ChoiceData.
- If there are possible campaigns available, campaign selected or not from ChoiceData.
- If a campaign is selected, banner selected and fetched or not. (Even if a campaign is selected, a banner might still not be selected for several reasons, including a hide cookie or a flag set by a campaign mixin.)
Here are some options 'n' constraints:
- No matter what, we should only load campaign and banner selection code if there are possible campaigns.
- No matter what, GeoIP code is ready to be separated out (see T102848), so it may be loaded in a different way and run at a different time.
- Selection code must run after GeoIP code.
- Selection code may be loaded as a dynamic dependency of ChoiceData, or via a call to mw.loader.load() in a script.
- Selection code may be in top- or bottom-loaded modules.
- Selection code may run right away, or only after the DOM is ready (called from a $( function ).)
- The request to fetch the banner content might happen right away, or only after the DOM is ready (called from a $( function ).)
- No matter what, the banner will only be inserted after the DOM is ready.
Suggestions on how to benchmark would be much appreciated, BTW.
- For the time, being we aren't considering the option of requiring banners to overlay page content. (That option that has been suggested, but so far, it hasn't received enough discussion do make it viable. Anyone interested in pursuing it: perhaps suggest a specific route for doing so?) So, we are concerned about possible page bumps when a banner is displayed (T107967).
- The solution we adopt may consider the possibility that in the future, GeoIP, device category and/or logged-in status may be made available in PHP (load.php endpoint), which would make client-side selection code smaller and require less users to run it. (See T103695.)
- Once implemented, we'll test real life performance changes, as per T107503.
- Banner controller refactoring notes
- Explanation of current banner and campaign selection process
- This patch, which demonstrates the bottom-loaded mw.loader.load() approach.
- This patch, which demonstrates the top-loaded ChoiceData-dynamic-dependency approach.
Proposal 1 (abandonded)
This proposal doesn't make sense, following RL queue changes in core. I'm just leaving it here for comparison purposes.
- Keep the GeoIP module top-loaded and continue to execute GeoIP processing right away.
- Make campaign and banner selection code bottom-loaded, but have it start processing as soon as it's loaded. (However, during a transition phase, it will be bottom-loaded but will wait for the DOM before executing most logic.)
- When a middle RL queue becomes available, move campaign and banner selection there.
- We may use animations and other means to minimize page bumps when banners are injected.
Proposal 2 (current)
- Keep all code async-top-loaded, and have all of it run right away (except stuff that needs the DOM to be ready). The code currently in master works this way.
- We may use animations and other means to minimize page bumps when banners are injected. Not implemented, requires further investigation.
- Investigate performance implications and possible needs for future changes, as per T107503.
See also the detailed rollout plan.