preload as="image" serializes javascript fetches
Reported by
benedikt...@googlemail.com,
Mar 5 2017
|
|||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3015.2 Safari/537.36 Steps to reproduce the problem: This is my html: <html xmlns="http://www.w3.org/1999/xhtml"> <head> <link rel="preload" as="image" href="images/logo-clear.png" /> <link rel="stylesheet" type="text/css" href="templates/slider.css"/> <link rel="stylesheet" type="text/css" href="views/home/home.css"/> <script type="text/javascript" src="templates/main.js"></script> <script type="text/javascript" src="includes/assets/AlbumViewer/AlbumViewer.min.js"></script> <script type="text/javascript" src="templates/slider.js"></script> </head> <body> <div id="hcolor"> </div> </body> </html> Note, that the css files and js files are empty and have no content. The webserver is HTTP/2 enabled (behind cloudflare and origin server is also h2-capable). When using the <link rel="preload" as="image" href="images/logo-clear.png" /> in Performance tab in devtools it can be observed that the fetching of the javascript is serialized (c.f. attached screenshots). When the link rel="preload" is omitted the javascripts are all fetched in parallel. I have observed the behavior for http2 and http1.1. Furthermore, the serialization happens if the I use the HTTP Link Header Link: <images/logo-clear.png>; rel=preload; as=image instead of the preload tag. I've set up test pages: https://www.benediktwolters.de/image_no_preload/ https://www.benediktwolters.de/image_preload/ to repruduce a fresh browserinstance and cold-cache is required. What is the expected behavior? I would expect the fetching to be deterministic, regardless of which image is preloaded. What went wrong? In the preload case the javascripts are fetched sequentially while when preload was omitted the javascripts are fetched in parallel. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 58.0.3015.2 Channel: n/a OS Version: 4.4.0-64-generic Flash Version:
,
Mar 7 2017
,
Mar 17 2017
Reproduced it on Linux Chromium 59.0.3045.0 (Developer Build) (64-bit).
,
Apr 6 2017
M58 is almost close to stable, can we have a fix before M59 hits stable.
,
Apr 11 2017
I'd like to keep this in backlog, but I don't think this is a release blocker consulting the guideline: https://www.chromium.org/issue-tracking/release-block-guidelines
,
Apr 17 2017
It looks to me like this was fixed. I can reproduce this on 57.0.2987.133, but cannot reproduce on Canary 60.0.3072.0. OP, can you please confirm this does not happen on Canary?
,
Apr 17 2017
Screenshots of it working:
,
May 26 2017
,
Sep 25 2017
I see this resolved in Canary as well... I thought it could be blamed on using image fetchs as a script priority signal, but that seems to be ignoring preloads [1]. Maybe it was something related to H2 throttling which was recently unshipped[2] jkarlin@ - does that make sense? Allada@ - I think we can WONTFIX this, regardless of the original cause. [1] - https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/loader/fetch/ResourceFetcher.cpp?sq=package:chromium&dr=CSs&l=175 [2] https://groups.google.com/a/chromium.org/d/msg/blink-dev/ChqGX8UyHz8/KvejkZG0AgAJ
,
Sep 25 2017
H2 throttling could have been the cause. If so, it's still something in experiment on canary/dev but shouldn't be seen on beta or stable.
,
Dec 13 2017
As per comment #9 |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by nyerramilli@chromium.org
, Mar 6 2017