544979 - Blocking .google-analytics.com makes the web slow

Status: RESOLVED WORKSFORME

(Core :: Networking: HTTP, defect)

Description

[Ben Bucksch (:BenB)]

(This is about page load, esp. Reflow probably. I don't know what's the best Component for that.)

For privacy reasons, because I don't want to be tracked across the whole Web, I
block .google-analytics.com. I do that in my HTTP proxy.

However, I notice that loading webpages, e.g. my preferred newspaper, is slow, despite a fast Internet connection. Most of the time when the page load interrupts, the status bar says "Waiting for ...google-analytics.com...". This is only about 0.5-2 seconds, but given that it happens for *every* click, that adds up to hours in a month.

Impact:
* This affects many many websites.
* Increases page load time significantly (from 1-2s to 3-5s)

Implementation:
This is unnecessary, because the only reference to google-analytics.com is a single
<script src="www.google-analytics.com/urchin.js"></script>
line. There's no inherent need to block page load on this. You can and should still load the HTML and all images and render them, and load the JS and run the onload handler only then.

Compare bug 544970, which would probably also be fixed by this.

Please don't discard this bug because you need to block google-analytics to run into it. IMHO, everybody should block them :).

Comment 1

[Bryan]

Hmm, I block google-analytics.com using Adblock Plus 1.1.3 and have no issues with page load at all!

BUILD: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a2pre) Gecko/20100208 Minefield/3.7a2pre (.NET CLR 3.5.30729) ID:20100208095921

~B

Comment 2

[Ben Bucksch (:BenB)]

Yes, AdBlock Plus might be using a different method. The method is obviously important. I block in the proxy.
(I do not use AdBlock Plus, because I have nothing against non-abusive ads, just against tracking).

Comment 3

[Matthias Versen [:Matti]]

How do you block it with your proxy ?
Do you get a timeout, 404 or DNS error if you try to load the google URL over the proxy ?

Comment 4

[Ben Bucksch (:BenB)]

Tried by entering in FF URLbar:
<http://www.google-analytics.com/urchin.js> gives an empty document for me.
<https://ssl.google-analytics.com/urchin.js> gives a "server is refusing connections" error in my case.

Comment 5

[Ben Bucksch (:BenB)]

Oh, and both loads finish almost immediately (0.2-0.4s).

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #0)
> This is unnecessary, because the only reference to google-analytics.com is a
> single
> <script src="www.google-analytics.com/urchin.js"></script>
> line. There's no inherent need to block page load on this. You can and should
> still load the HTML and all images and render them, and load the JS and run the
> onload handler only then.

It's not quite that simple.  Lots of Web pages have dependencies on the script executing before anything else gets parsed.  A significant part of that dependence, but definitely not all of it, is due to document.write.


Why can't you configure your proxy so that the attempt to load something from google-analytics.com returns a connection refused error or something similar, rather than timing out?  If the proxy immediately says that the connection failed, we should just go on.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #5)
> Oh, and both loads finish almost immediately (0.2-0.4s).

Does the proxy behave the same given the different HTTP headers that are sent for script requests (e.g., different 'Accept' header)?

Comment 8

[Henri Sivonen (:hsivonen)]

I think this should be WONTFIX in the browser and the right fix is in the proxy config as mentioned in comment 6.

Comment 9

[Ben Bucksch (:BenB)]

> Why can't you configure your proxy so that the attempt to load something from
> google-analytics.com returns a connection refused error or something similar,
> rather than timing out?

As I said in comment 5, the proxy *does* send "connection refused", as you suggest.

The proxy is "privoxy", and I don't think it differentiates based on Accept headers.

Comment 10

[Ben Bucksch (:BenB)]

Tried with wget --header="Accept: text/javascript" http://www.google-analytics.com/urchin.js -S , no difference. Proxy gives "403 Forbidden" for http.

For SSL, it blocks the request entirely for <https://ssl.google-analytics.com/urchin.js>. Given that SSL is protected, the headers can't possibly make any difference there.

Comment 11

[Ben Bucksch (:BenB)]

Compare bug 492459, which is specifically about the SSL problem.
This bug here is mainly about the normal web (http) being notably slower.
The other bug found a regression window: It broke between 3.0.9 and 3.0.10.

Comment 12

[Dimitris Karnoutsos]

Hi. I block google-analytics.com via my router and AFTER a site loads I get the message "The connection was reset"
This happens only with Firefox 6.0.2 (os: windows 7 x64) and not other browsers.

Comment 13

[Michal Novotny [:michal]]

This bug was inactive for 8 year, closing it as WFM. If you still experience the problem, reopen the bug and provide HTTP log. See https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging