- From: Patrick Meenan <pmeenan@google.com>
- Date: Thu, 16 Feb 2023 13:24:51 -0500
- To: public-web-perf@w3.org
- Message-ID: <CACPgMqWbkmK9xf=a4WC0dYt0sWqdpmhDp7Dx843Z-u5N74Yd1A@mail.gmail.com>
Would anyone be particularly concerned if we removed iFrames from the list of elements that support fetchpriority? It's not currently implemented in Chrome and as we go through the spec process, it isn't immediately clear that trying to prioritize the document fetch is the best way to control the scheduling of the iFrame. Specifically: - The fetch will be in a different document context from main-document subresources and may not be able to be scheduled within the browser relative to the other requests. - The network fetch may not be on a connection where it could be prioritized against other requests (even if they happen to be from the same origin) depending on how browsers choose to partition the network state across frames for privacy. - It doesn't control the scheduling of non-fetch iFrames. I'm thinking that we'd be better off thinking about scheduling of iFrame instantiation as it's own thing with imperatives that match what dev's would like to control. i.e. would a "defer" make sense for an iframe to delay starting the loading of an iframe until the main DOM is ready? Kind of like there's already loading=lazy for matching the image behavior.
Received on Thursday, 16 February 2023 18:47:41 UTC