This task is for CentralNotice code to fix the banner bump, that is, the jump in page content due to banners loading and being injected in the background.
The method proposed here to fix this issue is to use ESI (edge-side injection) in the simplest possible way, in the Varnish layer, to add banners directly to the base HTML.
Banner content would be retrieved via a call to Special:BannerLoader, made from Varnish. Responses from that page would be deterministically based on the contents of a cookie, which would be set by client-side code on the previous pageview. The cookie would contain at least the name of the banner to be injected and the campaign associated with it, though it could also be configured to include additional targeting data points, depending on cache capacity. (Those additional data points are not hard requirements for this approach, but they would help make the system fully responsive to changes in campaign and banner settings.)
In addition to allowing banner content to be fully deterministic based on cookie content, this method would require relatively little new code, compared to other possible approaches to fixing the banner bump, since existing CentralNotice client-side code would continue to do the heavy lifting of banner selection, as occurs in the current system. We would run basically all existing client-side code and would retain all existing features for banner selection, impression limiting, data reporting, large-then-small banners, A/B testing, other banner sequences, banner hiding, etc. From the perspective of client-side code, the main difference would be that, instead of loading and injecting a banner, a cookie would be set to request banner injection by the cache on the user’s next pageview.
The main disadvantage of this approach is that banners would only be shown the second time a user visits the site, over the course of an active campaign that targets the user.
It is possible that for certain campaigns, the lack of a banner on the first pageview could significantly affect the campaign. At this writing, without having looked at the data, we can only guess which types of campaigns would be most impacted, and to what degree.
While we can never know for sure when a user will return to the site, we can probably guess the likelyhood of them returning over the course of a campaign by looking at how long it's been since their last visit. This data point is available in the WMF-Last-Access cookie.
To minimize the risk to any campaign due to the lack of a banner on the first pageview, we can include a feature to revert to the old system, and inject a banner client-side on the first pageview, if a user seems unlikely to return before the campaign ends. Also, if there exist other circumstances that cause problems for this system, and that can be detected on the server or on the client, those circumstances could also trigger the old first-pageview injection system (for example, viewing the site inside an app other than a browser, on mobile). While this would still cause a banner bump on a small number of pageviews, the overall gains in site usability would still be extremely significant.
For campaigns that **must** show a banner on every pageview (like maintenance or blackout campaigns) we can also revert to the old system. A follow-on feature could add a new setting to always inject banners server-side for such "every pageview" campaigns. This should work fine, since such campaigns don't use randomness or data stored on the client, and all basic targeting information is available server-side (though some extra work may be required to get that information to the code that needs it).
//(Note: I am working on this on my own time, so, not as part of my work as an FR-Tech engineer. Unless otherwise noted, this task is not included in planned work by FR-Tech. Please consider my contributions here as you would those of a volunteer contributor. Thanks so so much!! - @AndyRussG)//