Progressive Image Display: LQIP and Blur-up for Speed

Performance has two dimensions that are often confused. Measured performance covers hard metrics such as Largest Contentful Paint, Time to First Byte and Total Blocking Time. Perceived performance describes how fast a page subjectively feels to the user. The two are related but not identical: a page can be technically fast and still feel sluggish if the screen stays empty while loading.

Research on wait perception is clear. Waits with visual feedback feel roughly 11 to 15 percent faster than waits without feedback (Nielsen Norman Group). A peer-reviewed study on skeleton screens found that pages with a gradual build-up score higher on perceived speed and ease of navigation than pages with plain loading spinners (Mejtoft, Langstrom, Soderstrom, 2018). This is exactly where progressive image display comes in: it replaces the empty area with an immediately visible preview.

The economic lever is considerable. Websites that load within one second achieve the highest conversion rates; with each additional second of load time between zero and five seconds, the conversion rate drops by about 4.42 percent on average (Portent). The probability of a bounce rises by 32 percent when load time grows from one to three seconds (Google / Think with Google). Since images make up the largest share of page weight, their display is the most direct lever on both dimensions. Readers who want to deepen the fundamentals will find them in our article on Core Web Vitals 2026.

LQIP stands for Low Quality Image Placeholder, a placeholder created from a heavily downscaled and compressed version of the target image. Typically this preview is only 16 to 40 pixels wide and is compressed so aggressively that it is just a few hundred bytes in size. Facebook popularized the technique back in 2015 and brought placeholders down to around 200 bytes (Guy Podjarny / engineering report). A file this small can be embedded directly as a Base64 string in the HTML, making it instantly available without an additional network request.

Blur-up describes the visual effect built on top of the placeholder. The tiny preview is scaled up to full display size, which makes it appear blurred, and is further smoothed with a CSS blur filter. As soon as the high-resolution image has loaded, it fades in on top with a short transition. The user experiences a soft transition from a blurry hint to the sharp image, instead of an abrupt jump from emptiness to content.

Two further placeholder variants are closely related. The dominant color fills the image box with the average or most frequent color of the image, which is extremely cheap and already provides context. SVG-based placeholders (such as SQIP) generate an abstract vector approximation from a few shapes. Which variant fits best depends on the image type and design ambition; LQIP with blur-up delivers the most lifelike preview and is therefore usually the first choice for photographic content.

A common misconception is that a placeholder automatically improves the Largest Contentful Paint. That is not necessarily the case. LCP measures when the largest content-relevant element is rendered. A heavily downscaled, blurred placeholder is usually not counted by the browser as the final LCP candidate, because it is not the actual image. Progressive display therefore mainly fills the perceptible gap until the real LCP candidate appears.

This does not mean LQIP is irrelevant for Core Web Vitals. Its decisive contribution lies with Cumulative Layout Shift. Unsized media, meaning images without reserved space, is the most common cause of layout shifts on the web; 62 percent of mobile pages contain at least one image without size attributes (HTTP Archive Web Almanac 2024). When the placeholder fills the box with correct width, height and aspect-ratio from the start, no shift occurs when the real image loads. Read more in our article on avoiding layout shifts in the shop.

In addition, the placeholder must not slow down the real LCP. When the LQIP is inline Base64 in the HTML, it slightly enlarges the HTML document; with many images this can bloat the first byte stream. The practical rule is therefore: inline LQIP only for the few images in the initial viewport, and for all other images a separate, very small placeholder or the dominant color. This keeps the critical HTML lean while the above-the-fold area is filled immediately.

Generating placeholders belongs in the build process or upload handling, not in manual work. From each source image, a tiny variant is created automatically, which is then Base64-encoded or stored as a separate file. Libraries such as sharp or libvips handle this in milliseconds per image and integrate into almost any pipeline.

A proven size for the LQIP is around 20 pixels on the longest edge. At this resolution, the file typically stays below 400 bytes under aggressive compression, which is small enough for inlining. The dominant color can be extracted in the same step by reducing the image to a single pixel and reading its color value. This color serves as a fallback background in case the placeholder has not yet decoded.

It is important to generate the placeholder in the same aspect ratio as the original image. Only then does it exactly fill the box reserved via aspect-ratio and no distortion occurs during the fade. Anyone running a complete image pipeline with WebP and AVIF adds LQIP generation as an additional step that uses the same source data.

The most robust implementation gets by with minimal JavaScript. The placeholder sits as a background or as an additional image in a container with a fixed aspect-ratio. The actual image sits on top and starts with opacity: 0. As soon as the image's load event fires, opacity is set to one via a CSS transition, and the sharp image fades softly over the blurred preview.

Two details deserve attention. First, a slight transform: scale(1.05) on the placeholder hides the transparent edges created by the blur filter. Second, the fade should be omitted when prefers-reduced-motion is active, so motion-sensitive users are not disturbed by the transition. The placeholder's alt attribute stays empty and aria-hidden, since only the full image is relevant for screen readers.

The LCP image in the initial viewport requires special handling. It should not be lazy-loaded but prioritized with fetchpriority="high", ideally additionally announced via preload in the head. Here the placeholder only fills the few milliseconds until the real image arrives. How loading priorities and deferral for below-the-fold images differ is explained in our article on lazy loading and code splitting.

Besides the client-side LQIP, an older, purely format-based approach exists: the progressive JPEG. Unlike the baseline JPEG, which builds an image line by line from top to bottom, the progressive JPEG encodes several passes of increasing detail. The browser first shows a coarse full-image version and refines it with each incoming pass. The effect resembles blur-up but requires no additional markup.

The advantage lies in simplicity: it is enough to encode the JPEG progressively, which most encoders handle via a switch. The disadvantage is the lower control over the visual transition and the fact that modern formats such as WebP and AVIF do not offer this behavior in the same form. For pages that already rely on JPEG or seek a very lightweight approach, the progressive JPEG nonetheless remains a sensible option.

Progressive display does not replace image optimization but complements it. The placeholder bridges the wait; the actual image should still be as small and fast as possible. On desktop, the median image weight per page is around 1,059 kilobytes, on mobile about 911 kilobytes (HTTP Archive Web Almanac 2024). Images thus remain the largest byte share of page weight, ahead of JavaScript and fonts.

The full potential emerges in combination: the picture element selects the appropriate size via srcset and sizes and the best format via multiple source entries (AVIF, then WebP, then JPEG). On top of that sits the blur-up mechanism with the placeholder. The user immediately sees a preview, the browser loads the smallest matching variant in the background, and the fade hides the remaining latency. The fundamentals of format choice are covered in detail in our article on image optimization with WebP and AVIF.

The number of images also plays a role. Between 2022 and 2024, the median number of image requests per page fell from 25 to 18 on desktop (HTTP Archive Web Almanac 2024). Fewer but more deliberately optimized images with progressive display deliver a calmer loading experience than many unoptimized ones. For data-intensive Shopware shops with large product catalogs, automated placeholder generation on image upload is therefore especially valuable.

Like any performance measure, progressive display needs success monitoring. On the measured side, LCP and CLS from real field data count; a stable CLS near zero confirms that placeholders and aspect-ratio work correctly. On the perception side, metrics such as First Contentful Paint and visually oriented indicators that capture the moment of first visible content help.

Field data is more meaningful than lab measurements because it reflects the actual device and network diversity of visitors. Especially on slow mobile connections, progressive display has its greatest effect, because there the span between the first placeholder and the finished image is longest. Continuous performance monitoring reveals whether the measure actually works for these user groups.

A regular image audit is recommended that answers three questions: which above-the-fold images still lack a placeholder? Where are width, height or aspect-ratio missing and thus endangering CLS? And where is an overly large inline placeholder used that bloats the critical HTML? The answers yield a prioritized action plan that addresses the most visible and most-visited images first. Such audits combine well with general frontend optimization.

Progressive image display is not a substitute for solid image optimization but its perception-oriented complement. Anyone who combines LQIP and blur-up with correctly reserved space, responsive sizes and modern formats improves both at once: measured Core Web Vitals through stable CLS and fast image delivery, and perceived speed through immediately visible visual context.

The effort remains manageable because placeholder generation can be fully automated and the blur-up mechanism gets by with little CSS and minimal JavaScript. The gain is measurable in better vitals and noticeable in a calmer, higher-quality loading experience that, especially on mobile devices, helps decide between staying and bouncing. Combined with thoughtful frontend optimization, image display thus turns from a waiting moment into a quality signal.