Perfherder has detected a browsertime performance regression from push 735440c1b4160453b1900fa7eda503880db4a7aa. As author of one of the patches included in that push, we need your help to address this regression.

Regressions:

Improvements:

Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests. Please follow our guide to handling regression bugs and let us know your plans within 3 business days, or the offending patch(es) may be backed out in accordance with our regression policy.

If you need the profiling jobs you can trigger them yourself from treeherder job view or ask a sheriff to do that for you.

For more information on performance sheriffing please see our FAQ.

28% loadtime improvement and 6% speedindex regression? This sounds fishy.

I'd be surprised if this was a real regression, indeed. We're doing strictly less work.

Set release status flags based on info from the regressing bug 1817360

Agreed with :emilio and :tnikkel - This was a spike around Mar 24, but subsequent data points snapped almost immediately back to the mean.

Yeah, and more importantly, the pageload improvement did stick. So yay :)

I took at look at the ContentfulSpeedIndex graph. It looks like it stays high. There were a large number of retriggers around the landing of bug 1817360, that looks like a spike, but the test is just noise-y. Before bug 1817360 the majority of runs were under the 900 line, and after the majority were over the 900 line.

I also downloaded the browsertime tgz before/after as well as looked at profiles with screenshots to get a better idea of what is going on. The loadtime win isn't really a win since we are drawing the page about the same or slightly later and the timing of the load event doesn't really correspond to much useful for the user here. So my theory here is that the eager broken image load was done earlier in page load when we were less busy. When we make it lazy it starts later so it contends with the painting and image load of the page, and for some reason the broken image loading seems to block drawing of the pages images, perhaps because this is a relatively lower power phone. Potentially if we wanted to improve our cold metrics we could investigate making the broken icon even more lazy, say by only loading it once a new process has gotten some idle time, and just drawing nothing until then. Safari doesn't have a broken image icon at all, just an outline, so should be fine to draw nothing temporarily.

Hm, you're right. The variance is high (Almost feels higher around the change, but that could be my brain making patterns), but the floor did go up.
Looks like perhaps ~2% regression (~20ms up), not 6%, though.

ni=emilio to take a look & see if the remaining difference seems real/concerning or not.

(Maybe we shifted some work around in a way that confused the benchmark?)

I don't think this is worth digging too much into, given the size of the regression. Another option is that the load event firing sooner made YT do more work before first paint.