[Webkit-unassigned] [Bug 203058] HEAD requests are not cached

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Oct 16 16:15:54 PDT 2019


Ben Nham <nham at apple.com> changed:

           What    |Removed                     |Added
                 CC|                            |nham at apple.com

--- Comment #3 from Ben Nham <nham at apple.com> ---
I do not think it will be a huge win, because we are not blocking DOMContentLoaded or FirstMeaningfulPaint on these resources loading. It would impact AllSubresourcesLoaded time only. There are 13 resources on the Amazon snapshot in the test that exhibit this behavior. The other sites in the test would be unaffected.

For PLT5:

1. On the cold run, we'd have to do the 13 GETs, but potentially the 13 HEADs could be served out of cache.
2. On the warm run, all 26 requests (13 GETs and 13 HEADs) could potentially be served out of cache.

We open multiple connections to the PLT5 server in parallel, so we save on 6 parallel SSL session setups to the same hostname, plus 13-26 transmission delays which are parallelized onto those 6 concurrent connections. Probably looking at something 100-200 ms saved on the warm Amazon PLT.

I can try to jerry-rig up some quick and dirty patch to try to get a better estimate from the A/B bots.

Another consideration is that maybe we should not bother caching HEADs directly but just support the downgrade from a cached GET to a cached HEAD.

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20191016/46bf93b0/attachment-0001.html>

More information about the webkit-unassigned mailing list