[whatwg] responsive images srcalt proposal

[pghj]

Thanks to some feedback I got, I worked out the preloading algorithm in
some more detail.


It will enable efficient preloading of images in my srcalt proposal, as
well as images with the proposed postpone attribute, and improve overall
performance. The algorithm is meant to supersede the simple preload
scanners that are currently implemented.


In short, this algorithm will, when downloading is stalled by JS, calculate
layout on a separate DOM as if javascript were disabled, in order to decide
which srcalt, postponed and CSS background images should be downloaded and
with what priority.


 1.) Start downloading all CSS, JS, and <img> without srcalt and postpone
attributes (*1). Always reserve one socket for downloading each of the
three file types (*2). Prioritize on CSS and JS.

2.) As soon as all CSS and the document source are downloaded, do one of
the following:

a.) If all JS has finished running, do layout and continue with step 3.

b.) If JS is still running, build an independent DOM as if javascript were
disabled, do layout on that and continue with step 3.

3.) Clear the download queue for images. With the given DOM and layout,
start downloading the required images from CSS backgrounds, <img>
src/srcalt and visible postponed images. Prioritize on images that will be
immediately visible to the user.

4.) As soon as JS finishes, and step 2b was used, re-invoke step 3 for the
real DOM (possibly altered by JS). Evaluate whether (too many) unnecessary
images (srcalt/postpone/css backgrounds) were downloaded. If so, mark this
for each category (srcalt/postpone/css) in a cache. Next time the same url
is visited, delay downloading this category until JS finishes (*3).


 *1.) Images without postpone attribute are required for the load event.

*2.) A server might have specific performance problems serving one type of
file. By reserving sockets downloading can continue on the other file
type(s).

*3.) JS altering the DOM to such an extend that the wrong images got
downloaded is probably quite rare, but this step will counter the bandwidth
penalty after the first visit. Developer modes of browsers should issue a
warning when this occurs.


 Compared to the current preload scanners, this implementation will:


 * support srcalt responsive images,

* support postpone attributes on images,

* allow for earlier download of postponed images and CSS backgrounds,

* can prioritize on all images that are immediately visible to the user.


 In this scenario srcalt images can never start downloading until document
source and all CSS has been obtained. This might result in a slight
performance loss when responsive images are used. However, since most HTML
and CSS downloads fast (once the server starts sending) and CSS is mostly
cached anyway, in practice this will effect only a very few page visits.

Depending on available bandwidth and user preference, UAs could also
compensate for this delay by preloading a srcalt candidate by making an
educated guess.


Thank you for reading,

Josh