We’re taking part in the ongoing Event Timing Chrome origin trial, in order to experiment with that API early and give feedback to its designers.
When we set out to ask Wikipedia visitors their opinion of page load performance, our main hope was to answer an age-old question: which RUM metric matters the most to users? And more interestingly, which ones matter the most to our users on our content.
Unlike most websites, Wikipedia and its sister projects are ad-free. This is actually one of the reasons why our performance is so good. We don’t have to deal with slow and invasive third-parties.
We’ve recently published research on performance perception that we did last year. The micro survey used in this study is still running on multiple Wikipedia languages and gives us insights into perceived performance.
Today we’re publishing our first report of the performance experienced by visitors of Wikimedia websites, focused on the Autonomous Systems visitors are connecting from.
Should we be skeptical of performance guidelines which state that 100 milliseconds feels instantaneous to everyone?
Machine learning is a powerful tool, but it’s easy to use it incorrectly and draw biased conclusions, as we’ll show in this real world example.
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.
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.