Closed
Bug 1383593
Opened 7 years ago
Closed 7 years ago
Noticeable delay when opening of first new tab if activity stream is enabled
Categories
(Firefox :: New Tab Page, defect, P2)
Firefox
New Tab Page
Tracking
()
RESOLVED
FIXED
Firefox 58
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox56 | --- | disabled |
firefox57 | + | fixed |
firefox58 | --- | fixed |
People
(Reporter: marco, Assigned: Mardak)
References
Details
(Keywords: regression)
Attachments
(9 files, 1 obsolete file)
(deleted),
video/webm
|
Details | |
(deleted),
text/x-review-board-request
|
k88hudson
:
review+
ritu
:
approval-mozilla-beta+
|
Details |
(deleted),
video/webm
|
Details | |
(deleted),
video/x-flv
|
Details | |
(deleted),
video/x-flv
|
Details | |
(deleted),
video/webm
|
Details | |
(deleted),
video/mp4
|
Details | |
(deleted),
video/mp4
|
Details | |
(deleted),
video/webm
|
Details |
The first time you open a new tab in a new window there is a noticeable delay. This is a recent regression. Could it be related to the fact we disabled the preallocated content process?
Assignee | ||
Comment 1•7 years ago
|
||
What part is slow? The opening of the tab? Or does the tab show up blank and fills in content? If the latter, it's probably because preloading of about:newtab doesn't happen until the second tab. You can simulate it for all new tabs by turning off browser.newtab.preload.
Reporter | ||
Comment 2•7 years ago
|
||
(In reply to Ed Lee :Mardak from comment #1) > What part is slow? The opening of the tab? Or does the tab show up blank and > fills in content? > > If the latter, it's probably because preloading of about:newtab doesn't > happen until the second tab. You can simulate it for all new tabs by turning > off browser.newtab.preload. It's the latter. If I disable "browser.newtab.preload", all new tabs are opened blank and then filled.
Assignee | ||
Comment 3•7 years ago
|
||
Sounds like we want bug 1353013 to have the first about:newtab quick too.
Depends on: 1353013
Assignee | ||
Comment 4•7 years ago
|
||
When you say regression, this is relative to tiles? If you turn off activity-stream via `browser.newtabpage.activity-stream.enabled` and preload=false, there's a more noticeable delay?
Reporter | ||
Comment 5•7 years ago
|
||
(In reply to Ed Lee :Mardak from comment #4) > When you say regression, this is relative to tiles? If you turn off > activity-stream via `browser.newtabpage.activity-stream.enabled` and > preload=false, there's a more noticeable delay? The delay is less noticeable with Activity Stream disabled.
Reporter | ||
Comment 6•7 years ago
|
||
The delay is there actually also if "browser.newtab.preload" is set to true and you open multiple new tabs. It is more noticeable with preload set to false, but it's there anyway. Without activity stream, I see no delay whatsoever.
Reporter | ||
Updated•7 years ago
|
Keywords: regression
Summary: Regression in first opening of a new tab in a new window → Noticeable delay when opening of new tabs if activity stream is enabled
![]() |
||
Comment 8•7 years ago
|
||
(In reply to Marco Castelluccio [:marco] from comment #0) > The first time you open a new tab in a new window there is a noticeable > delay. This is a recent regression. > > Could it be related to the fact we disabled the pre-allocated content process? I can reproduce this, and browser.newtab.preload must be true to do so. (Win 7, nightly) STR: 1) ctrl-w to open a new window 2) ctrl-t 3) visually time the content fill-in 4) goto 2 The first tab is noticeably slower to render compared to subsequent tabs. With browser.newtabpage.activity-stream.enabled set to false you get the old tab page. Not really relevant. I'm guessing this is going to be hard to optimize especially this late in the game. Peter can you comment? [Tracking Requested - why for this release]: Potential 57 blocker related to content rendering performance of the new tab page
tracking-firefox57:
--- → ?
Flags: needinfo?(pdehaan)
Updated•7 years ago
|
status-firefox56:
--- → disabled
status-firefox58:
--- → affected
status-firefox-esr52:
--- → unaffected
Assignee | ||
Comment 9•7 years ago
|
||
When this bug was initially filed, prerendering bug 1398819 had not landed. Things should be better with that, but as per comment 8, it's still noticeable for the very first about:newtab loaded in a window.
Comment 10•7 years ago
|
||
I definitely see a subtle difference in the first newtab loaded vs subsequent ones in the same window (in FF Nightly on macOS).
Flags: needinfo?(pdehaan)
Reporter | ||
Comment 11•7 years ago
|
||
What would it take to preload the Activity Stream page when about:home is loaded too, instead of just about:newtab? This would make the first newtab as fast as the second newtab opened.
Assignee | ||
Comment 12•7 years ago
|
||
(In reply to Marco Castelluccio [:marco] from comment #11) > What would it take to preload the Activity Stream page when about:home is > loaded too, instead of just about:newtab? That was the original approach and idea from mconley with Bug 1353013 - Kick off preloading about:newtab at a better time β¦ but then after some investigation, it became Bug 1353013 - Be less aggressive about preloading about:newtab mconley, thoughts on comment 11?
Flags: needinfo?(mconley)
Assignee | ||
Comment 13•7 years ago
|
||
Looking closer at the original prototype patch from dao that effectively does what marco suggested in comment 11: Bug 1353013 comment 7 points out significant talos regressions up to ~20% tp5o. There will probably be memory/AWSY regressions as well. I just added/retriggered those.
Assignee | ||
Comment 14•7 years ago
|
||
Here's a comparison of tiles and current behavior followed by variations of fades and delay combinations and lastly no hiding at all. Design has said to go with the last option of no hiding, so that placeholders appear when the page first loads.
Comment hidden (mozreview-request) |
Comment 16•7 years ago
|
||
(In reply to Ed Lee :Mardak from comment #12) > mconley, thoughts on comment 11? The commit message in that patch, "Be less aggressive about preloading about:newtab", mostly means that preloading tries to occur _not_ when the user is in the middle of doing something. However, it also modifies preloading so that instead of waiting for the first newtab to open in order to do it, it waits for the first idle period with a budget of at least 40ms following a user activity idle period of 1s after the browser window opens _or_ a preloaded browser has been consumed. This increases the likelihood that the first about:newtab page will be preloaded from 0% to > 0%, but doesn't guarantee it. It really depends on what the user is doing - if they're never idle, sending tons of events and/or doing lots of things that cause animation, we'll never hit the threshold that would allow us to preload. Does that clear it up?
Flags: needinfo?(mconley)
Assignee | ||
Comment 17•7 years ago
|
||
I pushed a try build of 57beta7 with bug 1400326 and the fix here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3d50b1409e7b4b8e78b54df99e1f7d0dbec201f4 dominik, the fix for this bug should help with the perceived performance of loading about:home on a warm start as we will end up showing placeholders instead of a mostly-blank page. Could you measure opening firefox with activity stream on about:home and opening one new tab? win64 build: https://queue.taskcluster.net/v1/task/QGXZ95-qTx6oyFncL-trbQ/runs/0/artifacts/public/build/target.zip
Flags: needinfo?(dstrohmeier)
Assignee | ||
Comment 18•7 years ago
|
||
marco, could you try this beta7++ build from comment 17, and does it feel acceptable? mac build: https://queue.taskcluster.net/v1/task/cg3cj-mnRhmOWu4fJk4NsQ/runs/0/artifacts/public/build/target.dmg
Flags: needinfo?(mcastelluccio)
Comment hidden (mozreview-request) |
Comment 20•7 years ago
|
||
mozreview-review |
Comment on attachment 8917505 [details] Bug 1383593 - Noticeable delay when opening of new tabs if activity stream is enabled. https://reviewboard.mozilla.org/r/188458/#review193756 Looks good
Attachment #8917505 -
Flags: review?(khudson) → review+
Assignee | ||
Comment 21•7 years ago
|
||
Comment hidden (mozreview-request) |
Comment 24•7 years ago
|
||
Pushed by edilee@gmail.com: https://hg.mozilla.org/integration/autoland/rev/310eff6bb091 Noticeable delay when opening of new tabs if activity stream is enabled. r=k88hudson
Assignee | ||
Updated•7 years ago
|
Summary: Noticeable delay when opening of new tabs if activity stream is enabled → Noticeable delay when opening of first new tab if activity stream is enabled
Reporter | ||
Comment 25•7 years ago
|
||
(In reply to Ed Lee :Mardak from comment #18) > marco, could you try this beta7++ build from comment 17, and does it feel > acceptable? > > mac build: > https://queue.taskcluster.net/v1/task/cg3cj-mnRhmOWu4fJk4NsQ/runs/0/ > artifacts/public/build/target.dmg I don't see any difference. The first new tab you open is still as slow as before, the second you open is preloaded. Notice that opening additional new tabs is also slower with Activity Stream than without (see comment 6).
Flags: needinfo?(mcastelluccio)
Reporter | ||
Comment 26•7 years ago
|
||
Reporter | ||
Comment 27•7 years ago
|
||
Reporter | ||
Comment 28•7 years ago
|
||
Should I open a new bug for the subsequent new tabs?
Flags: needinfo?(edilee)
Assignee | ||
Comment 29•7 years ago
|
||
(In reply to Marco Castelluccio [:marco] from comment #26) > Created attachment 8917607 [details] > ActivityStream.flv The subsequent new tabs after 0:05 have a flash even when preloaded probably because activity stream is in the content process. (In reply to Marco Castelluccio [:marco] from comment #27) > Created attachment 8917608 [details] > NoActivityStream.flv Compared to tiles after 0:05, the preloaded tiles appear to always be visible (although the onboarding icon in the top left does flash). Yes, file a separate bug for the subsequent preloaded case flashing.
Flags: needinfo?(edilee)
Assignee | ||
Comment 30•7 years ago
|
||
I made a side by side comparison of a build from when this bug was filed 2017-07-23 to the try build from comment 18. From opening a new tab: 2017-07-23 build 566ms to render background 700ms to render search box with text and section header 733ms to render top sites placeholders 1400ms to render top sites fully try build 0ms to render background 100ms to render search box, placeholders for top sites and stories 233ms to render text and top sites fully So compared to before, the try build: - reduced time to render background by 100% - reduced time to search box by 85.7% - reduced time to render top sites placeholders by 86.4% - reduced time to render top sites fully by 83.3%
![]() |
||
Comment 31•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/310eff6bb091
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 58
Updated•7 years ago
|
Assignee: nobody → edilee
Comment 32•7 years ago
|
||
Please request Beta approval on this when you get a chance.
Flags: needinfo?(edilee)
Reporter | ||
Comment 33•7 years ago
|
||
(In reply to Ed Lee :Mardak from comment #30) > Created attachment 8917703 [details] > 20170723 vs bug1383593.webmhd.webm > > I made a side by side comparison of a build from when this bug was filed > 2017-07-23 to the try build from comment 18. I couldn't see such a difference, but I compared current nightly vs the try build. I still see the first opened new tab quite slower than the following opened new tabs. Maybe it's just my machine/profile, so it would be good if somebody else who was able to reproduce could verify the fix.
Flags: needinfo?(pdehaan)
Flags: needinfo?(jmathies)
Assignee | ||
Comment 34•7 years ago
|
||
Comment on attachment 8917505 [details] Bug 1383593 - Noticeable delay when opening of new tabs if activity stream is enabled. Approval Request Comment [Feature/Bug causing the regression]: Activity Stream. Blocks tracking-firefox57 blocking bug 1399961. [User impact if declined]: Users see content noticeably later on new windows and new tabs compared to Tiles. See https://ed.agadak.net/as/57%20placeholders.webmhd.webm [Is this code covered by automated tests?]: No [Has the fix been verified in Nightly?]: Yes, 20171012105833 [Needs manual test from QE? If yes, steps to reproduce]: No [List of other uplifts needed for the feature/fix]: None [Is the change risky?]: No [Why is the change risky/not risky?]: The change is removing css transitions and selecting more specific elements [String changes made/needed]: Nope [Perf win]: From comment 30 comparing when this bug was filed to now, new tabs have reduced time to render content by ~85%. From video in this comment, compared to the immediately Nightly build before, this fix improves time to various content when launching Firefox: - reduced time to render search box by 4.7% - reduced time to render text by 13.3% - reduced time to render top sites by 37.5% - reduced time to render highlights by 41.2% - reduced time to render top site icons by 8.1% Detailed measurements: https://docs.google.com/spreadsheets/d/16-eErW1EFQ_WR1wA9e-NBWLF4YyNjbEV2jO7tBR-iJk
Flags: needinfo?(pdehaan)
Flags: needinfo?(jmathies)
Flags: needinfo?(dstrohmeier)
Attachment #8917505 -
Flags: approval-mozilla-beta?
Updated•7 years ago
|
Updated•7 years ago
|
Comment on attachment 8917505 [details] Bug 1383593 - Noticeable delay when opening of new tabs if activity stream is enabled. Must fix, Beta57+
Attachment #8917505 -
Flags: approval-mozilla-beta? → approval-mozilla-beta+
Hi Marco, could you please confirm any improvements you notice with this change? Thanks!
Flags: needinfo?(mcastelluccio)
Assignee | ||
Comment 37•7 years ago
|
||
marco, you can attach videos of before and after, and I'll put together a side-by-side
Comment 38•7 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-beta/rev/b94e49969f70
Assignee | ||
Updated•7 years ago
|
Reporter | ||
Comment 39•7 years ago
|
||
Reporter | ||
Comment 40•7 years ago
|
||
Even though the following new tabs are still opened faster than the first, this is a marked improvement.
Flags: needinfo?(mcastelluccio)
Assignee | ||
Comment 41•7 years ago
|
||
Updated•7 years ago
|
Updated•5 years ago
|
Component: Activity Streams: Newtab → New Tab Page
You need to log in
before you can comment on or make changes to this bug.
Description
•