Bug 81719 – ResourceLoadScheduler casuses too much delay

• Status: NEW
• Component: Page Loading

[James Simonsen]

Chrome loads yahoo.com 100+ ms slower than other browsers. One of the causes is that subresources start loading significantly later. The ResourceLoadScheduler is part of the problem. While the document is finishing parsing, 30 resources are discovered and queued in the ResourceLoadScheduler. The scheduler then queues a timer to fire later that actually issues the requests to the network layer. By the time that timer fires, requests have been queued between 10 - 90 ms, leaving the network (one of our most precious resources) idle during this time. We should be much more aggressive about issuing those requests.

Apparently the purpose of the ResourceLoadScheduler is to try to request JS and CSS in front of images, even if they're discovered out-of-order. Some buffering is needed to do this, but this is too much.

[Tony Gentilcore]

> Apparently the purpose of the ResourceLoadScheduler is to try to request JS and CSS in front of images, even if they're discovered out-of-order. Some buffering is needed to do this, but this is too much.

The code does know about the priority. Perhaps when the highest priority items are enqueued, the requests could be issued immediately?

git annotate says japhet and antti are good people to consult about how this should work.

[Gavin Peters]

(In reply to comment #1)
> > Apparently the purpose of the ResourceLoadScheduler is to try to request JS and CSS in front of images, even if they're discovered out-of-order. Some buffering is needed to do this, but this is too much.
> 
> The code does know about the priority. Perhaps when the highest priority items are enqueued, the requests could be issued immediately?

Yes.  Embargoing to onload is too late.

The network stack itself should be able to deal with multiple requests coming in; the only problem is if you present high priority requests after low priority requests: an aggressive stack may potentially have requests already open.

So your proposed solution just embargoing the low priority requests until the highest priority requests have gone out should work, and make things much faster.


> 
> git annotate says japhet and antti are good people to consult about how this should work.

[Tony Gentilcore]

> Yes.  Embargoing to onload is too late.
Point of clarification: nothing is embargoed to onload. In fact, the loading of all of the subresources is a prerequisite for onload.

[Gavin Peters]

(In reply to comment #3)
> > Yes.  Embargoing to onload is too late.
> Point of clarification: nothing is embargoed to onload. In fact, the loading of all of the subresources is a prerequisite for onload.

Yes, correct: embargoing for 90ms is too late is what I should have written, had I been thinking clearly.

And in fact, subresources can't be embargoed until onload, except possibly prefetch and prerender requests, which don't "count" towards the onload event.