Marco Castelluccio [:marco] Reporter
	Description • 7 years ago

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?

	Ed Lee :Mardak 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.

	Marco Castelluccio [:marco] 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.

	Ed Lee :Mardak Assignee
	Comment 3 • 7 years ago

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

	Ed Lee :Mardak 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?

	Marco Castelluccio [:marco] 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.

	Marco Castelluccio [:marco] 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.

	Tim Spurway [:tspurway]
	Comment 7 • 7 years ago

:mar

	Jim Mathies [:jimm]
	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

	Ed Lee :Mardak 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.

	Peter deHaan [:pdehaan]
	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).

	Marco Castelluccio [:marco] 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.

	Ed Lee :Mardak 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?

	Ed Lee :Mardak 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.

	Ed Lee :Mardak 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.

	Mike Conley (:mconley) (:⚙️)
	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?

	Ed Lee :Mardak 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

	Ed Lee :Mardak 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

	Kate Hudson :k88hudson
	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

	Pulsebot
	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

	Marco Castelluccio [:marco] 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).

	Marco Castelluccio [:marco] Reporter
	Comment 28 • 7 years ago

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

	Ed Lee :Mardak 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.

	Ed Lee :Mardak 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%

	Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)
	Comment 31 • 7 years ago
bugherder

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

	Ryan VanderMeulen [:RyanVM]
	Comment 32 • 7 years ago

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

	Marco Castelluccio [:marco] 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.

	Ed Lee :Mardak 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

	Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)
	Comment 35 • 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+

	Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)
	Comment 36 • 7 years ago

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

	Ed Lee :Mardak Assignee
	Comment 37 • 7 years ago

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

	Ryan VanderMeulen [:RyanVM]
	Comment 38 • 7 years ago
bugherder uplift

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

	Marco Castelluccio [:marco] Reporter
	Comment 40 • 7 years ago

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