Open Bug 1312645 Opened 6 years ago Updated 4 years ago

Regression in site render time during boot on Firefox 49

Categories

(Core :: Layout, defect)

49 Branch
defect
Not set
normal
20

Tracking

()

UNCONFIRMED
Tracking Status
platform-rel --- -
firefox49 --- wontfix
firefox50 - wontfix
firefox51 + wontfix
firefox52 + wontfix
firefox53 + wontfix
firefox54 --- wontfix

People

(Reporter: davem, Unassigned, NeedInfo)

Details

(Keywords: regression, Whiteboard: [platform-rel-Microsoft][platform-rel-Outlook])

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36



Actual results:

With the release of Firefox 49, we've noticed an increase of ~300ms in the time it takes to render the page for Outlook.com/Outlook Web App during boot/startup (this is purely the time it takes to render the DOM and doesn't include script downloads or other network requests). The first screenshot attached shows the increase in render time just for Firefox in the AppCache and NoCache boot scenarios. The second screenshot shows our total page load time on Firefox broken down by version 48 and 49 as well as the change in sample sizes for each version. Based on the trends we're seeing (where times substantially increase around 9/23 at the same time as v49 becomes the predominant version) we think this might be related to the latest Firefox release.
Maybe related to layout?
Component: Untriaged → Layout
Flags: needinfo?(bugs)
Flags: needinfo?(jduell.mcbugs)
Whiteboard: [platform-rel-Microsoft][platform-rel-Outlook]
platform-rel: --- → +
Flags: needinfo?(jduell.mcbugs)
[Tracking Requested - why for this release]:
Important performance regression, we should investigate before 49 goes live.
Of course, s/49/50/ in comment #2
[Tracking Requested - why for this release]: It may be too late to do this in 50 assuming the fix is external given the platform-rel flag on it. Let's plan to address this in 51.
Track 51+ as important performance regression.
Hi Astley,
Can you help shed some light here or find an owner for this?
Flags: needinfo?(aschen)
Rank: 20
By using gecko profiler to collect more info, it seems pretty hard to have stable result on same test scenario. If we want to break down which parts contribute this 300ms slow down on Firefox 49, we probably require a static site/test case so that it could be a lot easier to narrow down the regression window and push further for more clarification.

Dave, is it possible ? or is there any other way to give same test condition ?
Flags: needinfo?(aschen) → needinfo?(davem)
A test case would be helpful - this likely isn't going to be fixed for 51, though. 
I'm assuming 52/53 are also affected but am not certain.
And if we can measure it quickly enough, getting a mozregression to narrow down when this started showing up would be great.
Can somebody refresh my memory - when did we change the compiler version on Windows?  Because it may have been around 49, though it would be unfortunate if we traced the regression to that change.
(In reply to Milan Sreckovic [:milan] from comment #9)
> Can somebody refresh my memory - when did we change the compiler version on
> Windows?  Because it may have been around 49, though it would be unfortunate
> if we traced the regression to that change.

Bug 1186064 indicates 50 so thankfully uncorrelated :)

We really need a profile here. Dave, can you capture one in Firefox? Go to https://new.cleopatra.io/ and follow the instructions.
I'll look into getting a profile for this one.
Assignee: nobody → bugs
Flags: needinfo?(bugs)
I've emailed the reporter.
Looks like this is stalled on getting a profile, marking wontfix for 52.
This is months old and I don't think we need to track it anymore. If we get a profile or another report of this happening in recent versions then maybe the bug will be actionable.
Assignee: bugs → nobody
You need to log in before you can comment on or make changes to this bug.