You just need to make sure that any code you rely on that creates EventLogging events at the end of the page lifecycle do so with pagehide/pageshow and not unload/onbeforeunload. Then we should be able to safely remove the unload handler in EventLogging's BackgroundQueue.

Indeed, it's that simple. However, @Krinkle reminded me that our JS-enabled experience now excludes IE9-10: https://www.mediawiki.org/wiki/Compatibility#Browser_support_matrix Meaning that we don't need an unload event handler at all. All grade A browsers support pagehide/pageshow according to https://caniuse.com/page-transition-events

I think that only registering the unload handler for browsers that don't support pagehide makes sense. Those older browsers don't support bfcache anyway.

It hasn't been deployed, as far as I can see.

The code writing to that schema is still active in MediaWiki. I don't know if anyone is still consuming that data and in what form. It just seemed like measuring active editors is a pretty useful metric to keep. But not knowing who consumes it, if anyone, I don't have an opinion about what IP/geo context needs to be preserved.

I haven't checked what's causing the single-threaded behaviour. I presume it's happening in the evaluator, as you're probably running code on the main thread there?

I honestly have no idea, I've never looked at this data.

Solving this with a combination of a post-send queued job and JS-issued POST requests for the DB writes sounds like a fine solution.

Special:CreateZObject page

No, that's all I could find. It's not a gate, by the way, it's just best practice to have it done before deploying to production. Thank you!

Thank you very much for the thorough investigation and explanations, I agree that now the issue is well understood and the experiments can be removed.

-resize doesn't guarantee a 220 pixels wide image as output

A starting point - and possibly the only thing to do - is to add webp to that list:

I've looked at the code where the notification is created. Since you're correctly doing this in a DeferredUpdate, there shouldn't be any measurable impact on Save Timing. I don't think this extension required new metrics to be measured.

@AntiCompositeNumber pointed to the right comment. ImageMagick has limited options in that area. It's either a choice of always getting an exact width and a tiny percentage of the image being potentially cropped (what we do now) and always having the full picture but the width may vary by 1 pixel. Since the thumbnail width is expected to be a precise value in MediaWiki/wikitext, we decided to use the former.

The link to the code in the task description is broken for me: https://gerrit.wikimedia.org/r/mediawiki/extensions/TheWikipediaLibrary (Not found)

Is there an easier way to test this on Beta than making 100 edits manually?

Not that I know of, but that was still being debated at recent meetings

Confirmation from Michal of which code we should use: https://twitter.com/mmocny/status/1387161141097517067

It's great that we narrowed this down and confirmed it, excellent work! The change's claimed behaviour is definitely consistant with the change we observed in hit/miss ratio. What's upstream's take on making this behaviour configurable?

The data transfer waste is probably not that severe since HTML is gzipped and repetitive strings compress really well, but it's still waste. The Performance Team's position on these is that they serve little purpose and should be removed.

The whole system

From my perspective, yes, enough due diligence has been done on the performance front once that subtask has been completed. But the Performance Team doesn't decide what gets deployed to WMF production or not.

@ema the per-host dashboard is back!

The data is confirmed to make it to the NavigationTiming schema for browsers that support Server-Timing:

The subtask is the only actionable left from this review.

As @AntiCompositeNumber there will always be cases where the thumbnail weighs more than the original, whenever the original uses a more compact way of storing colors (such as black and white), because our thumbnail pipeline generates true color thumbnails.

Confirming that this header now gets saved in Swift for new files:

@ema I've just realised that the net was too wide. Chrome has "Safari" in its UA string, for example: