For context, this work will benefit a large percentage of our visitors because we will be able to measure a key aspect of performance we were blind to before with Safari (the only browser that lacked that feature). About a quarter of our traffic comes from Safari. We (Wikimedia/Performance team) commissioned the work, but Noam did everything. Without something like Paint Timing the performance of Wikimedia site could degrade in terms of when things appear on the screen on Safari and we wouldn't have a way to know. Observability is critical to allow us to react to performance degradations, and to have confidence that new features deployed to Wikimedia sites don't impact performance negatively. While Apple wasn't against the idea of implementing Paint Timing themselves, it was never a priority for them and we could have waited for years for them to implemented it - if they ever did.
@alexhollender here it is: https://drive.google.com/file/d/1k_JfmtxXQS5OuAiE318hK-B-dqD0RHN9/view?usp=sharing this also includes non-wikipedia logos, but as you see in the change, only the wikipedia ones are getting touched at the moment.
@alexhollender we use the 1.5x and 2x variants for displays that haver higher pixel densities and for people who zoom on the page. The main goal is to keep the logo sharp on HiDPI/retina displays.
Wed, Jun 3
Tue, Jun 2
I can definitely review a patch.
It's waiting for someone to do it. @jijiki when she gets back from leave, possibly?
Thanks for implementing that, I tried it out on Beta and it works as expected. What are your thoughts on performance instrumentation of this feature and the custom metric I've suggested?
@dpifke has looked into this. Dave, can you share notes here about what you've tried and what you understand about this problem?
Thu, May 28
@Peter what do you want to do with this? Address this deprecation problem or retire PerformanceInspector altogether?
Taking another look at lossy optimisation, for the enwiki logo I think that most of the gains are coming from the fact that ImageOptim is converting it to a palette PNG instead of an ARGB one. That's why it's gaining so much (51% smaller than this latest lossless optimisation). Looking at what that means in terms of unique colors, we are indeed going from 3329 different colors to 252.
Moved the crontab to the analytics-privatedata user (was previously under mine), which has a keytab to access data behind Kerberos. And changed permissions of output directory and files accordingly.
Wed, May 27
Works as expected on Beta Commons. I don't expect any surprises when this goes to production.
Tue, May 26
Once this is proven successful in production, how difficult do you think it would be to adapt this code for it to work on Desktop as well? There are huge savings to be had there, and now that we have an efficient method for it, I think it would be a good time to make it work on both platforms.
Mon, May 25
@hashar why not add the libcurl package to releng/tox? libcurl being such a generic tool, this is bound to happen again for another python project.
Thu, May 21
Wed, May 20
Not a performance thing per se.
This isn't actionable until a specific use of this header is proposed. Eg. compressing images further would be counter-productive in our current architecture, because our thumbnails are rendered on the fly. What you'd save on data would increase latency because the desired low quality image is more likely to be uncached than regular ones.
It's much easier to find before/after runs in Grafana now.
Parent task is enough to keep track of this on its own.
@eprodromou what's the performance issue here? That's a PHP error.
Mon, May 18
I think the spirit of this task is to be more exhaustive (all non-printable icons, all production skins).
Fri, May 15
I think that I've fixed the display further, the format of the heatmap needed to be "Time series buckets". Looking good!
Thu, May 14
Wed, May 13
The preloading of the next page summary is nice. I think you could afford to preload the next image as well to avoid the image flashing in, which is even more visible due to the next not doing the same. The images are fairly small, it would be a reasonable tradeoff and in the spirit of what the current UX is trying to do with preloading.
@CBogen please add mine, "GDubuc (WMF)"