How to Build Your Own Progressive Image Loader
The preview image is tiny – perhaps a 20px width highly-compressed JPEG. The file can be less than 300 bytes and appears instantly to give the impression of fast loading. The real image is lazy-loaded when required.
- support responsive images to load alternative versions for larger or high-resolution (Retina) screens
- have no dependencies – it will work with any framework
- work in all modern browsers (IE10+)
- be easy to use.
Our Demo and GitHub Code
Here’s what our technique will look like:
We’ll start with some basic HTML to implement our progressive image:
<a href=”full.jpg” class=”progressive replace”>
<img src=”tiny.jpg” class=”preview” alt=”image” />
full.jpgis our large full-resolution image contained in the link
tiny.jpgis our tiny preview image.
Both images must have the same aspect ratio. For example, if
full.jpg is 800 x 200, it has a resulting aspect ratio of 4:1.
tiny.jpg could therefore be 20 x 5 but you should not use a 30px width which would require a fractionally impossible 7.5px height.
To Inline or Not Inline Images
The preview image can also be inlined as a data URI, e.g.
<img src=”data:image/jpeg;base64,/9j/4AAQSkZJ…” class=”preview” />
Inlined images appear instantly, require fewer HTTP requests and avoid additional page reflows. However:
- it takes more effort to add or change an inline image (although build processes such as Gulp can help)
- base-64 encoding is less efficient and is typically 30% larger than binary data (although this is offset by additional HTTP request headers)
- inlined images cannot be cached. They will be cached in the HTML page but could not be used on another page without re-sending the same data.
- HTTP/2 lessens the need for inline images.
Be pragmatic: inlining is a good option if the image is used on a single page or the resulting code is small, i.e. not much longer than a URL!
We start by defining the link container styles:
Continue reading %How to Build Your Own Progressive Image Loader%