Progressive Bildanzeige: LQIP und Blur-up für Tempo

Performance hat zwei Dimensionen, die oft verwechselt werden. Die gemessene Performance umfasst harte Metriken wie Largest Contentful Paint, Time to First Byte und Total Blocking Time. Die gefühlte Performance beschreibt, wie schnell eine Seite für den Nutzer subjektiv wirkt. Beide hängen zusammen, sind aber nicht identisch: Eine Seite kann technisch schnell sein und sich trotzdem träge anfühlen, wenn der Bildschirm während des Ladens leer bleibt.

Die Forschung zur Wartezeit-Wahrnehmung ist eindeutig. Wartezeiten mit visuellem Feedback fühlen sich rund 11 bis 15 Prozent schneller an als Wartezeiten ohne Rückmeldung (Nielsen Norman Group). Eine peer-reviewte Studie zu Skeleton Screens fand, dass Seiten mit gestaffeltem Aufbau bei wahrgenommener Geschwindigkeit und Navigationskomfort höher bewertet werden als Seiten mit blossen Ladespinnern (Mejtoft, Långström, Söderström, 2018). Genau hier setzt die progressive Bildanzeige an: Sie ersetzt die leere Fläche durch eine sofort sichtbare Vorschau.

Der wirtschaftliche Hebel ist beträchtlich. Websites, die innerhalb einer Sekunde laden, erreichen die höchsten Conversion-Raten; mit jeder zusätzlichen Sekunde Ladezeit zwischen null und fünf Sekunden sinkt die Conversion-Rate im Schnitt um etwa 4,42 Prozent (Portent). Die Wahrscheinlichkeit eines Absprungs steigt um 32 Prozent, wenn die Ladezeit von einer auf drei Sekunden wächst (Google / Think with Google). Da Bilder den größten Anteil am Seitengewicht stellen, ist ihre Darstellung der direkteste Hebel auf beide Dimensionen. Wer die Grundlagen dazu vertiefen will, findet sie in unserem Beitrag zu den [Core Web Vitals 20261.

LQIP steht für Low Quality Image Placeholder, also einen Platzhalter aus einer stark verkleinerten und komprimierten Version des Zielbildes. Typischerweise ist diese Vorschau nur 16 bis 40 Pixel breit und wird so stark komprimiert, dass sie nur wenige Hundert Byte gross ist. Facebook popularisierte die Technik bereits 2015 und brachte Platzhalter auf rund 200 Byte herunter (Guy Podjarny / Engineering-Bericht). Eine derart kleine Datei lässt sich direkt als Base64-String in das HTML einbetten, sodass sie ohne zusätzlichen Netzwerk-Request sofort verfügbar ist.

Blur-up beschreibt den visuellen Effekt, der auf dem Platzhalter aufsetzt. Die winzige Vorschau wird auf die volle Anzeigegröße hochskaliert, wodurch sie unscharf wirkt, und mit einem CSS-Weichzeichner zusätzlich geglättet. Sobald das hochauflösende Bild geladen ist, wird es mit einer kurzen Überblendung darüber eingeblendet. Der Nutzer erlebt einen weichen Übergang von der verschwommenen Ahnung zum scharfen Bild, statt eines abrupten Sprungs von Leere zu Inhalt.

Eng verwandt sind zwei weitere Platzhalter-Varianten. Die dominante Farbe füllt die Bildbox mit der durchschnittlichen oder häufigsten Farbe des Bildes, was extrem günstig ist und bereits Kontext liefert. SVG-basierte Platzhalter (etwa SQIP) erzeugen eine abstrakte Vektor-Näherung aus wenigen Formen. Welche Variante am besten passt, hängt vom Bildtyp und vom Designanspruch ab; LQIP mit Blur-up liefert die naturgetreueste Vorschau und ist daher für fotografische Inhalte meist die erste Wahl.

Ein verbreitetes Missverständnis ist, dass ein Platzhalter automatisch den Largest Contentful Paint verbessert. Das ist nicht zwangsläufig der Fall. Der LCP misst, wann das größte inhaltlich relevante Element gerendert ist. Ein stark verkleinerter, unscharfer Platzhalter wird vom Browser in der Regel nicht als finaler LCP-Kandidat gewertet, weil er nicht das eigentliche Bild ist. Die progressive Anzeige füllt also vor allem die wahrnehmbare Lücke, bis der echte LCP-Kandidat erscheint.

Das bedeutet nicht, dass LQIP für die Core Web Vitals irrelevant ist. Der entscheidende Beitrag liegt beim Cumulative Layout Shift. Unsized Media, also Bilder ohne reservierten Platz, sind die häufigste Ursache für Layoutverschiebungen im Web; 62 Prozent der mobilen Seiten enthalten mindestens ein Bild ohne Größenangaben (HTTP Archive Web Almanac 2024). Wenn der Platzhalter die Box mit korrektem width, height und aspect-ratio von Anfang an ausfüllt, entsteht beim Nachladen des echten Bildes keinerlei Verschiebung. Mehr dazu im Beitrag zur [Vermeidung von Layout Shifts im Shop1.

Zudem darf der Platzhalter den echten LCP nicht ausbremsen. Wenn das LQIP als Inline-Base64 im HTML steht, vergrößert es das HTML-Dokument geringfügig; bei vielen Bildern kann das den ersten Bytestrom aufblähen. Die Praxisregel lautet daher: Inline-LQIP nur für die wenigen Bilder im initialen Viewport, für alle übrigen Bilder ein separater, sehr kleiner Platzhalter oder die dominante Farbe. So bleibt das kritische HTML schlank, während der Bereich oberhalb der Falz sofort gefüllt ist.

Die Erzeugung der Platzhalter gehört in den Build-Prozess oder in die Upload-Verarbeitung, nicht in die manuelle Handarbeit. Aus jedem Quellbild entsteht automatisch eine winzige Variante, die anschließend Base64-kodiert oder als separate Datei abgelegt wird. Bibliotheken wie sharp oder libvips erledigen das in Millisekunden pro Bild und lassen sich in nahezu jede Pipeline einbinden.

Eine bewährte Größe für das LQIP liegt bei etwa 20 Pixel auf der längsten Kante. Bei dieser Auflösung bleibt die Datei bei aggressiver Kompression typischerweise unter 400 Byte, was klein genug für das Inlining ist. Die dominante Farbe lässt sich im selben Schritt extrahieren, indem das Bild auf einen einzigen Pixel heruntergerechnet und dessen Farbwert ausgelesen wird. Diese Farbe dient als Fallback-Hintergrund, falls der Platzhalter noch nicht dekodiert ist.

Wichtig ist, den Platzhalter im selben Seitenverhältnis wie das Originalbild zu erzeugen. Nur dann füllt er die per aspect-ratio reservierte Box exakt aus und es entsteht keine Verzerrung während der Überblendung. Wer eine durchgängige [Bild-Pipeline mit WebP und AVIF1 betreibt, ergänzt die LQIP-Erzeugung als zusätzlichen Schritt, der dieselben Quelldaten nutzt.

Die robusteste Implementierung kommt mit minimalem JavaScript aus. Der Platzhalter liegt als Hintergrund oder als zusätzliches Bild in einem Container mit fester aspect-ratio. Das eigentliche Bild liegt darüber und startet mit opacity: 0. Sobald das load-Ereignis des Bildes feuert, wird die Deckkraft per CSS-Transition auf eins gesetzt, und das scharfe Bild blendet weich über die unscharfe Vorschau.

Zwei Details verdienen Aufmerksamkeit. Erstens kaschiert ein leichtes transform: scale(1.05) auf dem Platzhalter die durch den Weichzeichner entstehenden transparenten Ränder. Zweitens sollte die Überblendung bei aktiviertem prefers-reduced-motion entfallen, damit bewegungsempfindliche Nutzer nicht durch den Fade gestört werden. Das alt-Attribut des Platzhalters bleibt leer und aria-hidden, da nur das vollwertige Bild für Screenreader relevant ist.

Für das LCP-Bild im initialen Viewport gilt eine Sonderbehandlung. Es sollte nicht lazy geladen, sondern mit fetchpriority="high" priorisiert werden, idealerweise zusätzlich per preload im Head angekündigt. Der Platzhalter füllt hier nur die wenigen Millisekunden bis zum Eintreffen des echten Bildes. Wie sich Lade-Prioritäten und Aufschub für Bilder unterhalb der Falz unterscheiden, erläutert unser Beitrag zu [Lazy Loading und Code-Splitting1.

Neben dem clientseitigen LQIP existiert ein älterer, rein bildformatbasierter Ansatz: das progressive JPEG. Anders als das Baseline-JPEG, das ein Bild Zeile für Zeile von oben nach unten aufbaut, kodiert das progressive JPEG mehrere Durchgänge zunehmender Detailtiefe. Der Browser zeigt zunächst eine grobe Vollbild-Version und verfeinert sie mit jedem eintreffenden Durchgang. Der Effekt ähnelt dem Blur-up, benötigt aber kein zusätzliches Markup.

Der Vorteil liegt in der Einfachheit: Es genügt, das JPEG progressiv zu kodieren, was die meisten Encoder per Schalter beherrschen. Der Nachteil ist die geringere Kontrolle über den visuellen Übergang und die Tatsache, dass moderne Formate wie WebP und AVIF dieses Verhalten nicht in gleicher Form bieten. Für Seiten, die ohnehin auf JPEG setzen oder einen sehr leichtgewichtigen Ansatz suchen, bleibt das progressive JPEG dennoch eine sinnvolle Option.

Progressive Anzeige ersetzt nicht die Bildoptimierung, sondern ergänzt sie. Der Platzhalter überbrückt die Wartezeit; das echte Bild sollte dennoch so klein und schnell wie möglich sein. Auf dem Desktop liegt das mediane Bildgewicht pro Seite bei rund 1.059 Kilobyte, auf Mobilgeräten bei etwa 911 Kilobyte (HTTP Archive Web Almanac 2024). Bilder stellen damit weiterhin den größten Byte-Anteil am Seitengewicht, noch vor JavaScript und Schriften.

Das volle Potenzial entsteht im Zusammenspiel: Das picture-Element wählt über srcset und sizes die passende Größe und über mehrere source-Einträge das beste Format (AVIF, dann WebP, dann JPEG). Darüber liegt die Blur-up-Mechanik mit dem Platzhalter. Der Nutzer sieht sofort eine Vorschau, der Browser lädt im Hintergrund die kleinste passende Variante, und die Überblendung kaschiert die verbleibende Latenz. Die Grundlagen der Formatwahl behandelt unser Beitrag zur [Bildoptimierung mit WebP und AVIF1 im Detail.

Auch die Anzahl der Bilder spielt eine Rolle. Zwischen 2022 und 2024 sank die mediane Zahl der Bild-Requests pro Seite von 25 auf 18 auf dem Desktop (HTTP Archive Web Almanac 2024). Weniger, aber gezielter optimierte Bilder mit progressiver Anzeige liefern ein ruhigeres Ladeerlebnis als viele unoptimierte. Für datenintensive [Shopware-Shops1 mit grossen Produktkatalogen ist die automatisierte Erzeugung von Platzhaltern beim Bild-Upload daher besonders wertvoll.

Wie jede Performance-Maßnahme braucht auch die progressive Anzeige eine Erfolgskontrolle. Auf der Seite der gemessenen Werte zählen LCP und CLS aus echten Felddaten; ein stabiler CLS nahe null bestätigt, dass Platzhalter und aspect-ratio korrekt greifen. Auf der Seite der Wahrnehmung helfen Metriken wie First Contentful Paint und visuell orientierte Kennzahlen, die den Zeitpunkt des ersten sichtbaren Inhalts erfassen.

Felddaten sind aussagekräftiger als Labormessungen, weil sie die tatsächliche Geräte- und Netzvielfalt der Besucher abbilden. Besonders auf langsamen Mobilverbindungen entfaltet die progressive Anzeige ihre größte Wirkung, denn dort ist die Spanne zwischen erstem Platzhalter und fertigem Bild am längsten. Ein [kontinuierliches Performance-Monitoring1 macht sichtbar, ob die Maßnahme bei diesen Nutzergruppen tatsächlich greift.

Empfehlenswert ist ein regelmäßiges Bild-Audit, das drei Fragen beantwortet: Welche Above-the-Fold-Bilder besitzen noch keinen Platzhalter? Wo fehlen width, height oder aspect-ratio und gefährden damit den CLS? Und wo wird ein zu grosser Inline-Platzhalter verwendet, der das kritische HTML aufbläht? Aus den Antworten entsteht ein priorisierter Maßnahmenplan, der die sichtbarsten und meistbesuchten Bilder zuerst adressiert. Solche Audits lassen sich gut mit der allgemeinen [Frontend-Optimierung1 bündeln.

Progressive Bildanzeige ist kein Ersatz für solide Bildoptimierung, sondern deren wahrnehmungsorientierte Ergänzung. Wer LQIP und Blur-up mit korrekt reserviertem Platz, responsiven Größen und modernen Formaten kombiniert, verbessert beides zugleich: die gemessenen Core Web Vitals durch stabilen CLS und schnelle Bildauslieferung sowie die gefühlte Geschwindigkeit durch sofort sichtbaren visuellen Kontext.

Der Aufwand bleibt überschaubar, weil die Platzhalter-Erzeugung sich vollständig automatisieren lässt und die Blur-up-Mechanik mit wenig CSS und minimalem JavaScript auskommt. Der Gewinn ist messbar in besseren Vitals und spürbar in einem ruhigeren, hochwertigeren Ladeerlebnis, das gerade auf mobilen Geräten über Verbleib oder Absprung mitentscheidet. In Verbindung mit einer durchdachten [Frontend-Optimierung1 wird die Bildanzeige so vom Wartemoment zum Qualitätssignal.