W3C home > Mailing lists > Public > public-web-perf@w3.org > April 2013

<img src="..." defer>

From: Jake Archibald <jakearchibald@google.com>
Date: Sun, 14 Apr 2013 18:52:48 +0100
Message-ID: <CAPy=JorA4D469BXLJhU0aW9f=KLFV5Ehp60N7PxQ7gT8OuyPAg@mail.gmail.com>
To: public-web-perf@w3.org

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

# 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

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
* 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.

Received on Sunday, 14 April 2013 17:53:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:01:18 UTC