513564 - Firefox 3.5.1 is very slow with low-bandwidth/dialup connection compared with older versions such as Firefox 2 (TESTED)

Status: RESOLVED INCOMPLETE

(Core :: Networking, defect)

Description

[Jay]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1

Firefox 3.5.1 is very slow compared with older versions such as Firefox 2

I've noticed over the last few years that Firefox is getting slower. Today I tested page download time between Firefox 3.5.1 and an old copy of Firefox 2.0.0.14 I had kicking around.

I'm using 56k Dial-up using Vista SP1 - connecting at a low 26-28 kbps – slow I know, but I don't have the luxury of Broadband. The page I tested was Google Images and did a search for the word “cat”. This I also did in-safe-mode and without extensions.

On average Firefox 2.0.0.14 retrieved the whole page in 33 seconds, where as Firefox 3.5.1 only managed a miserable 46 seconds.

I've disabled ipv6 and the usual extras such as Automatic-Updates, Block-Reported-Attack-Sites, Block-Reported-Web-Forgeries and various installed plugins – I've even turned off favicons to save that tiny bit of data too. I also have JavaScript turned off as this can slow things down a notch on some sites.

On many occasions image intense sites with thumbs will only partially load some of the images. Especially if I load the page without images switched on and then select a few to view with the 'Show-image' extension.

Also all CSS heavy pages such as Deviant Art end up taking forever to load, all content seems to be loaded before the CSS which is crazy. If I hit reload, then sometimes, the CSS appears sooner, but I bet that's helped because of the cached images already loaded.

I've also created new profiles, and re-installed Firefox 3.5.1 several times to see if there was any difference.

I realise that I don't have a great super fast connection, but if I'm loosing out with data on dial-up and it's a good percent over older versions, then others that are on DSL etc may be loosing out too without their knowledge - There's a big difference between 33 and 46 seconds to download a page!

Reproducible: Always

Steps to Reproduce:
1.Use Dial-up Modem
2.Use Firefox 3.5.1 and check the load times on a site.
3.Use the same site as above with Firefox 2 and comapre times.
Actual Results:  
Using Google Images searching for the word "cat" (without JavaScript), Firefox 3.5.1 returned the page on dial-up in 46 seconds, where as Freifox 2.0.0.14 produces the page in 33 seconds.

Expected Results:  
I'd hope that Firefox 3.5.1 would at least load pages the same as Frefox 2.0.0.14.

Comment 1

[Ria Klaassen (not reading all bugmail)]

Could very well be caused by an add-on; to exclude extension problems and changes in your profile, can you retest with a new profile?
http://support.mozilla.com/en-US/kb/Basic+Troubleshooting#Make_a_new_profile

Comment 2

[Jay]

Hi, As I mentioned above, I've tried different profiles and in fact I also tried a new one earlier on after the above - but no success. I've also tried this without extensions and also removed some plugins and disabled various features in about:config, but to no avail.

I've a feeling that there was something new added from version 3+ onwards in about:config that is taking up a small bit of crucial bandwidth that firefox 2 and 1 didn't before. This 'Crucial' bit of bandwidth is damn precious to us dial-up users!

Comment 3

[Ria Klaassen (not reading all bugmail)]

I did some tests at http://www.speedtest.net/ for comparison between Firefox 2 and 3.5 but Firefox 3.5 was even a bit faster every time.
Problem is that it needs to be reproducible in order to fix it.

Comment 4

[Jay]

Thanks for trying to test this problem - did you emulate a low-bandwidth modem connection? I'm using dial-up and I only connect at between 26 and 28kbps. 

I've had some speed up in Firefox 3.5.1 today by changing some settings in “about:config” to mirror Firefox 2 settings. These changes seem to have improved things somewhat. Although I haven't tested each one individually to see which one has the most benefit.

network.http.max-persistent-connections-per-proxy 4
network.http.max-persistent-connections-per-server 2
network.http.max-connections 8
network.http.pipelining.maxrequests 4
network.http.redirection-limit 20
network.http.request.max-start-delay 10
geo.enabled “false”
browser.chromesite_icons “false”
browser.chrome.favicons “false”

Turned off “JavaScript”
Turned off “Java”
No “RSS feeds” active
Turned off “Block reported attack sites”
Turned off “Block report web forgeries”
Turned off “Automatically check updates to: Firefox, Installed Add-ons and Search Engines”
Turned off “Show search suggestions”

This has improved the original speed test I did searching for the word “cat” in Google images. My average with Firefox 3.5.1 after the above changes was “32 seconds” – this is much closer to Firefox 2. Plus thumbnail images so far don't seem to be stopping halfway through.

I think that these changes may help others in my situation if there is any way to pass this info on?

As I mentioned before, every byte counts on a slow connection, everything that is sent uses up a portion of what is available and for many of us we don't have that much bandwidth to give away. So if you've any other suggestions as to how to improve Firefox's speed for dial-up, please let me know.

Comment 5

[Ria Klaassen (not reading all bugmail)]

Dial up connections are really expensive here, even if you hardly use the internet the bill is high, so I can't test this with dial up. The slowest connection I have is a UMTS connection but as I remember much faster in comparison with dial up (and much cheaper, at least here). I tried the speedtest for you with the UMTS but still not much difference here between Firefox 2 and 3.5. Firefox 3.5 is a bit faster.

Comment 6

[Jay]

I guess without dial-up, there's no way of proving this. But I've been looking into this since the release of Firefox 3 - I must like Firefox!

Firefox 3.5.1 is now working great with the following changes in About:Config

network.http.max-persistent-connections-per-proxy 4
network.http.max-persistent-connections-per-server 2
network.http.max-connections 8
network.http.pipelining.maxrequests 4
network.http.redirection-limit 20

As far as I know, although I can't confirm, these settings were changed in version 3 - I imagine to keep inline with the improved internet conections a large majority of users have gained.

But as I'm sure you're aware, there's lots of us still on dial-up and can't get anything faster - millions I imagine. 

If there is anyway, I really hope you can pass this info on to others that have low-bandwidth. I'm sure they would benefit.

Thanks :o)

Comment 7

[Wayne Mery (:wsmwk)]

if someone has better component for this that just Networking, feel free to move.

Comment 8

[Parkhideh]

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.1)
> Gecko/20090715 Firefox/3.5.1
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.1)
> Gecko/20090715 Firefox/3.5.1
> 
> Firefox 3.5.1 is very slow compared with older versions such as Firefox 2
> 
> I've noticed over the last few years that Firefox is getting slower. Today I
> tested page download time between Firefox 3.5.1 and an old copy of Firefox
> 2.0.0.14 I had kicking around.
> 
> I'm using 56k Dial-up using Vista SP1 - connecting at a low 26-28 kbps – 
> 
> 
> On many occasions image intense sites with thumbs will only partially load some
> of the images. Especially if I load the page without images switched on and
> then select a few to view with the 'Show-image' extension.
> 
Firefox v 3.6.8
I have not tested this problem yet because a reliable ISP has to be found that does not interfere with the measurements.  However, I confirm the paragraph above that on dialup, images may not load at times (like www.bbc.co.uk site).  Unfortunately a reload will clear the problem and that may be for the cache reason Jay has mentioned.  I assumed, and for no good reason, that my packets were lost and reload corrected it.  Now I will have to compare old versions of Firefox and report back.

Comment 9

[Parkhideh]

Jay, I find your explanation and placing the blame on CSS downloading priority fascinating and in line with what I see with Firefox.  It is that I did not associate, or believe, that the format information is downloaded after all the data is downloaded.  If true it makes no sense.  But clearly "can" explain why in Firefox 3 I see a blank page for ever and then suddenly the page appears.  This is very irritating when all I need is a link on that page to click on.

However, some other measurements are in order.
1) Are you sure that the site is not "browser aware" and sends different amount of data to Firefox 2 than Firefox 3?  The reason is that the bottle neck in dialup is the connection speed and I fail to see how it takes 46 seconds instead of 33 seconds for the same data to download; no matter the priority of which file is downloaded first.
2) Are you sure that items like Flash files are not present in version 3.  My browser speeded up a lot after I added the FlashBlock and AdBlock Plus.

Unfortunately I will not be at my setup till mid January, so if you can do the following test on your favourite site it will be helpful.
a) Have Firefox as the sole application running, leave it on and bring up your dialer.  It should show Duration and Activity of your connection.
b) Note the time and the Kb sent and received.
c) After few minutes not much should have been changed in Activity (important).
d) Do what you reported that takes 33 and 46 seconds, twice each to be sure that cache is clear every time.

Q1) Is the total bytes received and sent identical (or close) in all cases?
Q2) How long is the time to download? 

My expectation is to see all cases the same.  And I have no explanation should Q1 be the same but Q2 be 33 and 46 seconds in download.

Comment 10

[Wayne Mery (:wsmwk)]

Parkhideh, any new info?

I've attempted to ping Jay, the reporter.

Comment 11

[Wayne Mery (:wsmwk)]

Jay seems to be gone

Comment 12

[Patrick McManus [:mcmanus]]

from the description it seems likely that the root cause is very low bandwidth being split to a higher degree of parallelism and that slows the loading of the css - possibly even inducing loss on the css load.

generally the parallelism is the right thing for the Internet - so we won't be making a direct change to lower values. But we've recently seen the same thing with insance levels of parallelism caused by sharding things 16 ways (which can lead to 100 connections in parallel) and aggressinve server TCP IW configurations. Its work looking for a decent answer here.

Comment 13

[Parkhideh]

(In reply to Patrick McManus [:mcmanus] from comment #12)
> from the description it seems likely that the root cause is very low
> bandwidth being split to a higher degree of parallelism and that slows the
> loading of the css - possibly even inducing loss on the css load.
> 
Patrick, thank you for the explanation; I read four of the many items you have referred to and readily admit falling off the boat.  These were id=792438; id=728435; id=813712 and https://wiki.mozilla.org/Necko/Performance/AutomatedTesting.

Unless it is implied, I did not find two items:

1) The measure stick to what is being improved.  That is what is the goal?  Display what faster?  What is the users' perspective of a better browser?  What priority do the developers place on the error "Firefox cannot find the server or load the page" under the condition of multiple tabs and low bandwidth to some servers?  All I read was the tradeoff of image vs style sheet loading and a few other items that I do not comprehend.  In comment 9 I have already said what I had in Firefox 2 that was lost in Firefox 3.x.x.
May I suggest that parallelism be discarded in ONE option and the serial loader be used as the measure stick.  If you can create a parallel loader version that is as reliable under all circumstances and faster; then more power to you.  Otherwise, what may be VERY GOOD in one case and totally non-functional in another should not be taken so lightly.

2) I did not see any mention in the tests of bandwidth and transport media.  To tell the truth I did not see any language showing anyone being concerned about the transport media.  Here I refer to ISO layers.  All the reading seemed to concern itself with the application layer.  But internet, as you well know, goes over SONET/SDH and with ATM protocol at times.  So what good is it if you create multiple parallel processes (virtual connections) and then get stuck with the 53 byte packets of SDH in a rush hour?  I assure you that fifty years from now, there will be as many physical circuits as virtual between a user and the server.  But today I doubt that between Boston and New York you find more than a dozen physical circuits.  And in the boonies, where I live, you are lucky to have a T1 shared by the whole village.  We use dial-up that goes over T1 for internet.  :)

    While not trying to be negative about any approaches, I think testers have to create the connectivity that we USERS have (an Ethernet or 4G LTE is not what we have).  Then set a simple goal like "display the text first, without images, flash, etc; then format it correctly, then go for the rest.  This way the user can get the job done as soon as text and links appear, or wait for the images, as the case may be.  And no matter the bandwidth, user shouldn't get error messages due to Firefox loading protocol.  :)
----------------
Wayne, technically speaking I found bug id=792438 better addressing the issue.  So I do not see any point in black box testing new versions of Firefox under this bug report.
----------------

Comment 14

[Patrick McManus [:mcmanus]]

(In reply to Parkhideh from comment #13)

> 1) The measure stick to what is being improved.  That is what is the goal? 
> Display what faster?  What is the users' perspective of a better browser? 

its a question we struggle with. The best automated metric we have is time until the base page's onload event fires. What we really want, but right now don't capture progamatically is something along the lines of "time to page usable above the fold".. sometimes we do that with a stopwatch. and of course any of those metrics vary according to the network conditions they are executed on {bandwidth, latency, buffering being the big three variables}. You mention "stoneridge" and that's a project that seeks to automate and provide regression testing for a range of metrics on a range of different networks.

We try and find the right balance for where the Internet is today and is going tomorrow. Right now, for desktop firefox (not mobile), that means on average around 3.5mpbs of bandwidth expecting roughly a range of 1 to 10mpbs. RTTs average around 100ms - bandwidth continues to grow but RTT is inching up. The fact that the rtt::bw ratio is changing drives some of algorithm changes (i.e. you need more parallelism to use that bandwidth so firefox evolved to have more parallelism.) That matches with numbers published by folks like Akamai who measure the capabilities of huge numbers of clients connected to their CDNs every day. Dialup isn't much of a factor. I know it exists, but focusing on that takes resources away from focusing on where the web is really going (and helping to enable that growth).

Of course, if you've got special interest in dialup environments and have patches that help that without trading off main stream use cases those patches would be welcomed!

> What priority do the developers place on the error "Firefox cannot find the
> server or load the page" under the condition of multiple tabs and low
> bandwidth to some servers? 

I do care. But if the root cause is that the conditions are so far behind the typical web user's setup then it won't get a lot of attention. We're trying to make the web a better place and I admit that for some legacy use cases firefox isn't necessarily the best tool for supporting things like 28kbps dialup in 2012.

But like I said, I do care about understanding the cause. In this particular case I think your problem is a scaled down version of a problem we are seeing on more typical broadband setups. (i.e. the home lan may have 3mbps but the Internet has 120mbps and that ratio along with the parallelism of hostname sharding can cause the same problem you're seeing at scaled down speeds).

If I felt the root cause was totally rooted specifically in a dialup setup I would have resolved this bug WONTFIX (which doesn't mean it isn't a bug), but that wasn't my conclusion. I hope the work in 792438 will help it.