Maintaining and improving one of the largest websites in the world using Open Source software requires a continuous commitment. The site is always evolving, so for every new component we want (or need!) to deploy, we need to evaluate the Open Source solutions available.
One of the main aims of Wikidata is to represent knowledge in a way that is computable—that is, amenable to automatic processing. Wikipedia already contains a lot of information; much of it is reasonably easy for a human to understand—though some of the more esoteric bits are decidedly not—but it’s not at all readily crunchable by a computer.
WikimediaDebug is a set of tools for debugging and profiling MediaWiki web requests in a production environment. WikimediaDebug can be used through the accompanying browser extension, or from the command-line. This post highlights changes we made to WikimediaDebug over the past year, and explains more generally how its capabilities work.
The Coolest Tool Award acknowledges projects and with that, all the people who have been contributing to those projects — primarily the developers and maintainers, and the people who help with documentation, translation, feedback, technical advice, design or communication.
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.