Change Details

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 [[ https://gerrit.wikimedia.org/r/#/c/221759/ | 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. More notes: - 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. - 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.) See also: - [[ https://www.mediawiki.org/wiki/Extension:CentralNotice/Notes/Banner_controller_refactoring | Banner controller refactoring notes ]] - [[ https://www.mediawiki.org/wiki/Extension:CentralNotice/Campaign_and_banner_selection | Explanation of current banner and campaign selection process ]] - [[ https://gerrit.wikimedia.org/r/#/c/213990/ | This patch ]], which demonstrates the bottom-loaded mw.loader.load() approach. - [[ https://gerrit.wikimedia.org/r/#/c/217303/ | This patch ]], which demonstrates the top-loaded ChoiceData-dynamic-dependency approach.

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 [[ https://gerrit.wikimedia.org/r/#/c/221759/ | 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. More notes: - 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.) See also: - [[ https://www.mediawiki.org/wiki/Extension:CentralNotice/Notes/Banner_controller_refactoring | Banner controller refactoring notes ]] - [[ https://www.mediawiki.org/wiki/Extension:CentralNotice/Campaign_and_banner_selection | Explanation of current banner and campaign selection process ]] - [[ https://gerrit.wikimedia.org/r/#/c/213990/ | This patch ]], which demonstrates the bottom-loaded mw.loader.load() approach. - [[ https://gerrit.wikimedia.org/r/#/c/217303/ | This patch ]], which demonstrates the top-loaded ChoiceData-dynamic-dependency approach.

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 [[ https://gerrit.wikimedia.org/r/#/c/221759/ | 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. More notes: - 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.) See also: - [[ https://www.mediawiki.org/wiki/Extension:CentralNotice/Notes/Banner_controller_refactoring | Banner controller refactoring notes ]] - [[ https://www.mediawiki.org/wiki/Extension:CentralNotice/Campaign_and_banner_selection | Explanation of current banner and campaign selection process ]] - [[ https://gerrit.wikimedia.org/r/#/c/213990/ | This patch ]], which demonstrates the bottom-loaded mw.loader.load() approach. - [[ https://gerrit.wikimedia.org/r/#/c/217303/ | This patch ]], which demonstrates the top-loaded ChoiceData-dynamic-dependency approach.