Rendering of cached images is blocked by AJAX requests
Reported by
sampo.ni...@wellmo.com,
Mar 27 2016
|
||||||||
Issue descriptionChrome Version : 49.0.2623.75 (64-bit) URLs (if applicable) : http://sampo.kapsi.fi/queue/ Other browsers tested: Firefox: OK IE: OK What steps will reproduce the problem? (1) Open http://sampo.kapsi.fi/queue/ (2) Click on "Start test" (This starts 20 concurrent slow AJAX requests, and immediately adds an <img> element that points to an image that is already in the browser cache) What is the expected result? The image is rendered immediately, since it's already in the browser cache. What happens instead? The image is rendered only after 15-18 AJAX requests have received their responses. The image is as that point retrieved from the cache (not the server) and rendered. It seems that Chrome adds all image load requests to the request queue, even though the image is already in the cache and does not need a request to the server. Thus rendering of the image is blocked until sufficiently many previous requests have been processed. This happens both when the image is cached using far-future cache headers and when using a cache manifest. I've tested this on Chrome 49/Linux, Chrome 49/Win, Chromium 48/Linux and Chrome 49/Android 5.1.1 (on Samsung Galaxy S6) All other browsers I've tested (Firefox, IE10, Android 4.4 native browser) render the image immediately. This is especially troublesome for mobile web apps. Our web app uses the cache manifest to store locally all images it uses. When the app starts, we launch several AJAX requests to update data from our server. It then renders a page (depending on how it was launched), but images on that page won't render until some of the AJAX requests have been completed. On cellular networks this can take several seconds when it needs to initialize the network connection first. The only workaround I've come up with is to create <img> elements pointing to each image the may app use before launching the AJAX requests. The <img> elements don't even need to be added to the DOM. This causes the image to be fetched from the browser cache, and after that rendering it is no longer blocked by the AJAX requests. This can be tested on the page by either re-doing the test or by clicking "Create img element" first. (Performing an AJAX request to the image does not help - the example page does that to ensure the image is in the browser cache.)
,
Mar 31 2016
,
Apr 6 2016
This is an interesting case for resource prioritization. I am able to repro. Even though the resource is in the disk cache, it sits in the per-domain queue behind other resources not in the cache, and is starved. Seems like we should be checking the disk cache eagerly before letting a request sit in the per-domain queue behind requests that can't be satisfied from cache. Randy, Pat, do you see a way to address this case?
,
Apr 6 2016
This work is in flight https://codereview.chromium.org/1706903003/
,
Apr 6 2016
Great, thanks! In that case, assigning to Pat. Pat, can you confirm that this issue is fixed by your change?
,
Apr 6 2016
I presume my work will also fix this (since I'm moving throttling under the disk cache) but Pat's will probably land earlier. Still, if there's a lot to do on https://codereview.chromium.org/1706903003/, feel free to reassign it to me and it should be dealt with by handling issue 600839 .
,
Apr 6 2016
Reassigning to rdsmith@ His work on prioritization/fetch changes will eliminate the throttling as well as obsolete the changes I was working on. The hooks for my changes are actually about to get removed so it's probably a dead end at this point.
,
Apr 18 2017
Sadly, I don't think I'm going to be getting back to this anytime soon.
,
Feb 16 2018
,
May 30 2018
Artchiving this, but we are doing work on prioritization that may fix this. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by ssamanoori@chromium.org
, Mar 29 2016Labels: -Type-Bug M-51 OS-Linux OS-Mac OS-Windows Type-Bug-Regression
Status: Untriaged (was: Unconfirmed)