(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 :).
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
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).
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 ?
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.
Oh, and both loads finish almost immediately (0.2-0.4s).
(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.
Component: Layout → DOM
QA Contact: layout → general
Component: DOM → HTML: Parser
QA Contact: general → parser
(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)?
I think this should be WONTFIX in the browser and the right fix is in the proxy config as mentioned in comment 6.
> 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.
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.
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.
4 months ago
Type: enhancement → defect
Component: HTML: Parser → Networking: HTTP
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.