1969857 - 12.28 - 5.38% espn loadtime / bild-de LastVisualChange + 2 more (Android) regression on Mon May 19 2025

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Treeherder Bug Filer]

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

Please acknowledge, and begin investigating this alert within 3 business days, or the patch(es) may be backed out in accordance with our regression policy. Our guide to handling regression bugs has information about how you can proceed with this investigation.

If you have any questions or need any help with the investigation, please reach out to [e-mail]. Alternatively, you can find help on Slack by joining #perf-help, and on Matrix you can find help by joining #perftest.

Regressions:

Ratio	Test	Platform	Options	Absolute values (old vs new)
12%	espn loadtime	android-hw-a55-14-0-aarch64-shippable	warm webrender	499.96 -> 561.36
8%	espn loadtime	android-hw-a55-14-0-aarch64-shippable	fission warm webrender	523.54 -> 566.60
8%	espn loadtime	android-hw-a55-14-0-aarch64-shippable	warm webrender	508.36 -> 546.61
5%	bild-de LastVisualChange	android-hw-a55-14-0-aarch64-shippable	warm webrender	1,681.20 -> 1,771.71

Improvements:

Ratio	Test	Platform	Options	Absolute values (old vs new)
5%	bild-de loadtime	android-hw-a55-14-0-aarch64-shippable	warm webrender	831.54 -> 789.83

Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests.

If you need the profiling jobs you can trigger them yourself from treeherder job view or ask [e-mail] to do that for you.

You can run all of these tests on try with ./mach try perf --alert 45313

The following documentation link provides more information about this command.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

It has been over 7 days with no activity on this performance regression.

:jajohnson, since you are the author of the regressor, bug 1961377, which triggered this performance alert, could you please provide a progress update?

If this regression is something that fixes a bug, changes the baseline of the regression metrics, or otherwise will not be fixed, please consider closing it as WONTFIX. See this documentation for more information on how to handle regressions.

For additional information/help, please needinfo the performance sheriff who filed this alert (they can be found in comment #0), or reach out in #perftest, or #perfsheriffs on Element.

For more information, please visit BugBot documentation.

Comment 3

[Greg Mierzwinski [:sparky]]

:fbilt, can you double-check the regression culprit here? I noticed that there's a commit in between where the android build failed and it's more likely to be the culprit: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&searchStr=espn&tochange=e5b599370ade4fd1fac7cbe07791c4f8159cc959&fromchange=a1228bfde2135b583671e235c62e7f3be7cdb129

This push specifically: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&searchStr=android&revision=eb4983d54abd883010eb9799045c5acf848bf3e7

Comment 4

[Florin Bilt]

I just finished the bisection process, and it seems that the regression was caused by the revision flagged by you.
Apologies for the confusion.
I will change the regression by field.

Comment 5

[Donal Meehan [:dmeehan]]

:farre, there is little time to fix this since the final beta builds tomorrow. Appreciate if you could take a look?

Comment 6

[Andreas Farre [:farre]]

I'll have to look at this closer, but immediately this feels strange since the regressing bug's patch is behind a pref.

Comment 7

[Andreas Farre [:farre]]

Does someone know if perfherder runs with the navigation API pref on?

Comment 8

[Aaron Train [:aaronmt]]

I'm unfamiliar with Perfherder environment. I assume someone on #perf-help would know. Moving this to Core.

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 10

[Andreas Farre [:farre]]

I started a performance comparison with SHIP off for android to see if we get the performance back. If that's the case, this performance regression is the same as bug 1968988

Comment 11

[Donal Meehan [:dmeehan]]

Thanks. If that's the case, we can set the regressor correctly (Bug 1951246) and mark Fx140 as disabled.

Comment 12

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Setting to S2 as same as bug 1968988.

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

It has been over 7 days with no activity on this performance regression.

:kaya, since you are the author of the regressor, bug 1951246, which triggered this performance alert, could you please provide a progress update?

If this regression is something that fixes a bug, changes the baseline of the regression metrics, or otherwise will not be fixed, please consider closing it as WONTFIX. See this documentation for more information on how to handle regressions.

For additional information/help, please needinfo the performance sheriff who filed this alert (they can be found in comment #0), or reach out in #perftest, or #perfsheriffs on Element.

For more information, please visit BugBot documentation.

Comment 15

[Kaya [:kaya]]

The issue seems to be happening due to bfcache in parent. I am still debugging the flow. (as in Bug 1968988)

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

It has been over 7 days with no activity on this performance regression.

:kaya, since you are the author of the regressor, bug 1951246, which triggered this performance alert, could you please provide a progress update?

If this regression is something that fixes a bug, changes the baseline of the regression metrics, or otherwise will not be fixed, please consider closing it as WONTFIX. See this documentation for more information on how to handle regressions.

For additional information/help, please needinfo the performance sheriff who filed this alert (they can be found in comment #0), or reach out in #perftest, or #perfsheriffs on Element.

For more information, please visit BugBot documentation.

Comment 17

[Hsin-Yi Tsai (she/her)[:hsinyi]]

Adjusted the severity given it's currently disabled, though it's still a high priority we're actively working on.

Comment 18

[[:owlish] 🦉 PST]

Hi Andreas, just to make sure: was it confirmed by your comparison that SHIP was the problem? (just looking at the discussion here, it seems like the the regressor bug was changed to the SHIP one 3 minutes after your message, but I can't tell if the comparison was finished by then, and also I cannot seem to be able to see the results of the comparison now) Thanks!

Comment 19

[Andreas Farre [:farre]]

I can't recall, I'll have to defer to kaya or smaug. The thing I can say is that this has nothing to do with the commit indicated in comment 3, since that code is preffed off.

Comment 20

[[:owlish] 🦉 PST]

Hey folks, I checked this (try pushes: recent rebase and the recent rebase with SHIP on), and it looks like SHIP is not at fault here. The espn and build-de failures appear as intermittent in both cases. I think this bug has nothing to do with SHIP.

Comment 21

[Olli Pettay [:smaug][[e-mail]]]

This is definitely not the bug I've been looking at when it comes to SHIP. loadtime isn't very useful metric.

Comment 22

[[:owlish] 🦉 PST]

Thank you for the clarification, Olli! I cleared the regression field, because this is not related to SHIP.

Comment 23

[[:owlish] 🦉 PST]

I removed Kaya from assigned because as this does not seem to be related to SHIP, Kaya should not be working on this.

Comment 24

[Randell Jesup [:jesup] (needinfo me)]

To be honest, loadtime as a metric is almost totally worthless; random timing issues can cause later requests to be in the load group, and if so they extend loadtime, sometimes significantly, with little or no user impact other than the loading indicator stays on longer