The compressed bundle I see in the demo is 100kb, that seems like an excessive upfront cost for such as small feature. The bulk of the size is coming from base64-encoded images that are embedded in the CSS, itself embedded in the JS.

Is it done this way because partners want to self-host this feature with no "phone home" aspect that would happen if Wikimedia served some of the UI images? If not, the images referenced should simply be hosted by Wikimedia and the images referenced by URL in the CSS. This would allow the functionality to be active much earlier on the page by drastically reducing the initial bundle size, which would only contain JS and CSS, without embedded images.

If it's a concern that the UI images would only be loaded the first time the dialog is invoked, you could preload them in the background with low priority after the initial bundle has been downloaded. By separating things this way, it would allow for earlier interactivity.

Speaking of which, I see that the links are decorated from the original HTML, which invites interaction. If I leave my cursor on top of one of the links before the bundle has finished loading, nothing happens once it does, no popup appears. This seems like a scenario worth accounting for as it can affect users with slow connections.

37kb sounds a lot more reasonable, but what I'd like to know is why it needs to be bundled in the CSS and not hotlinked, with the images served from Wikimedia infrastructure. We do this for a number of icons: https://github.com/wikimedia/operations-mediawiki-config/tree/master/static

This would ensure better caching, and even caching across partners. And more importantly, it would mean that the images aren't blocking in the initial load of the feature.

You're absolutely right. The only reason we did that was for simplicity (much easier to embed the files than to manage SWAT deploys of the config repo). It is starting to be a hot topic with partners so I think we'll act on your advice here.

I'm a bit worried about tracking which products are using which images and the risk that they change under our feet. Do you know if there's something in place for that or would it be wise for us to have a "wikipedia-preview" directory with all our images even if it means duplicating some of them?

Yes, by all means, create a new folder hierarchy in /static/ for what you need! It's fine if you duplicate some existing icons for the purpose of this project. Your feature should get enough traffic to keep your icons hot in cache.

Hi @SBisson ! I'm getting a handle on the status of this and it seems there's been some activity on T273674 and I'm curious if there's anything else needed from Performance at this time that we should schedule for Q2 or later?

@greg I don't know if the performance team feels like they are done or would like to review this some more.

On our side, despite very slow progress, we appreciate the feedback already given and remain committed to seeing it through. Due to a change in strategy, the plan outlined in T273674 probably won't happen but the images will be extracted from the bundle as recommended.