Bug 81715 – Preload scanner unhelpful on yahoo.com

• Status: NEW
• Component: Page Loading

[James Simonsen]

Someone reported that Chrome loads yahoo.com 100+ ms slower than other browsers. Analyzing the trace shows that the subresources loaded later. One cause was that the preload scanner failed to preload the resources. This happened for two reasons:

1. The preload scanner will only preload CSS and JS before first paint. It could've loaded 30 other resources 30 - 80 ms earlier without that restriction. IIRC, the restriction was added to prevent responses from interfering with first paint, which regressed some benchmark.

2. The entire document was already available to the HTML parser. The parser ended up discovering all of the resources before first paint. So, this check didn't actually serve its intended purpose. It just slowed down the load.

Requesting all 30 resources took 750 us, so it's not a significant delay. That suggests this logic is intended to prevent us from getting responses too quickly. I propose we implement the throttling on the response side, instead of the request side. Getting the requests out on the wire (or at least to the network stack) sooner is better. Network is often the weakest link.

[Tony Gentilcore]

> 1. The preload scanner will only preload CSS and JS before first paint. It could've loaded 30 other resources 30 - 80 ms earlier without that restriction. IIRC, the restriction was added to prevent responses from interfering with first paint, which regressed some benchmark.

At one point the PreloadScanner would not load any resources in the body while parsing the head. I investigated that in bug 45072 and relaxed that restriction so that the PreloadScanner would always load scripts and stylesheets, but left the restriction in place for images. Details in the bug.

We should definitely revisit this as I was only testing with a limited subset of sets and it is certainly possible I missed something.

> Requesting all 30 resources took 750 us, so it's not a significant delay. That suggests this logic is intended to prevent us from getting responses too quickly. I propose we implement the throttling on the response side, instead of the request side. Getting the requests out on the wire (or at least to the network stack) sooner is better. Network is often the weakest link.

I like that idea a lot.

[Antti Koivisto]

Yeah, it is a good idea to revisit these assumptions.