Page MenuHomePhabricator

Grafana graphs show spike in production `lastVisualChange` since 3/30/2021
Closed, ResolvedPublic

Description

Our grafana graphs are showing a ~600 ms increase in the lastVisualChange metric for the Obama page and the Facebook production page on en wiki since March 30, 2021:

Screen Shot 2021-04-13 at 5.39.33 PM.png (912×4 px, 445 KB)

Interestingly enough, I observed infobox related reflows on both pages when the page loads. Here is a gif I recorded of the Obama page reflow:

2021-04-13 17.38.03.gif (1×2 px, 1 MB)

Here is a gif I recorded from the Facebook page:

2021-04-13 17.49.43.gif (1×2 px, 385 KB)

Acceptance criteria

  • Reflows are absent from Obama and Facebook pages. lastVisualChange spike dissipates.

Event Timeline

nray updated the task description. (Show Details)

That's probably a reasonable guess. The full edit set was this one. That change was motivated because I pushed all the inline CSS into Common.css and out of the module. When I pushed the module live I got immediate sadness offwiki about the headers being left rather than centered on mobile (there might have been other minor complaints but that one was of most interest) and that was the minimum edit to correct. (Yes, I did experience the reflow as well; I figured it would be tolerable if suboptimal.)

The reason there are the number of selectors is because I'm looking to a future when infoboxes aren't tables (or at least, not entirely tables).

If you want to pull similar CSS into whatever dark magic CSS you have on the Minerva/MF side since I'm pretty sure you keep at least some infobox styles there, that'd be cool with me.

This seems to be a side-effect of not addressing T190083: Make MediaWiki:Mobile.css render-blocking

Common.css (desktop) is treated by ResourceLoader as a primary stylesheet. Like the native layout of the skin, it renders before the article appears.

The Mobile.css is instead registered as a "second-class citizen", intentionally left in a defect state where it causes performance problems (such as additional repaints, layout shifts, and a later loadEventEnd) so as to encourage use of TemplateStyles. While I generally agree with the direction to use TemplateStyles where possible, I think we've reached a state on most wikis where everything that can be moved has been moved.

Perhaps now is the right time to re-evaluate T190083 and actually trust to community to use it wisely (with us standing by to guide them if we spot misuse). Both to allow for cases where TemplateStyles can't be used, as well as as optimisation where it is actually more performant than TemplateStyles. Infobox styles, for example, are on virtually every page load, and seems to me like one of the few things that would benefit from shared caching instead of downloading again and again on every article.

(Infobox is being moved, there are just some 5.5k uses in the wild to take care of.)

Jdlrobson claimed this task.

We are back to normal now on those graphs. We can continue conversation on T190083.