I noticed page loads felt a bit sluggish after the 1.26wmf22 deploy so I poked around. The CSS in <head> seemed a lot larger than I remembered it being. Unfortunately, the two sources we have for tracking the size of static asset payload size over time only measure anonymous page-views. So I rolled back Echo to the 1.26wmf21 branch on testwiki and compared the size of CSS in <head> to its size when Echo is on 1.26wmf22. I found a fivefold increase in the size of uncompressed CSS.
| 1.26wmf21 | 1.26wmf22 | Percent increase | |
|---|---|---|---|
| Uncompressed size | 73 kB | 378 kB | 418% |
| Compressed size | 14 kB | 43 kB | 231% |
(Both measurements are relevant, because the performance impact of CSS is not just a function of the time it takes to retrieve it, but also of the time it takes to parse it and apply it to the DOM.)
This has had a substantial impact on page load times for logged-in users:
I think the right thing to do is to revert and spend a bit of extra time working out the performance footprint before rolling this out again.
Echo is a wonderful extension which editors use and love, and it is very good to see it get a second-wind of development activity. Please do not feel discouraged or blamed.
The performance team is going to do a postmortem of this deployment to figure out how to ensure our monitoring and testing infrastructure flags such regressions in the future. Let's work together to make this a learning experience for us as an engineering community.
