1602025 - Browsing from about:blank to a URL runs activity-stream code and does an about:newtab reflow

Status: NEW

(Firefox :: New Tab Page, enhancement, P3)

Description

[Randell Jesup [:jesup] (needinfo me)]

See this profile: https://perfht.ml/34WI2Vt
I see an onidlecallback running resource://activity-stream/data/content/activity-stream.bundle.js, then several Reflows/displaylists for about:newtab

In total, this spans ~80ms; main content thread ran for ~45ms of that 80.

This is going from a fresh start directly to about:blank, and pasting a docs.google.com link into the addressbar and browsing.

Unclear if this delays anything in this load (since it's network bound at this point), but it might impact real loads in some cases, and it also uses CPU at a critical point (and much more minorly, power)

Local m-c build; high end linux box.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Hmm, why are we loading anything from https://img-getpocket.cdn.mozilla.net in child process while it is also loading the page
(docs.google.com..)

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

onIdleCallback: resource://activity-stream/data/content/activity-stream.bundle.js
https://perfht.ml/2E4qNG4

Comment 3

[Jessilyn Davis]

Feel free to change this priority according to when y'all are thinking about working on it (P1 = this release, P2 = next release, P3 = Backlog). (Marking as P1 to get it out of New Tab triage.)

Comment 4

[Ed Lee :Mardak]

jesup, this is most likely the preloaded new tab controlled by browser.newtab.preload most recently changed in bug 1353013 to preload on idle instead of after opening a new tab.

Comment 5

[:Gijs (out for now; he/him)]

(In reply to Ed Lee :Mardak from comment #4)

jesup, this is most likely the preloaded new tab controlled by browser.newtab.preload most recently changed in bug 1353013 to preload on idle instead of after opening a new tab.

It still happens immediately when opening new tabs; it's the new window (and therefore also initial startup) case that does the preload on an idle task instead of immediately. bug 1540832 covers using an idle task for the opening new tab case.

That said, I'm confused about the steps here.

(In reply to Randell Jesup [:jesup] (needinfo me) from comment #0)

This is going from a fresh start directly to about:blank, and pasting a docs.google.com link into the addressbar and browsing.

Is your homepage set to about:blank? But you've got the default new tab page, or something? And session restore is off? In general, more detailed steps to reproduce (ideally from a clean profile) would be helpful to understand exactly what case we're talking about here.

Unclear if this delays anything in this load (since it's network bound at this point), but it might impact real loads in some cases, and it also uses CPU at a critical point (and much more minorly, power)

Well, we're using an idle task for the preload, so that opening new tabs is faster in future. It's not super clear to me what else we could do here. We could use more idle tasks throughout the work AS is doing and somehow chunk it up, but that would in turn risk slowing down actual new tab openings that aren't preloads. Not preloading slows down new tab openings in the common case.

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

Gijs -
./firefox -P profile -no-remote about:blank
turn on profiler (c-shift-1)
Paste URL into address bar, hit return with no major delay

The issue may be that we're actually in a load, even though we're waiting on the network when this runs. The CPU may have idle periods (though idle callbacks only mean we may have a new ms of idle), but loading resources at this point will fight for bandwidth (and CPU) with the pageload that's happening.

Best would be to wait for a "deep idle" (user-level idle, not just mainthread idle) and also defer slightly after startup (30s?) before looking for it; immediately on startup is almost always a busy time; often with an immediate load (or sessionrestore) you'd fight with.

Comment 7

[Jessilyn Davis]

mconley - can you advise here? Will this be fixed as some of the other work you're working on?

Comment 8

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

I believe the static about:home work for startup (bug 1614351) is likely going to help here - we're going to be pulling the initial about:home from the HTTP cache (presuming one was stashed there in the last session). We're also going to be sequestering about:home / about:newtab in the privileged about content process, where that process will have lower process priority (on Windows) when in the background (as in this case).