[Webkit-unassigned] [Bug 81715] New: Preload scanner unhelpful on yahoo.com

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=81715

           Summary: Preload scanner unhelpful on yahoo.com
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Page Loading
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: simonjam at chromium.org
                CC: tonyg at chromium.org


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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.