848460 - Reduce browser.slowStartup.timeThreshold to a more aggressive value

Status: VERIFIED FIXED

(Firefox :: General, defect)

Description

[Justin Dolske [:Dolske]]

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.

Comment 1

[Tyler Downer [He/Him]]

Do we have telemetry data around average startups?

Comment 2

[Gregory Szorc [:gps]]

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.

Comment 3

[Jared Wein [:jaws] (please needinfo? me)]

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?

Comment 4

[(dormant account)]

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

Comment 5

[Jared Wein [:jaws] (please needinfo? me)]

(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.

Comment 6

[Justin Dolske [:Dolske]]

(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.

Comment 7

[(dormant account)]

(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.

Comment 8

[Dão Gottwald [:dao]]

(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

Comment 9

[Dão Gottwald [:dao]]

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.

Comment 10

[Dão Gottwald [:dao]]

Attachment: 45 seconds

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.

Comment 11

[Dão Gottwald [:dao]]

Attachment: 50 seconds for Aurora uplift

Comment 12

[Justin Dolske [:Dolske]]

(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. :(

Comment 13

[Dão Gottwald [:dao]]

Marco, please add this to the current iteration?

https://hg.mozilla.org/integration/fx-team/rev/832f1617782b

Comment 14

[Dão Gottwald [:dao]]

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

Comment 15

[Marco Mucci [:MarcoM]]

Added to Iteration 32.2

Comment 16

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/832f1617782b

Comment 17

[Marco Mucci [:MarcoM]]

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

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/8a4cd0c71469