Let’s explore our web performance data from an angle we haven’t explored before: mobile device type.
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.
Here is how we measure and interpret load times on Wikipedia. Let’s also look at what real-user metrics are, and how percentiles work.
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.
To understand why Thumbor is a good fit, it’s important to understand where it fits in our overall thumbnailing architecture. A lot of historic constraints come into play, where Thumbor could be adapted to meet those needs.
Thanks to a new web standard, we’ve recently deployed a small performance improvement that highlights some of the unique challenges we encounter on Wikimedia sites.
Making Thumbor production-ready for Wikimedia is a journey that started a year and a half ago. Let’s look at the rationale for this project.
Is it faster to save articles on Wikipedia than it was a year ago?
When a performance improvement seems too good to be true, it’s time to investigate in depth and find out what happened.
Over the past six months we deployed a new technology that sped up Wikipedia’s backend application, reducing the median page-saving time for editors from about 7.5 seconds to 2.5 seconds.