We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Web Content Delivery
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Web Content Delivery
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
A news site loaded article hero images as standard (baseline) JPEGs. Each image was invisible for 2-3 seconds, then appeared all at once. Users saw an empty white rectangle, waited, and then the image popped in with a jarring flash. The page felt slow even though total load time was acceptable.
The same image saved as a progressive JPEG loaded differently. Within 200ms, a blurry version of the entire image appeared. Over the next 2 seconds, it sharpened in multiple passes until the final quality rendered. Same total download time. Completely different user experience. The page felt fast because the user always saw something.
This is the core insight of progressive image loading: perceived performance matters more than actual performance. A page that shows blurry content immediately and sharpens gradually feels faster than a page that shows nothing for 3 seconds and then displays perfect content.
| Technique | Placeholder Size | Visual Quality | Implementation Effort |
|---|---|---|---|
| Progressive JPEG | 0 bytes (built into file) | Blurry full image | Save as progressive in image tool |
| LQIP | 200-500 bytes | Blurred tiny image | Generate 20px thumbnail, inline as base64 |
| BlurHash | 20-30 bytes | Colored gradient approximation | Compute hash at build time, decode in JS |
| Dominant Color | 7 bytes (hex color) | Solid color background | Extract at build time, set as CSS background |
| SQIP | 800-1000 bytes | SVG with primitive shapes | Generate SVG approximation at build time |
| Solid Skeleton | 0 bytes (CSS only) | Gray placeholder box | CSS background-color: #e5e7eb |
Progressive JPEG is the simplest technique. The JPEG specification supports two encoding modes: baseline (renders top-to-bottom as data arrives) and progressive (renders the entire image at increasing quality). The progressive version is usually the same file size or slightly smaller than baseline. The only change is how the encoder orders the data.
LQIP (Low-Quality Image Placeholder) takes a different approach. A tiny version of the image (20px wide) is generated at build time, base64-encoded, and inlined directly in the HTML. The browser renders it immediately (no network request), applies a CSS blur filter, and then swaps to the full image when it loads. Medium, Pinterest, and Facebook all use LQIP.
BlurHash encodes the color distribution of an image into a 20-30 byte string. The client-side decoder turns that string into a blurred gradient that approximates the image's colors and composition. Smaller than LQIP but requires a JavaScript decoder.