Page MenuHomePhabricator

Performance review of Wikipedia Preview
Closed, ResolvedPublic



Wikipedia-Preview is a standalone JavaScript component that allows external partners to show previews of Wikipedia articles on their sites. Similar to the page previews extension but for external sites.

Preview environment



Which code to review

Performance assessment

Please initiate the performance assessment by answering the below:

  • What work has been done to ensure the best possible performance of the feature?

We always keep an eye on the bundle size. The published bundle is minified and available in gzip format. The included SVGs have been optimized. We use no external libraries.

There's a loading state in place while the user is waiting for the API response.

  • What are likely to be the weak areas (e.g. bottlenecks) of the code in terms of performance?

Initial download of the bundle may be an issue on slow networks. We could consider breaking it down but we also need to consider the complexity for partners who are integrating it in their sites.

  • Are there potential optimisations that haven't been performed yet?

The style (CSS) could be more DRY. I hope this is addressed before the review. It should shave a few bytes.

The fullscreen gallery view uses heavy images. We need to look at the options for loading the smallest possible images that will look OK on the device.

We considered some pre-fetching of data on page load to make the previews instantaneous but that means more bandwidth being used for previews that may not be shown.

  • Please list which performance measurements are in place for the feature and/or what you've measured ad-hoc so far. If you are unsure what to measure, ask the Performance Team for advice:

No measurement in place yet. We don't know if any event logging will be possible so we can't plan for live performance measurements at this point. Any suggestions for other types of testing or static analysis would be much appreciated.

Event Timeline

Gilles triaged this task as Medium priority.
Gilles moved this task from Inbox, needs triage to Doing (old) on the Performance-Team board.

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.

Gilles changed the task status from Open to Stalled.Nov 4 2020, 10:13 AM

Changing the status since I haven't heard back about my initial feedback, feel free to make this task "Open" again once you've had a chance to respond to my questions.

SBisson changed the task status from Stalled to Open.Dec 16 2020, 4:49 PM

(Better late than never)

@Gilles this is great feedback. We've removed the localized wordmark SVGs from the bundle. These were by far the largest images. But we've kept the small icons. We see this as a compromise between bundle size and simplicity of development and deployment while this component is still experimental. The production bundle sits at 37kb currently. What do you think of that number? Is there a limit we should stay under?

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.

Remember that the links themselves belong to the partner's website, not Wikipedia Preview. We implemented like that on the demo site because the link decoration includes an icon that takes space so applying it when everything has loaded makes the text jump. However, actively checking if the cursor is on top one of those links when the component finishes loading would be a good functional improvement.

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:

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.

Gilles added a subscriber: Gilles.

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.

Krinkle edited projects, added Performance-Team (Radar); removed Performance-Team.
Krinkle added a subscriber: Krinkle.

I think our review can be considered done. We'd be happy to take another look after some of the changes have been put in place. I'll monitor this form our radar for now. Feel free to close in favour of any other tasks or keep it open to include the follow up work. Either is fine by me :)

See also: