You may have encountered progressive images on Facebook and Medium. A blurred low-resolution image is replaced with a full-resolution version when the element is scrolled into view:
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:
See the Pen responsive-image by SitePoint (@SitePoint) on CodePen.
Download the code from GitHub
We’ll start with some basic HTML to implement our progressive image:
<img src="tiny.jpg" class="preview" alt="image" />
full.jpg is our large full-resolution image contained in the link href, and
tiny.jpg is 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%
The Todo-Backend project provides an arena to showcase backend tech stacks. It defines a simple web API in the form of a to-do list and users can create their own identical APIs using various tech stacks.
As for now, there are over 80 Todo-Backend projects implemented in a wide range of tech/framework combinations, including JVM (Java/Scala/Kotlin/Closure), C#/.Net, Ruby, Python, PHP, Golang, Haskell, and a lot more. On each language/platform, there are one or more implementations based on different framework/data persist solution combinations.
This is the sixth part in a series on WebAssembly and what makes it fast. If you haven’t read the others, we recommend starting from the beginning. On February 28, the four major browsers announced their consensus that the MVP of WebAssembly is complete. This provides a stable initial version that browsers can start shipping. This […]