User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Build ID: 20161017030209 Steps to reproduce: Go to about:healthreport and look at the graph on the right part. Actual results: Firefox is listed as taking about 35s to start. Expected results: I timed an actual startup of Firefox, at 0:02 the window will be shown with a single empty tab, at 0:29 all empty tabs will have been created, at 1:28 all tab names will have been loaded and at 2:49 all favicons will have been loaded too. Only at that point Firefox will start responding to my input, so it would make sense to consider this time point for the healthreport data. This might seem a long time, but I currently have 1253 open tabs that needs to be reloaded from the sessionstore. I’m also pretty sure this could be improved, but this bug is only about the false reporting.
Created attachment 8803445 [details] startup.PNG Hey Emmanuel, I have measured the startup time of nightly tabs using "about:healthreport", online stopwatch and about:startup addon. The browser startup times in my Ubuntu 16.04 32bits machine using stopwatch is as follows: 03.7 seconds for single empty tab 06.7 seconds for all empty tabs 08.3 seconds for all tabs with names 10.2 seconds for all favicons Here is the screen capture: https://testing-1.tinytake.com/sf/MTA2NTU2OF80MjkwNDc1 Screenshot is also added. In this test, I do not see any significant browser startup time differences between "about:healthreport", addon and online tool. Is there a better /more precise/ tool that I need use to measure this time? Is this a regression issue ? If yes, could you please provide the range? Please See http://mozilla.github.io/mozregression/ for details (if needed). Thanks
Component: Untriaged → Web: Health Report
Product: Firefox → Firefox Health Report
The "startup time" is simply based off the "first paint" signal. As far as i know, we don't have a well defined startup measurement that would cover "time Firefox became responsive after startup" right. For now, this is correct as long as it corresponds properly to the "first paint" signal.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P5
> … "first paint" signal. If the following enhancement requested can be fulfilled – 1037075 - Need event or notification signalling initiation of restoring a session <https://bugzilla.mozilla.org/show_bug.cgi?id=1037075> – then what might be the subsequent signals for measurement purposes? ---- This is not to suggest that first paint-based measurements are lacking in value. There may be equal or greater value in complementary measurement of the time between: a) initiation of restoration of a session; and b) a subsequent defined signal that 'comes close' to the user's (less well defined) sense of any restored page becoming usable. ---- For what it's worth: within the set of approaches that I sometimes use to measure 'useful startup' times – where I use Session Manager <https://addons.mozilla.org/addon/session-manager/> to begin restoration at a specific point in time – there's Tab Tally <https://addons.mozilla.org/addon/tab-tally/>. When any of the restored windows shows – in the Tab Tally icon – the number that was shown in the Session Manager dialogue, then I know that Firefox has made a significant step towards preparing a page for usefulness.
I'm marking this bug as INVALID, because about:healthreport was removed in bug #1352497.
Status: NEW → RESOLVED
Last Resolved: 8 months ago
QA Contact: Virtual
Resolution: --- → INVALID
Product: Firefox Health Report → Firefox Health Report Graveyard
You need to log in before you can comment on or make changes to this bug.