New issue
Advanced search Search tips

Issue 832563 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Apr 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Cached files report longer times for download in the Developer Network than they do for retrieving from the network

Reported by paul.le...@nielsen.com, Apr 13 2018

Issue description

Chrome Version       :  65.0.3325.181 
URLs (if applicable) : https://7commgames.com.au/schedule
Other browsers tested:
  Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
     Safari: FAIL Version 11.1 (12605.1.33.1.3)
    Firefox: OK 59.0 (64-bit)
       Edge:

What steps will reproduce the problem?
(1) Empty browser cache
(2) Open the network tab in developer tools
(3) In the network tab filter box enter "translations/en_GB.json"
(4) Download the URL https://7commgames.com.au/schedule
(5) Once the page is downloaded you should see the file https://widgets.sports.gracenote.com/translations/en_GB.json has been downloaded twice
(6) Verify the first request came from the network, the second from the cache
(7) Note the timings of each request


What is the expected result?
The download time of the file retrieved from the cache should be less (<10 ms i would expect) as it has been preloaded earlier in the page load.


What happens instead?
The second request is retrieved from the cache (disk cache in this instance) and has a reported time of 849ms (the first network request was 149ms)

Please provide any additional information below. Attach a screenshot if
possible.
I have seen this issue with other URLs and on other pages whilst working to optimise our page download.
In this example the first request is triggered by the insertion of a "link" element to preload the file. This link element is inserted using javacript. 
<link rel="preload" href="//widgets.sports.gracenote.com/translations/en_GB.json" as="fetch">
(I am not sure this is relevant as it seems to be working)


 
Screen Shot 2018-04-13 at 09.52.52.png
110 KB View Download
Cc: susan.boorgula@chromium.org
Components: Blink>Loader
Labels: -Type-Bug -Pri-3 hasbisect-per-revision RegressedIn-63 Triaged-ET FoundIn-67 FoundIn-66 Target-67 Target-66 Target-65 FoundIn-65 M-68 Needs-Triage-M65 FoundIn-68 Target-68 OS-Linux OS-Mac OS-Windows Pri-1 Type-Bug-Regression
Owner: yhirano@chromium.org
Status: Assigned (was: Unconfirmed)
paul.lemon@ Thanks for the issue.

Able to reproduce this issue on Windows 10, Mac OS 10.12.6 and Ubuntu 14.04 on the latest Canary 68.0.3398.0 and reported version 65.0.3325.181 as per the original comment.

Bisect Information:
===================
Good Build: 63.0.3207.0 (Revision - 499829)
Bad Build : 63.0.3208.0 (Revision - 500160)
Attached are the screen shots for reference.

On executing the per-revision bisect script, below is the Changelog URL:

https://chromium.googlesource.com/chromium/src/+log/e32943af2683a9aef43ad21fc98fbe4b392a3fb5..ceffb6f0de79979f9fa7024b0ab8b640659bc04a

From the above Changelog, suspecting the below change:
Reviewed-on:  https://chromium-review.googlesource.com/647346

yhirano@ Please check and confirm if this issue is related to your change, else help us in assigning to the right owner.

Thanks.
832563-good.PNG
111 KB View Download
832563-bad.PNG
111 KB View Download
Status: WontFix (was: Assigned)
It's possible that fetching from cache takes longer than fetching from network, especially when the former is throttled by the scheduler.
Hi,

The response to the bug seems to indicate it that is known and accepted that retrieving from the cache can take about 5.5x longer than from the network (149ms versus 849ms)

I would respectfully ask that this is considered as a bug as it seems to contradict expected behaviour of a disk cache.

If this is not considered as a bug - it does contradict the strategy of optimising user download experience by preloading.

Paul

Sign in to add a comment