Some notes from yesterday's meeting:

• Page rendering is indeed blocked until top-loaded RL modules are fetched (either from the server or LocalStorage) and executed.
• We definitely don't want to keep the current setup of top-loaded modules that don't do most of their stuff until the DOM is ready!
• For now, we'll move processing to bottom-queue modules. Once a middle queue (earlier loading and execution than the bottom queue, but asynchronous) is implemented, processing will move there.
• For now, GeoIP processing will move together with the CN modules. window.Geo will stay available for legacy access, but we'll have a new mw.geoIP.getGeo() function (or something like that). Location info will be available later than it now is, since that's the one thing that bannerController currently processes right away. Nonetheless, we'll try this and see how it goes!

Unless I'm mistaken, moving a module to a different queue only will take effect when the Varnish cache clears, so it'll take a full month to complete any switch.

If there are no objections to this approach, maybe let's make a detailed RL-module-adding-and-switching roadmap that includes the addition of new modules and the removal of GeoIP from CN?

Another note from the meeting: while we don't expect to require banners to overlay content or animate, we may provide facilities to help mitigate page bumps. Here's a possible approach:

• Use a timer to see check how long it takes for the banner to be ready to insert.
• Whenever the banner is ready, wait for the browser finish the current execution queue (setTimeout(fn, 0)), and check if page is scrolled such that the banner will be visible.
• If the banner was ready quickly and the page is scrolled such that the banner will be visible, just insert it.
• If the banner took a long time to be ready and the page is scrolled such that the banner will be visible, insert it using an animation that gradually moves the rest of the page down.
• If the page is scrolled such that banner won't be visible, insert it and adjust the scroll position to prevent the page from jumping.

Do we have any idea how much this is likely to delay banner display on average? 'Page bump' has been one of the most consistent community complaints about CentralNotice, and there's been a lot of previous work to reduce it. It may be a worthwhile tradeoff though if a small delay means improving performance for everyone else (which I think is the aim?)

Also worth bearing in mind: fundraising banners use javascript to insert themselves right at the top of the screen, unlike most other banners.

In T106577#1484585, @Pcoombe wrote:

Do we have any idea how much this is likely to delay banner display on average? 'Page bump' has been one of the most consistent community complaints about CentralNotice, and there's been a lot of previous work to reduce it.

Hi! Since the whole campaign and banner selection system currently only runs after the DOM is ready, I don't think we'll actually increase banner display time much by moving the CN RL modules to the bottom queue. Also, this will be a temporary measure, while we wait for the "middle queue" to be implemented and deployed (expected this quarter).

It may be a worthwhile tradeoff though if a small delay means improving performance for everyone else (which I think is the aim?)

Yes! Currently, the time taken to load CN RL modules and perform initial processing (i.e., the bits of logic that are not delayed until the DOM is ready) actually blocks page rendering for everyone, all the time. The only caveat is that for most returning users, that's still quite fast, since the modules can be loaded from a LocalStorage cache rather than from the server.

Also worth bearing in mind: fundraising banners use javascript to insert themselves right at the top of the screen, unlike most other banners.

Great point, thanks! Yeah, that complicates a bit how we should implement any trickery to detect and, if necessary, mitigate page bumps, though I think the trickery will still be possible.

Proposal:

• Keep GeoIP top-loaded.
• Only move CN display logic to before the DOM is ready as a final rollout step, to keep the changes as incremental as possible.

Detailed rollout proposal here.

This looks great, from what little I understand :D Maybe add a few words about how we plan to test for performance regression, and give current benchmarks?

Added a proposal to the task description...

+2, I think it's a good balance. We're certainly not going to make page load any slower with this refactor, and we're in a great position to experiment with dependencies and stuff.