DevTools should not warn on all unused rel=preload resources |
|||||
Issue descriptionChrome 56.0.2902.0 OSX 10.12.0 What steps will reproduce the problem? (1) Open DevTools to the console. (2) Visit https://badssl.com/ What is the expected output? No warnings related to preloaded resources. What do you see instead? After 3 seconds, three warnings like this appear: The resource https://badssl.com/front-page-icons/bad-white.svg was preloaded using link preload but not used within a few seconds from the window's load event. Please make sure it wasn't preloaded for nothing. badssl.com prefetches three small icons to avoid a flash of unload content on mouse hover. The time window where a user triggers the hover state is narrow, because the user is usually about to click the link (desktop), or has already pressed it (mobile). Any network delay for the hover/pressed makes the effect look confusing and unpolished. I see the following options if I want to keep the hover effect: - Create bogus (non-displayed) DOM elements to "use" the preloaded resources. - Manually implement my own prefetch in Javascript and use Javascript to apply the resources (note: the current approach is pure CSS). - [Specific to this case:] Because the preloaded icons are actually just color variants of the regular ones, we can use the same resource for the hover state and use CSS masks. But there is not sufficient cross-browser support for this. - Get rid of the hover effect, or substantially change it. - Live with this warning. The spec says badssl.com may "Apply resources conditionally based on arbitrary resource or application criteria." I think the current badssl.com implementation is a perfectly reasonable use case of rel=preload for a simple, modern web page. I don't think there should be a warning on my page for something that is being used correctly. I don't have enough context to propose getting rid of this warning entirely, but I don't think it's appropriate to unconditionally show a warning. yoav@: There is no context at Issue 646797 ; what was the motivation for the initial implementation of this warning? Could we address it more directly? [1] https://www.w3.org/TR/preload/#h-early-fetch-and-application-defined-execution
,
Nov 1 2016
No, preload is the right primitive. Prefetch is a low priority fetch that's optimized for "I will need this on the next page" use case, whereas the use case above wants these resources fetched with high priority and uses them on the same page. Re, warning: I agree, the warning is unnecessary in this case.. but don't have a good suggestion for how strike the right balance here. I'm leaning towards "live with it"... =/
,
Nov 1 2016
I misread the spec then in navigation basically meaning user interaction.
,
Nov 5 2016
Yeah, preload is the right primitive here, and the warning is legit (i.e. the resource wasn't used and you *should* make sure you had a good reason to preload it). I wonder if there's something to be done to better explain that to the next person that legitimately performs speculative preloads in a similar way, and if the warnings could be made less spammy in some way. Ideas welcome.
,
Nov 6 2016
Aye this is a hard one. Preload assets are requested with appropriate priority so misuse of preloading nonpriority resources early could add network contention that you don't want. We can see in the attached waterfall that the preloaded assets due delay the download of actual critical assets. (bad-white is downloaded before the github-ribbon.css, and dubious-white is downloaded before good.svg) Yoav, I'm kind of surprised to see the low priority bad-white get its request sent before github-ribbon's. (Same connection, too.) Any idea? That part aside, the page doesn't know the developer's intent if they want a preloaded image to be fetched before the page's images or after. So it assumes before and this warning kind of represents the fact that we delayed the page's assets a tad to get these which you haven't used yet. That seems mostly fair, though I can imagine we link to a page of docs w/ the message that explains this a tad more.
,
Nov 6 2016
Separately... Shubhie, Pavel: I wonder if it'd make sense to migrate this warning to PerformanceMonitor / Live Violations: https://codereview.chromium.org/2474073005
,
Nov 6 2016
Paul - I haven't looked deeper (traveling in the next few days...) but I have seen instances in the past where a lower priority fetch gets requested before the higher priority requests make it in. https://crbug.com/651160 is one. If that's indeed the case here, maybe we should think of a generic mechanism that would somewhat delay sending low priority requests (or with H2, we can rely on the server acting on their priority and delaying their responses).
,
Nov 8 2016
Re: PerformanceMonitor / Live Violations: Good point. I'd like to start with a set of violations that are obvious performance issues, but we should certainly add this to "rules under consideration".
,
Nov 18 2016
,
Nov 18 2016
,
Nov 21 2016
There is one difference between perf violations and logging at this point: violations are only captured while client is attached. Migrating this to violations would make console empty upon opening, having no retrospective failures. Seems like we should have perf violations and non-perf violations. This one is clearly non-perf-related.
,
Dec 1 2016
There is another scenario where this happens incorrectly. 1. Open page with correct use of preload (fonts). 2. Open Developer Tools. In Network, disable cache. 3. Close Chrome. 4. Open Chrome. Tab is restored. 5. View Console. The same message is printed twice per font.
,
Oct 4 2017
As per comment #2 and #5
,
Oct 9 2017
What is the recommended approach to get rid of these warnings? Use them in bogus elements? Try to preload them after document.body's "load" event fires? |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by pdk...@gmail.com
, Nov 1 2016