Re: <img src="..." defer>

I don't know if an attribute is the right solution, better "visibility" 
prioritization or just better slideshow implementations but a pattern I 
see way too frequently when looking at sites is they will have a large 
carousel of images that rotate on a timer (or even manually) but in the 
markup the images are all listed right after each other in divs at the 
top of the HTML.  Only one of the images is visible but the fetching in 
browsers didn't apply styles to test for visibility and all of the 
images end up downloading in parallel, contending with each other so 
even the displayed image is slowed (along with other visible images).

Some hint in the markup without having to have fetched the css and 
applied the styles should both make it easy for dev's to indicate to the 
browser that the given images are less important should be an easy way 
to help both developers and those implementing the prioritization in the 
browsers.

Even with SPDY/HTTP 2 there is a race between when the markup is 
delivered and when the styles are available to be applied that makes it 
useful to have an explicit indicator.

-Pat

On 4/15/2013 5:58 AM, Andy Davies wrote:
> I've had a couple of recent examples where this would make a positive 
> difference:
>
> 1. Site with JS at the bottom of the page with images served from the 
> same hostname.
>
> In browsers like Chrome that prioritise the download of resources 
> based on type they this doesn't cause an issue but in IE for example, 
> the images were consuming all the TCP connections leading to delay in 
> downloading the JS and hence DCL firing.
>
> Sharding the images onto a separate hostname, resolves the blocking 
> issue but then they're still competing for bandwidth which may or may 
> not be a problem depending on the connection.
>
> Of course prioritised downloading is probably the real answer here but 
> are other browsers likely to implement it quicker than defer could be 
> adopted?
>
>
> 2. Holiday site with image carousel on each destination page, carousel 
> is hidden by default
>
> All images were loaded from a separate hostname but carousel ones were 
> downloaded all the time and delayed the download of over visible images
>
> There are work arounds to both these issues e.g. CDN's, use data- 
> attributes and JS to defer download etc. but my preference is an 
> approach that gives the UA hints and allows it to make appropriate 
> choices. (It also means content can be indexed without robots needing 
> to execute JS)
>
> I know this discussion is largely focused on images right now but 
> there are other areas where better hinting of priorities might help 
> performance e.g. a way of declaratively deferring loading of 3rd party 
> scripts until a given event fires e.g. onload
>
> There's a section in Andy Hume's talk from The Responsive Day out 
> (http://www.besquare.me/session/responsive-page-load/) where he talks 
> about The Guardian's experiments at splitting the page load into 
> "content, enhancements and leftovers", with the loading of the last 
> two fired by DCL and onload respectively.
>
> I guess the question is what makes sense for browsers to handle and 
> what should be left to JS.
>
> Andy
>
>
> On 14 April 2013 18:52, Jake Archibald <jakearchibald@google.com 
> <mailto:jakearchibald@google.com>> wrote:
>
>     Hi,
>
>     I know this group is looking at resource priorities, but I'm
>     interested in taking it a big further for images, and perhaps
>     other visual media such as video.
>
>     # Problems I'd like to solve:
>
>     Developers are using hacks or ending up with unnecessary downloads
>     when they use JavaScript to change the src of an image, but want
>     to provide a non-JS fallback (see
>     https://www.w3.org/Bugs/Public/show_bug.cgi?id=17842). Although
>     this particular case will be solved with something like srcset,
>     there are other cases like conditionally using an image format
>     with limited support.
>
>     Developers are using hacks to lazy-load images that are likely to
>     be outside the viewport initially. These hacks use heavy scroll
>     listeners and don't take the connection type into account.
>
>     Images within elements that are never shown are downloaded.
>
>     # "defer" behaviour:
>
>     Images with 'defer' MUST NOT download while they aren't in a
>     document, or their calculated 'display' style property is 'none'.
>
>     The download state of images with 'defer' MUST NOT delay the
>     'load' event of the window.
>
>     Images with 'defer' MAY download once they are in the document,
>     and their calculated 'display' style property is not 'none'.
>
>     Images with 'defer' MUST download once they are in the document,
>     and their calculated 'display' style property is not 'none', and
>     any part of the image would be visible within the viewport. If
>     visibility within the viewport is uncertain (due to element size
>     determined by image dimensions), the image MUST download.
>
>     There's been a lot of discussion on
>     https://www.w3.org/Bugs/Public/show_bug.cgi?id=17842, I'll try and
>     sum up the pros & cons but will ping Ilya to add anything I may
>     have missed.
>
>     # Pros
>     * Imagery in hidden elements that may never be seen by the user
>     aren't downloaded
>     * JS can modify the src of images before their original src
>     downloads, by initially hiding the image with CSS
>     * The browser gets more freedom in regards to image downloading,
>     allowing it to do the best thing given the user's connection type
>     & interaction. Eg:
>     ** If making a connection is cheap & quick (eg, fast wifi), the
>     browser may delay downloading imagery until it's in the viewport,
>     which can avoid unnecessary downloads way below the fold
>     ** If making a connection is expensive & slow (eg, 3g), the
>     browser may download all imagery that isn't calculated
>     display:none to avoid waking the radio up later and using up battery
>
>     # Cons
>     * When creating images with js, you'd need to set .defer to true
>     before setting .src, else the image would download straight away
>
>     I don't see this as a big problem, devs know the ordering matters,
>     you already have to set src after load events
>
>     * Deferred images cannot be downloaded early by preloaders unless
>     they calculate page styles & images that are at the top of the
>     page may download later as they need to wait for style calculation
>     to know if they should download or not
>
>     Not a big deal. Images are low priority downloads anyway compared
>     to JS & CSS so waiting for layout isn't a problem. Also, primary
>     imagery shouldn't use this attribute.
>
>     * Firing the load event before all images download may skew metrics
>
>     By putting 'defer' on an image you're saying it isn't required to
>     consider the page loaded. I don't think this is an issue.
>
>     * Lazy-loading isn't good on mobile connections
>
>     The browser isn't required to lazy-load. It can make the choice
>     based on the connection, which is far better than the hacky
>     JavaScript developers are using to currently perform lazy-loading.
>
>     * Developer can't indicate they'd rather have
>     aggressive lazy-loading, to save CDN costs
>
>     Feature, not a bug. Would rather the browser did what's best for
>     the connection type. The developer could always display:none the
>     images, and use a scroll listener to show them as they come into
>     view, but I wouldn't want to make that any easier.
>
>     Cheers,
>     Jake.
>
>