41.63 KB, image/png
From bug 1301988 comment 8: (In reply to Patrick McManus [:mcmanus]) > (In reply to bugzilla) > > (In reply to Patrick McManus [:mcmanus]) > > > > > we use a history algorithm to try and decide how many connections an origin > > > typically needs rather than this hardcode. Obviously there are plusses and > > > minuses. > > > > If the history algorithm worked on connections 3 - 6 rather than 2 to 6, and > > connection 2 was openned simulaneously with connection 1 wouldn't this small > > change give the best of both worlds given most modern websites have > > considerably more than a handful of constituent objects? > > > modern websites run http/2 which only need one.. so we're chasing a > shrinking market there. but I don't want to make a big fuss - 2 wouldn't be > a problem > > > > > Otherwise IE always going to be faster as it is initially opening 2 > > connections and then parsing the html counting the objects to simultaneously > > opening up to 6 connections. > > > > When combined with downloading the favicon after the page has loaded this > > makes a real world difference to the user's perception of a browser’s speed. > > For example in the attached waterfall example Firefox hasn't started to > > render the first row of images when IE has completed the page.
Created attachment 8794202 [details] Waterfall graphs showing Nightly connections sitting idle Nightly is opening the connections earlier which is good. However the connections are sitting idle until the header objects have been processed rather than loading synchronously. In the attached example this will shave a further 120ms of the page load bringing Nightly much closer to IE's speed. Nightly https://www.webpagetest.org/result/160923_93_CFZ/1/details/#waterfall_view_step1 IE 11 https://www.webpagetest.org/result/160923_B4_D6Z/1/details/#waterfall_view_step1
Initializing second connection it would be ok.
Quick update on opening 2 connections straight after the DNS has replied. Chrome opens 3 initial connections straight after the DNS instead of 2 under some circumstances. (A further 3 instead of 4 are then opened later after the html has completed loading.) The trigger for this approach seems to be distance to the server.
Mass wontfix for bugs affecting firefox 52.
status-firefox52: affected → wontfix
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P2
You need to log in before you can comment on or make changes to this bug.