Page MenuHomePhabricator

Serve all Wikipedia Preview icons and images from
Open, Needs TriagePublic


To make the Wikipedia Preview bundle smaller and speed up time to interactive, all embedded SVG files should be moved to the config repo and served from

They should be placed in a wikipedia-preview-specific directory structure under static. This might mean some files will be duplicated from other directories but that's OK.

The only exception is the localized wordmark files. They are already served from no need to move them (or copy them) to a different directory.

Files can be added to the config repo by submitting a patch in gerrit and deploying it during a SWAT window.

This is a recommendation from T260913: Performance review of Wikipedia Preview

Event Timeline

Change 666680 had a related patch set uploaded (by Sbisson; owner: Sbisson):
[operations/mediawiki-config@master] Images for Wikipedia Preview

Will the JS itself also be hosted there? If not, you may want to serve it from wherever the script is so that you don't end up in a situation where you can't ever resize, rename or remove any file there ever just in case something somewhere uses a different version of the script.

Note that CSS supports relative path names (unlike JS) so that would naturally work and the directory would still be portable to upload wherever (e.g. github demo, official hotlink, or third-party embed selfhost).

@Krinkle that's an interesting idea. We've been promoting 3rd party self host so far but recently we've been talking about reducing friction as much as possible for partners so this would really help.

We're committed to backward compatibility so I'm not too worried about them using newer versions.

Would serving the script from here also cache it for 1 year?

I did not provide all context above.

We've been promoting self host. That was fine with the images inside the bundle since it's a single file but with the images extracted we cannot advice the partners to host all images and make sure it's all coming from the same path. That would be too much friction. But serving all of it from wp/static would be great as long as the script is not cached for too long without asking the partners to change the URL they are using.