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

Status: RESOLVED FIXED

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

Description

[Marco Castelluccio [:marco]]

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?

Comment 1

[Ed Lee :Mardak]

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.

Comment 2

[Marco Castelluccio [:marco]]

(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.

Comment 3

[Ed Lee :Mardak]

Sounds like we want bug 1353013 to have the first about:newtab quick too.

Comment 4

[Ed Lee :Mardak]

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?

Comment 5

[Marco Castelluccio [:marco]]

(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.

Comment 6

[Marco Castelluccio [:marco]]

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.

Comment 7

[Tim Spurway [:tspurway]]

:mar

Comment 8

[Jim Mathies [:jimm]]

(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

Comment 9

[Ed Lee :Mardak]

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

[Peter deHaan [:pdehaan]]

I definitely see a subtle difference in the first newtab loaded vs subsequent ones in the same window (in FF Nightly on macOS).

Comment 11

[Marco Castelluccio [:marco]]

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.

Comment 12

[Ed Lee :Mardak]

(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?

Comment 13

[Ed Lee :Mardak]

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.

Comment 14

[Ed Lee :Mardak]

Attachment: unpreloaded new tab.webmhd.webm

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 15

[Ed Lee :Mardak]

Attachment: Bug 1383593 - Noticeable delay when opening of new tabs if activity stream is enabled.

Review commit: https://reviewboard.mozilla.org/r/188458/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/188458/

Comment 16

[Mike Conley (:mconley) (:⚙️)]

(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?

Comment 17

[Ed Lee :Mardak]

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

Comment 18

[Ed Lee :Mardak]

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

Comment 19

[Ed Lee :Mardak]

Comment on attachment 8917505 [details]
Bug 1383593 - Noticeable delay when opening of new tabs if activity stream is enabled.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/188458/diff/1-2/

Comment 20

[Kate Hudson :k88hudson]

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

Comment 21

[Ed Lee :Mardak]

Attachment: unpreloaded hide title no pocket.webmhd.webm

Comment 22

[Ed Lee :Mardak]

Comment on attachment 8917505 [details]
Bug 1383593 - Noticeable delay when opening of new tabs if activity stream is enabled.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/188458/diff/2-3/

Comment 23

[Ed Lee :Mardak]

Attachment: unpreloaded hide title no pocket.webmhd.webm

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/310eff6bb091
Noticeable delay when opening of new tabs if activity stream is enabled. r=k88hudson

Comment 25

[Marco Castelluccio [:marco]]

(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).

Comment 26

[Marco Castelluccio [:marco]]

Attachment: ActivityStream.flv

Comment 27

[Marco Castelluccio [:marco]]

Attachment: NoActivityStream.flv

Comment 28

[Marco Castelluccio [:marco]]

Should I open a new bug for the subsequent new tabs?

Comment 29

[Ed Lee :Mardak]

(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.

Comment 30

[Ed Lee :Mardak]

Attachment: 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.

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

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/310eff6bb091

Comment 32

[Ryan VanderMeulen [:RyanVM]]

Please request Beta approval on this when you get a chance.

Comment 33

[Marco Castelluccio [:marco]]

(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.

Comment 34

[Ed Lee :Mardak]

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

Comment 35

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8917505 [details]
Bug 1383593 - Noticeable delay when opening of new tabs if activity stream is enabled.

Must fix, Beta57+

Comment 36

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Hi Marco, could you please confirm any improvements you notice with this change? Thanks!

Comment 37

[Ed Lee :Mardak]

marco, you can attach videos of before and after, and I'll put together a side-by-side

Comment 38

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/b94e49969f70

Comment 39

[Marco Castelluccio [:marco]]

Attachment: Before.mp4

Comment 40

[Marco Castelluccio [:marco]]

Attachment: After.mp4

Even though the following new tabs are still opened faster than the first, this is a marked improvement.

Comment 41

[Ed Lee :Mardak]

Attachment: bug1383593.marco.before-after.webmhd.webm