To the person who is assigned this ticket - Please note that I wrote step-by-step instructions for how I've been adding synthetic tests in my offboarding document at https://docs.google.com/document/d/13NypRIkc3-jOFNR6wTOnMfUXMjL11ny5OiyX4XulDK4/edit#heading=h.a26i7l3crf5f under the heading "Comparative synthetic tests" that I hope you will find helpful

@pmiazga's dared me to write a blog post about this experience during our super happy dev time meeting, so it's at https://www.nray.dev/blog/300ms-faster-reducing-wikipedias-total-blocking-time/ 🙂

I've reassigned this to Mo to reflect our above discussion ^^. Unfortunately, it doesn't appear that I have the ability to add myself as the "Other assignee":

• Write a proposed set of basic web team-centric performance SLOs

@Etonkovidova Thank you so much for leading this! 🎉

Discussed the remaining work on this with @Mabualruz, and we decided that he will create the necessary tickets (e.g. adding metrics to Grafana Dashboard, creating alerting, etc) for future work related to our proposed performance budget:

@Mabualruz and I met today to discuss remaining work on this and decided that @Mabualruz will lead the remaining work on this ticket with me transitioning to more of a support role :

Sorry for the noise everybody. This ticket is no longer needed.

Hey @Peter, that all sounds great to me and love the name Wikipedia Web Vitals. We don't have any performance SLOs right now.

I think this work resulted in a ~50% reduction in JavaScript execution time for the task on long pages like the "Barack_Obama" page which represents around ~260ms improvement in Total Blocking Time on the Moto G (5) phone that our synthetic tests use:

• Talk to designer about whether it should be replaced with indicators. Create a ticket if necessary.

Related to T329397

Looks like this is caused by a memory error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 1662976 bytes) but only on master. It doesn't occur on 1.41.0-wmf.5. It was hanging because we assumed mw was present in moduleReady.js. https://github.com/wikimedia/pixel/pull/187 should at least fix that problem

In Toggler.js, there was a small block of JavaScript that wasn't working correctly and was taking ~250ms to execute on my xiaomi redmi 9a phone. Therefore, I'm removing it in https://gerrit.wikimedia.org/r/908333. For long pages like the "United_States" page, this small step cuts the task's JS execution time by nearly half.

Should now be resolved by https://github.com/wikimedia/pixel/pull/185

Should now be resolve by https://github.com/wikimedia/pixel/pull/185

Before (with client preferences disabled and the inline script removed)
After (with 20 client preferences stored in a cookie)

Scheduled a meeting for this Wednesday with @Mabualruz and @Edtadros to go over the synthetic testing

Data has started to roll in from the synthetic tests:

Static pages have been deployed and tests have been merged. I'm not seeing anything on the graphs yet — I'm asking Peter about this now, but I'm leaving this ticket in code review so that someone else on the web team can become a bit more familiar with the synthetic testing process. I'm happy to meet and discuss these changes!

Thank you @Edtadros, great write up!

I reviewed the real user monitoring (RUM) we have in place for loadEventEnd and domComplete and didn't notice any obvious spikes:

Moved this to block to wait for deployment date. When ready, the patches associated with T331657 should be backported first, followed by the config change to enable page tools for anons