statcounter blocking accounts login on first run in new profile

RESOLVED FIXED

Status

www.mozilla.org
Pages & Content
RESOLVED FIXED
8 months ago
8 months ago

People

(Reporter: dietrich, Unassigned)

Tracking

Production

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

8 months ago
53.0.3 (64-bit) Mac OS X

STR:

* create new profile
* notice that the first run page has a big blank white square in the middle
* wait
* notice the url loading status is statcounter
* it goes away and then the fx accounts sign in content loads
(Reporter)

Comment 1

8 months ago
Created attachment 8872235 [details]
Screen Shot 2017-05-29 at 12.26.14.png
Hi Chris,

Is this statcounter code still needed? Can you provide some form of update on what is preventing us from removing this code?
Flags: needinfo?(chrismore.bugzilla)

Updated

8 months ago
Depends on: 1352821

Comment 3

8 months ago
I don't think this is blocking FxA sign up on first run. It just looks like the iframe is waiting for the parent frame's JS to finish loading before loading the iframe. I am seeing anywhere from 100ms to 500ms to load their JS.

https://www.mozilla.org/en-US/firefox/53.0.3/firstrun/

Let me update the other bug 1352821 on removing it from the 7 pages overall.
Flags: needinfo?(chrismore.bugzilla)
(In reply to Chris More [:cmore] from comment #3)
> I don't think this is blocking FxA sign up on first run. It just looks like
> the iframe is waiting for the parent frame's JS to finish loading before
> loading the iframe. I am seeing anywhere from 100ms to 500ms to load their
> JS.

I can't seem to reproduce what's reported in the bug, but the screenshot does seem to indicate a hang on loading resources from statcounter. I haven't dug in any further yet, as I wasn't sure if the snippet was still required on these pages.
:dietrich - the statcounter snippet has now been toggled off in production and is being removed from the code base. 

Can you still reproduce the same issue with the FxA iframe being slow to load? I suspect there might be other issues effecting how the iframe loading time performs, but we should be able to at least rule this out now.
Flags: needinfo?(dietrich)
(Reporter)

Comment 6

8 months ago
*so much better*

really hope we didn't ship this to very many first time users. we should probably apply our same perf standards even when doing partner experiments like this. only one chance to make a crap impression ;)
Flags: needinfo?(dietrich)
(In reply to Dietrich Ayala (:dietrich) from comment #6)
> *so much better*
> 
> really hope we didn't ship this to very many first time users. we should
> probably apply our same perf standards even when doing partner experiments
> like this. only one chance to make a crap impression ;)

Thanks for following up - we're generally very cautious when loading any third party resources on the site, I'm sorry you had issues here. This particular experiment was thankfully very short lived, although I'm not sure on the details for what percentage of users it went out to. I'd like to see if we can get some data in GA on how this may have effected firstrun users. Experiments can come through the woodwork rapidly and live for only short times, but the performance hit here was obviously either missed or not visible.
I went over the GA stats for /firstrun with Peter, and whilst page speed varies per locale we could not see a significant or notable impact on /firstrun during the time frame that this experiment was running. Page load performance on /firstrun is already well below average compared to other pages on mozorg (which is something I'd love to see improved), but this seems attributed more to loading an external iframe and its resources, rather a direct impact of what was reported here.

Closing this as fixed as the snippet has been removed from the site.
Status: NEW → RESOLVED
Last Resolved: 8 months ago
Resolution: --- → FIXED

Comment 9

8 months ago
Thanks for checking :agibson!

I also checked the number of accounts created on the /firstrun/ page by day before, during and after StatCounter was added/deleted, and the trend didn't change in either direction. So, even if StatCounter had some slight lag for some users, it didn't impact the primary conversion rate of the page.
You need to log in before you can comment on or make changes to this bug.