Closed Bug 1383593 Opened 3 years ago Closed 3 years ago

Noticeable delay when opening of first new tab if activity stream is enabled

Categories

(Firefox :: New Tab Page, defect, P2)

defect

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)

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?
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.
(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.
Sounds like we want bug 1353013 to have the first about:newtab quick too.
Depends on: 1353013
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?
(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.
Blocks: 1381569
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.
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
:mar
Priority: -- → P2
(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
Flags: needinfo?(pdehaan)
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.
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)
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.
(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)
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.
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.
(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)
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)
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 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+
Attachment #8917548 - Attachment is obsolete: true
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
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
(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)
Attached video ActivityStream.flv
Attached video NoActivityStream.flv
Should I open a new bug for the subsequent new tabs?
Flags: needinfo?(edilee)
(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)
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%
https://hg.mozilla.org/mozilla-central/rev/310eff6bb091
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 58
Assignee: nobody → edilee
Please request Beta approval on this when you get a chance.
Flags: needinfo?(edilee)
(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)
Blocks: 1399961
Flags: needinfo?(edilee)
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?
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)
marco, you can attach videos of before and after, and I'll put together a side-by-side
Attached video Before.mp4
Attached video After.mp4
Even though the following new tabs are still opened faster than the first, this is a marked improvement.
Flags: needinfo?(mcastelluccio)
Component: Activity Streams: Newtab → New Tab Page
You need to log in before you can comment on or make changes to this bug.