Currently browser.slowStartup.timeThreshold is 60 seconds, which was deliberately conservative. We should look at the relevant data and feedback, and see what would be an acceptable next step as a lower value. My gut tells me 30 seconds would be a fine next step, but that might also be indigestion. Maybe an even lower value; a 30 second startup still feels really terrible.

Do we have telemetry data around average startups?

Firefox 21 is reporting main, first paint, and session restored times for a majority of our users through Firefox Health Report. I reckon you could ask Metrics for data so this could be a data-driven decision. This may require waiting for FHR to collect a sufficient sample size from the Beta and/or Release channels. Presumably a change to this preference could be uplifted to Beta if you are worried about making this feature more useful sooner.

From Wed, Feb 6th #perf scrollback (yikes)... 12:45 PM <taras> jaws: btw, i think the 1min delay is a good one to ship this the first time 12:45 PM <taras> i would be reluctant to make it any lower 12:45 PM <taras> since some hw reliably has 45s startups It's also worth noting that bug 836010 landed in Fx21, so if we change it now then the new value will ride a different train (which would be good). Taras, what do you think about reducing this value for Fx22?

Do we have telemetry data that shows us how often users act-on/ignore this infobar?

(In reply to Taras Glek (:taras) from comment #4) > Do we have telemetry data that shows us how often users act-on/ignore this > infobar? We don't have any telemetry to track if users dismiss the notification or click on the button, but SUMO should be able to track the visit rate of the linked article.

(In reply to Jared Wein [:jaws] from comment #3) > 12:45 PM <taras> i would be reluctant to make it any lower > 12:45 PM <taras> since some hw reliably has 45s startups Are you talking ancient low-end HW where that would be expected and normal (for other browsers too)? Or something different? I suppose we could tune the threshold based on CPU+mem+HD info. But I'm hesitant to make this too complex (although I'm also unclear what the eventual FHR plans are here), and I'd be surprised if we have any existing data that correlates such factors.

(In reply to Jared Wein [:jaws] from comment #5) > (In reply to Taras Glek (:taras) from comment #4) > > Do we have telemetry data that shows us how often users act-on/ignore this > > infobar? > > We don't have any telemetry to track if users dismiss the notification or > click on the button, but SUMO should be able to track the visit rate of the > linked article. We should add some. SUMO can't tell us what proportion of users ignore an extra infobar Justin, $300 laptop hardware with new windows installs. Combination of anti-virus crapware + windows indexing taking a few weeks to complete without regard to io priority + world's crappiest HDs is lethal.

(In reply to Taras Glek (:taras) from comment #7) > Justin, $300 laptop hardware with new windows installs. Combination of > anti-virus crapware + windows indexing taking a few weeks to complete > without regard to io priority + world's crappiest HDs is lethal. We actually try to help these users... https://support.mozilla.org/en-US/kb/firefox-takes-long-time-start-up#w_check-your-antivirus-software https://support.mozilla.org/en-US/kb/firefox-takes-long-time-start-up#w_optimize-windows

If I read http://telemetry.mozilla.org/#release/29/SIMPLE_MEASURES_FIRSTPAINT correctly, 6% of the first paints take 30 seconds or longer. 6% seems like a lot, so I think we should be more conservative with reducing the threshold. Of course this doesn't need to be the last time we reduce it.

My gut feeling says 50 or 45 seconds would be reasonable next steps. How about we try 50 seconds in Firefox 31 and 45 seconds in Firefox 32? Maybe another 5 second reduction after that, etc.

(In reply to Dão Gottwald [:dao] from comment #10) > My gut feeling says 50 or 45 seconds would be reasonable next steps. How > about we try 50 seconds in Firefox 31 and 45 seconds in Firefox 32? Maybe > another 5 second reduction after that, etc. WFM. It would be nice if the Telemetry dashboard gave us the ability to see a finer breakdown for reports over > 30 seconds (or is that just 1 big bucket as reported by the client?). Also there appears to be some bogus data reported over the last month, as the media/mean jumped enormously and made the pushed the other data on the evolution graph to the bottom. :(

Marco, please add this to the current iteration? https://hg.mozilla.org/integration/fx-team/rev/832f1617782b

Comment on attachment 8426879 [details] [diff] [review] 50 seconds for Aurora uplift [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 836010 (feature, not a regression) User impact if declined: no slow-startup notification for users experiencing startups that take between 50 and 60 seconds on average Testing completed (on m-c, etc.): patch setting the threshold to 45 seconds is in the process of landing Risk to taking this patch (and alternatives if risky): low String or IDL/UUID changes made by this patch: none

Added to Iteration 32.2

Hi Juan, can you review the bug to determine if further verification is required.