1301988 - favicon is loaded while the page loads, therefore slows down other resources and thereby slows down page rendering

Status: NEW

(Firefox :: Tabbed Browser, defect, P3)

Description

[bugzilla]

Attachment: Page loading waterfall graphs

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20160911004011

Steps to reproduce:

If you specify the favicon in the html headers of a webpage on the server:
<link rel="icon" type="image/png" href="/images/favicon-16x16.png" sizes="16x16">
Firefox loads the favicon as it processes the headers. (If there is no header entry then Firefox loads the favicon.ico after the page has finished rendering.)


Actual results:

By not delaying the favicon until after the page this slows the page rendering as a spearate http request has to be sent and waited for. 

This is illustrated in this waterfall page, Firefox takes 1.5 seconds to render the page whereas IE11 takes under 1 second to show the same test webpage.

Firefox:
https://www.webpagetest.org/result/160911_86_N7T/1/details/#waterfall_view_step1

ie11
https://www.webpagetest.org/result/160911_1V_N7Z/1/details/#waterfall_view_step1



Expected results:

Chrome loads a 16x16 & 32x32 after the page has loaded
IE11 loads a 32x32 after the page has loaded
IE10 loads a favicon.ico after the page has loaded
Safari loads a 16x16 after the page has loaded

Firefox should also load a Favicon specified in the headers after the page has otherwise finished loading.

Comment 1

[alex_mayorga]

¡Hola reporter!

This looks like a legit bug yet I'm unable to find the exact component so trying "General".

Might it be that you know which component is best suited for this one?

¡Gracias!
Alex

Comment 2

[:Gijs (he/him)]

Just the favicon file would not really make such a big difference as you state, when you look at the webpagetest stuff (1 vs 1.5 seconds) - more like 100ms, tops - and I'm not convinced that the webpagetest stuff is a reliable source of how different engines deal with this problem. There's also no indication which version of Firefox was tested, what the e10s state was, etc.

All that said, I wouldn't be opposed to loading the favicon later... Marco, could we use the page-icon scaffolding to do a local load and only replace with the remote image after the page has fully loaded, or something?

Comment 3

[bugzilla]

The amount of improvment will depend on the position the website designer places the directive in the headers, the distance the webserver is from the user, and the slowest section of the connection between the user and the server. 

To make Firefox as fast as IE 11 would require two separate tweeks:

1) loading of the favicon at the end as suggested above.
2) Requesting two http connections, as IE 11 does, straight after the DNS has returned the Server IP address.

Microsoft started making the request for two connections straight after the DNS in IE9. IE8 like Firefox currently does, loads the second connection later in the process. IE8 is much slower than IE9.

If you wanted to make Firefox faster than IE then you could simulaneously request more connections straight after the DNS has loaded. 

Microsoft thinks these small incremental tweeks are worth implementing. W2k16 server also fixes the TCP slow start window issue (long blue lines in the attached example) this shaves a further 200ms off the speed of the example page.

Comment 4

[:Gijs (he/him)]

(In reply to bugzilla from comment #3)
> 2) Requesting two http connections, as IE 11 does, straight after the DNS
> has returned the Server IP address.
> 
> Microsoft started making the request for two connections straight after the
> DNS in IE9. IE8 like Firefox currently does, loads the second connection
> later in the process. IE8 is much slower than IE9.

This is an orthogonal networking layer change. Patrick, do we have a bug on file for something like this, or would it just be a default pref change, or...?

Comment 5

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

(In reply to :Gijs Kruitbosch from comment #2)
> All that said, I wouldn't be opposed to loading the favicon later... Marco,
> could we use the page-icon scaffolding to do a local load and only replace
> with the remote image after the page has fully loaded, or something?

I think it may be wise to load the icon a little bit later, (TBD when).
From a favicons API point of view, there's nothing preventing that, the only problem may be if the page is destroyed soon, we may never get the icon (the recent code you added that clears the favicon request on inner-window destruction) so I can't tell if waiting the whole load makes sense, maybe DOMContentLoaded could be enough?

Regarding the local load, currently, as you may remember, both the tab and the favicon service fetch the icon (likely one will fetch from the network cache), so I'm not sure what you mean by local load, we could surely use a "page-icon:url" as a placeholder and if we have a local icon it will do, otherwise will show the default favicon.

(In reply to bugzilla from comment #3)
> Microsoft started making the request for two connections straight after the
> DNS in IE9. IE8 like Firefox currently does, loads the second connection
> later in the process. IE8 is much slower than IE9.

I wonder (out of curiosity) if setting network.http.pipelining to true would actually help this case and if it is actually similar to what IE does. IIRC there was an effort to enable this by default a couple years ago and then it just disappeared. Patrick will know more.

Comment 6

[Patrick McManus [:mcmanus]]

(In reply to :Gijs Kruitbosch from comment #4)
> (In reply to bugzilla from comment #3)
> > 2) Requesting two http connections, as IE 11 does, straight after the DNS
> > has returned the Server IP address.
> > 
> > Microsoft started making the request for two connections straight after the
> > DNS in IE9. IE8 like Firefox currently does, loads the second connection
> > later in the process. IE8 is much slower than IE9.
> 
> This is an orthogonal networking layer change. Patrick, do we have a bug on
> file for something like this, or would it just be a default pref change,
> or...?

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.

(In reply to Marco Bonardo [::mak] from comment #5)

> I wonder (out of curiosity) if setting network.http.pipelining to true would
> actually help this case and if it is actually similar to what IE does. IIRC
> there was an effort to enable this by default a couple years ago and then it
> just disappeared. Patrick will know more.

http/1 pipelines are a flawed technology in general. H2 and priorities are the right answer to focus on.

Comment 7

[bugzilla]

(In reply to Patrick McManus [:mcmanus] from comment #6)

> 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?

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.

Comment 8

[Patrick McManus [:mcmanus]]

(In reply to bugzilla from comment #7)
> (In reply to Patrick McManus [:mcmanus] from comment #6)
> 
> > 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.

Comment 9

[Patrick McManus [:mcmanus]]

I would appreciate it if you would make a bug in core::networking about this.. specifically a default of 2 connections for base page loads (not for all origins - which have a weirder distribution)

Comment 10

[Dão Gottwald [:dao]]

(In reply to Patrick McManus [:mcmanus] from comment #9)
> I would appreciate it if you would make a bug in core::networking about
> this.. specifically a default of 2 connections for base page loads (not for
> all origins - which have a weirder distribution)

filed bug 1304295

Comment 11

[bugzilla]

Attachment: Further waterfall graphs showing Nightly connections sitting idle

Thanks for opening the new thread Dão.

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

Comment 12

[bugzilla]

Attachment: IE 11 & Nightly waterfalls compared

There is also an issue with external javascript loading earlier than necessary

If <script async type="text/javascript" src="main.js"></script> is placed at the end of the code just before </body> IE 11 waits until after the other page objects have loaded before loading the async script, whereas Firefox loads it first. 

The speed improvements should be in line with loading the <link rel="icon" type="image/png" href="/favicon-16x16.png" sizes="16x16"> after the other objects. 

In the example above such changes would shave a further 120ms of the visual completion of the page. (Pages with much larger external javascript files would see far greater improvements especially on servers with the TCP slow start issue, pages with less objects and people on slower connections.


The other improvement of moving the javascript to later in the load would mean the start of page html rendering could begin a lot earlier. In the attached example IE 11 starts at 50ms whereas Nightly starts at 78ms.

Comment 13

[bugzilla]

The other improvement of moving the javascript to later in the load would mean the start of page html rendering could begin a lot earlier. In the attached example IE 11 starts at 50ms whereas Nightly starts at 78ms.

Should have read 500ms & 780ms  (.5 sec & .78 sec) 

Careless, sorry.