Recently about:newtab has been set as the default home page for me (maybe as part of an experiment?). It is considerably slower than about:home. I can clearly see the stages of page loading: 1) Page loaded with placeholders (only one line) 2) A second line is added 3) Grey images appear for the "recent history" websites 4) Letters appear for the "main" websites 5) Small favicons appear for the "main" websites 6) Images appear for for "recent history" websites 7) Images appear for "main" websites Note I can't reproduce this on my fast Linux machine, but I can on my older Windows machine. Ideally, the page should be preloaded, just like when you open a new tab. Moreover, newtab preloading doesn't work for the first new tab I open (after the home page), but only starting from the second. Let me know if I should open a new bug for this.

Bug 1353013 makes it so that about:newtab can be preloaded for the very first about:newtab. Did you customize / turn off any of the sections? What's the value of browser.newtabpage.activity-stream.prerender ?

(In reply to Ed Lee :Mardak from comment #1) > Bug 1353013 makes it so that about:newtab can be preloaded for the very > first about:newtab. Cool, so I guess that bug will take care of the second issue I've noticed and I don't have to open a new bug. > Did you customize / turn off any of the sections? What's the value of > browser.newtabpage.activity-stream.prerender ? The only non-default value is browser.newtabpage.activity-stream.topSitesCount. It is 12 (I guess because I selected the option to show 2 lines of thumbnails).

[Tracking Requested - why for this release]: We shouldn't regress performance of the first page we load in Firefox 57.

We are tracking the hero element performance, which is the time to show the search placeholder text. This does not measure all the other items on the page. I believe if you are seeing activity stream on about:home, you should see the search bar with placeholder text appear immediately probably the first thing you see.

(In reply to Ed Lee :Mardak from comment #4) > We are tracking the hero element performance, which is the time to show the > search placeholder text. This does not measure all the other items on the > page. > > I believe if you are seeing activity stream on about:home, you should see > the search bar with placeholder text appear immediately probably the first > thing you see. Yes, the structure of the page appears quickly. The problem is that everything is a placeholder and is slowly populated. Overall, it looks way slower than about:home.

The slowness might be related to bug 1399965 where we found there was a unnecessary work / renders happening. A fix was pushed as part of bug 1399970, so we'll see if this improves.

I can still reproduce in the latest Nightly.

Here's a screen recording of startup (from when the browser window first appears on screen to when about:home is fully loaded). It takes about 4s here on the reference hardware. That feels pretty slow for a local page.

Kate has been doing some work on perceived performance of about:home. There's a PR up here: https://github.com/mozilla/activity-stream/pull/3536 The idea is to hide everything but the Search section until the page is done initializing to improve perceived perf.

I hadn't noticed this before, but you can also see the transition between the English strings and the selected locale strings (e.g. in my video you can see "Search the Web" being replaced by "Cerca sul Web").

We're tracking having localized strings in the initial/prerendered search box here: https://github.com/mozilla/activity-stream/issues/3370

I agree with marco about the perf. Especially if this can be seen by a human (and not automation). This might be blocking the release.

Bug 1403215 has fixes for perceived performance of startup waiting on approval-mozilla-beta

(In reply to Sylvestre Ledru [:sylvestre] from comment #12) > I agree with marco about the perf. Especially if this can be seen by a human > (and not automation). Here is what I observed last week when profiling opening a new window on the quantum reference hardware: - profile with the old about:home: https://perfht.ml/2k3If64 - profile with the activity stream about:home https://perfht.ml/2hznuyC In both of these profiles, it takes about 400ms for the content process to initialize itself and be ready to load a page. There's probably room for future improvements there, but that's unrelated to activity stream. After that: In the old about:home profile, it takes another 84ms to display about:home. In the activity stream about:home profile, it takes a bit more than 400ms for about:home to be ready (although we have something painted after about 65ms, I assume that's the pre-rendering with only the searchbox displayed). These 400ms seem to be spent mostly loading and running react code. So if we take into account when the about:home page is fully (or mostly) loaded, activity stream is significantly slower, and I think that's what Marco experienced when filing this bug. However if we take into account only the "searchbox placeholder text displayed" time, which was initially selected as the quantum target for startup performance (back when the searchbox placeholder was almost last thing to be displayed in about:home before bug 1371860 was fixed), activity stream about:home performs as well (or slightly better) than the old about:home.

Adding a link to a doc with some discussion around Activity Stream about:home performance: https://docs.google.com/document/d/1dcQkGF6HymEm2qvJAeJ_dsU8Bwa8jogUTtqfs1KQw_8/edit#

Hit save a bit too soon. Couple of things... - I would like to see this bug retested on the upcoming beta build which includes some uplifts around pre-rendering and perceived performance. - also, per the investigations referenced in the doc, loading of Activity Stream itself has been shown to perform comparatively very well, but the lag comes in getting to first paint. Resolving bug 1336227 (added to dependencies) would benefit our start-up performance much more than trying to further optimize activity stream. NI to Marco & Florian re: the retest.

(In reply to Marco Castelluccio [:marco] from comment #10) > I hadn't noticed this before, but you can also see the transition between > the English strings and the selected locale strings (e.g. in my video you > can see "Search the Web" being replaced by "Cerca sul Web"). I think this deserves its own bug.

(In reply to Florian Quèze [:florian] [:flo] from comment #17) > (In reply to Marco Castelluccio [:marco] from comment #10) > > I hadn't noticed this before, but you can also see the transition between > > the English strings and the selected locale strings (e.g. in my video you > > can see "Search the Web" being replaced by "Cerca sul Web"). > > I think this deserves its own bug. It's here: https://github.com/mozilla/activity-stream/issues/3370.

I'd like to track this as a blocker for 57 go live.

Some profiles of the content process loading about:home during warm startup, captured on very slow hardware to have very detailed profiles: With activity stream enabled for about:home: https://perfht.ml/2xRXwg3 https://perfht.ml/2xSvf9g With the old about:home: https://perfht.ml/2xSGUVx

I ran a comparative benchmark of about:home using today's nightly and the current Chrome release. For warm startup I measured from when the mouse button is pressed to when the home page is mostly loaded (for activity stream that means most placeholders are in place, for old about:home that means Firefox logo + searchbox, for Chrome that means everything loaded as everything paints at once). On average: old about:home: 1345ms Activity Stream about:home: 1684ms Chrome: 1241ms (this depends on network conditions, so Chrome may be slower in some places) For new window opening, where about:home is also visible, I measured from when something related to the new window is first painted on screen (on Firefox that means the whole area is blanked, on Chrome that means the new titlebar has been painted) to when the home page is mostly loaded. On average: old about:home: 200ms Activity Stream about:home: 570ms Chrome: 437ms (note: this benchmark is biased against Chrome, as Chrome paints a blank window much faster than Firefox when opening a new window, but then has more work to do to finish loading the new window) My raw data is at https://docs.google.com/spreadsheets/d/1K-jJIMQIK74Klze613f-GGIU-IaWiuZGBxt5Pf8rMeQ/edit and the videos used for the benchmark are available at https://drive.google.com/drive/folders/0B8wSrbtm7kXVR2pNaTdZSFVONGc?usp=sharing All the activity stream tests were with Pocket stories disabled, as this feature is disabled by default here.

Clearing needinfo since Florian tested it. I currently don't have access to the old machine where I could easily see this.

NI Tim, I'm going to walk over soon and ask you if this bug still blocks...

I don't think this bug should block 57. It's a metabug whose only open dependent bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1353013) is 'wontfix' for 57.

AFAIK, all planned perf fixes have landed on 57, I'd like to mark this as fixed for 57 and take it off the 57 blocking bugs list. Please let me know if there are any other open issues that still need to be uplifted to 57.

Did you mean WONTFIX? Or has there been new performance measurements showing the problems are now fixed? From the bugs I've seen, bug 1497996 seems the most promising way to address this.