Phame Blogs The speed of thought
The speed of thought
Posts from the Performance Team at Wikimedia

Why performance matters

Written by Imarlier on Wed, Dec 12, 4:21 PM.

There are practical reasons that web performance matters. From a user perspective, a site that’s slow results in frustration, annoyance, and ultimately a preference for alternatives. From the perspective of a site operator, frustrated users are users who aren’t going to return, and that makes it more difficult to accomplish your mission (be it commercial or public service). Optimizations keep people happy, keep them coming back, and keep them engaged[1].


Machine learning: how to undersample the wrong way

Written by Gilles on Oct 15 2018, 1:37 PM.

For the past couple of months, in collaboration with researchers, I've been applying machine learning to RUM metrics in order to model the microsurvey we've been running since June on some wikis. The goal being to gain some insight into which RUM metrics matter most to real users.


Best friends forever

Written by Peter on Oct 3 2018, 9:43 AM.

We use both synthetic and RUM testing for Wikipedia. These two ways of testing performance are best friends and help us verify regressions. Today, we will look at two regressions where it helped us to get metrics both ways.


Performance testing in a controlled lab environment - the metrics

Written by Peter on Sep 21 2018, 7:49 AM.

One of the Performance-Team responsibilities at Wikimedia is to keep track of Wikipedias performance. Why is performance important for us? In our case it is easy: We have so many users and if we have a performance regression, we are really affecting people's lives. Maybe you remember our hiring tweet from a couple of years ago?


Mobile web performance: the importance of the device

Written by Gilles on Jun 22 2018, 2:19 PM.

This week at our team offsite in Dublin, I looked at our performance data from an angle we haven't explored before: mobile device type. Most mobile devices expose their make and model in the User Agent string, which allows to look at data for a particular type of device. As per our data retention guidelines, we only keep user agent information for 90 days, but that's already plenty of data to draw conclusions.


Thumbor support for private wikis deployed

Written by Gilles on Feb 22 2018, 10:34 AM.

Yesterday we deployed Thumbor support for Wikimedia-hosted private wikis. While 99.9% of our traffic is for public-facing wikis, the Wikimedia Foundation hosts a number of private MediaWiki instances on the same infrastructure. Those wikis facilitate work for various groups in the movement, from community-run projects like OTRS, to local chapters, staff or the board. They're essential to the Wikimedia Movement, but by being private they're an architectural special case.


Measuring Wikipedia page load times

Written by Krinkle on Jan 9 2018, 6:25 PM.

This post shows how we measure and interpret load times on Wikipedia. It also explains what real-user metrics are, and how percentiles work.


The journey to Thumbor, part 3: development and deployment strategy

Written by Gilles on Nov 20 2017, 12:42 PM.

In the last blog post I described where Thumbor fits in our media thumbnailing stack. Introducing Thumbor replaces an existing service, and as such it's important that it doesn't preform worse than its predecessor. We came up with a strategy to reach feature parity and ensure a launch that would be invisible to end users.


The journey to Thumbor, part 2: thumbnailing architecture

Written by Gilles on Nov 17 2017, 3:17 PM.

Thumbor has now been serving all public thumbnail traffic for Wikimedia production since late June 2017.


The journey to Thumbor, part 1: rationale

Written by Gilles on Jun 20 2017, 3:33 PM.

We are currently in the final stages of deploying Thumbor to Wikimedia production, where it will generate media thumbnails for all our public wikis. Up until now, MediaWiki was responsible for generating thumbnails.


Looking back: improvements to edit save time

Written by Gilles on Jun 12 2017, 9:32 AM.

The WMF's financial year and its annual plan are coming to an end, and one of the Performance team's goals this past year was to reduce the amount of time it takes to save an edit on a wiki.


Improving time-to-logo performance with preload links

Written by Gilles on Jun 7 2017, 7:38 AM.

One of the goals of the Wikimedia Performance Team is to improve the performance of MediaWiki and the broader software stack used on Wikimedia wikis. In this article we’ll describe a small performance improvement we’ve implemented for MediaWiki and recently deployed to production for Wikimedia. It highlights some of the unique problems we encounter on Wikimedia sites and how new web standards can be leveraged to improve performance.


Investigating a performance improvement

Written by Gilles on Jun 2 2017, 10:02 AM.

Last week @Jdlrobson pinged me by email about a performance improvement his team noticed for large wiki articles on the mobile site in our synthetic tests run on WebPageTest. The improvement looked like this, a sudden drop in SpeedIndex (where lower is better):

About The speed of thought

As the Wikimedia Foundation’s Performance Team, we want to create value for readers and editors by making it possible to retrieve and render content at the speed of thought, from anywhere in the world, on the broadest range of devices and connection profiles.