Transloadit

Was ist progressives Rendering?

Progressives Rendering zeigt nutzbare Teile oder zunehmend vollständige Versionen von Inhalten an, sobald Daten verfügbar werden. So wird das Gesamtergebnis nicht zurückgehalten, bis alle Ressourcen geladen oder alle Verarbeitungsschritte abgeschlossen sind.

So funktioniert progressives Rendering

Progressives Rendering ist eine Strategie, die Encoding, Transport, Parsing und Darstellung umfasst; es ist kein einzelnes Medienformat. Auf Dateiebene speichert ein progressives JPEG das Bild als Folge von Scans mit steigender Qualität. Ein Decoder kann daher schon aus dem ersten Scan eine grobe Version des gesamten Bildes anzeigen und sie mit jedem weiteren Scan verfeinern. Ein PNG mit Interlacing überträgt seine Pixel in sieben Durchgängen. Auf Dokumentebene kann ein Server HTML streamen, sodass der Browser die äußere Seitenstruktur und Platzhalter anzeigt, während langsamere Abschnitte noch erzeugt werden. Der Streaming-Server-Renderer von React sendet beispielsweise zuerst den Fallback einer Grenze vom Typ <Suspense> und später den eigentlichen Inhalt. Die beiden Ebenen betreffen unterschiedliche Wartezeiten: Die Aufschlüsselung von Largest Contentful Paint auf web.dev erfasst die Zeit bis zum ersten Byte des HTML-Dokuments und die Ladezeit der Bildressource selbst als separate Teilzeiten. Ein früher gesendetes Dokument verkürzt daher nicht den Download eines darin referenzierten Bildes. Der Browser kann diesen Download jedoch früher beginnen, wenn das früh eintreffende HTML bereits die Bild-URL enthält. In beiden Fällen hilft die frühe Ausgabe nur, wenn sie tatsächlich früh auf dem Bildschirm erscheint. Reservierter Platz für die endgültige Ausgabe verhindert, dass deren Einsetzen das umgebende Layout verschiebt.

Wichtige Fakten

  1. Welche Bildformate können progressiv gerendert werden? JPEG, wenn es im progressiven Modus codiert ist, PNG und GIF, wenn sie im Interlacing-Verfahren vorliegen, sowie JPEG XL, wobei MDN darauf hinweist, dass Safari JPEG XL erst nach dem vollständigen Download rendert. WebP kann keine Vorschau des gesamten Bildes schrittweise verfeinern: Laut Googles WebP-FAQ bietet es keine progressive Aktualisierung oder Aktualisierung per Interlacing im Sinne von JPEG oder PNG, sondern nur inkrementelles Decodieren, bei dem Zeilen angezeigt werden, sobald deren Bytes eintreffen. Bei AVIF hängt es vom Encoding und vom Anzeigeprogramm ab. Die AVIF-Spezifikation unterstützt progressives Decodieren durch mehrschichtige Bilder, stellt dem Renderer aber frei, nur die höchste Ebene anzuzeigen; das Programm avifenc von libavif erzeugt mit --progressive eine solche Datei, und das Änderungsprotokoll von libavif nennt Chrome als Anzeigeprogramm, das die Ebenen progressiv rendert. Der Formatleitfaden von MDN erklärt dagegen, dass AVIF kein progressives Rendering unterstützt und Dateien vor der Anzeige vollständig heruntergeladen werden müssen. Er ergänzt, dass die geringere Größe von AVIF-Dateien dies außer bei größeren Dateien oft ausgleicht. Eine Konvertierung zu WebP oder AVIF erhält daher nicht von sich aus den Effekt einer zunächst groben Darstellung: Prüfen Sie bei AVIF die Encoder-Einstellung und die Zielbrowser; andernfalls muss ein separater Platzhalter diesen Effekt liefern.
  2. Welchen Aufwand verursacht ein progressives JPEG? Vor allem Aufwand beim Decodieren, weniger bei der Dateigröße. Laut libjpeg-Dokumentation sind progressive Dateien oft etwas kleiner als sequenzielle Dateien gleicher Qualität, und das endgültige Bild ist identisch. Sie erklärt außerdem, dass jeder angezeigte Scan beim Decodieren ungefähr so viel Aufwand verursacht wie ein vollständiges Bild gleicher Größe und dass Zwischenscans nur angezeigt werden, wenn die Anwendung den Modus für gepufferte Bilder der Bibliothek nutzt; andernfalls liest der Decoder jeden Scan und gibt nur das endgültige Bild zurück. Ob Betrachter die schrittweise Verfeinerung sehen, hängt daher vom verwendeten Decoder ab, nicht nur von der Datei.
  3. Warum erscheint eine gestreamte Seite trotzdem auf einmal? Meist hält etwas zwischen Renderer und Browser die Bytes zurück. nginx puffert Proxy-Antworten standardmäßig und leitet Daten nur dann direkt beim Empfang weiter, wenn proxy_buffering deaktiviert ist oder der Upstream X-Accel-Buffering: no sendet, einen Header, den nginx auf entsprechende Konfiguration mit proxy_ignore_headers hin ignorieren kann; der Leitfaden zum Selbsthosting von Next.js ergänzt, dass manche Cloud-Load-Balancer Antworten standardmäßig puffern und dass auch Reverse-Proxys zwischen Load-Balancer und Anwendung Antworten mit Chunked-Übertragung ohne Pufferung weiterleiten müssen. Für eine effiziente Komprimierung wird ein Abschnitt der Ausgabe gepuffert; die README-Datei der Express-Middleware compression beschreibt dies für Server-Sent Events und bietet res.flush(), um die Übertragung der teilweise komprimierten Antwort an den Client zu erzwingen. Die Anwendung kann den Effekt selbst aufheben: React dokumentiert, dass es kein progressives Laden gibt, wenn der Stream in onAllReady statt in onShellReady gestartet wird. Selbst wenn Bytes frühzeitig eintreffen, können vorab geladenes CSS oder JavaScript das Rendering weiterhin blockieren.
  4. Verursacht progressives Laden Layoutverschiebungen? Das kann passieren, wenn der Platz für später eintreffende Inhalte nicht reserviert ist. Googles Leitfaden zu Cumulative Layout Shift zählt Bilder ohne Abmessungsangaben und dynamisch eingefügte Inhalte zu den häufigsten Ursachen für einen schlechten Wert. Er empfiehlt, bei Bildern und Videos immer width und height anzugeben oder den Platz mit aspect-ratio in CSS zu reservieren. Ein Bild, das innerhalb eines Bereichs mit bekannter Größe schrittweise verfeinert wird, verschiebt nichts in seiner Umgebung; ein Ersatzbild, dessen Größe vom Platzhalter abweicht, kann die umgebenden Inhalte verschieben, sofern nicht bereits ein Container den Platz reserviert.

Wann progressives Rendering wichtig ist

Planen Sie progressives Rendering ein, wenn wesentliche Seiten- oder Medieninhalte vor nachrangigen Details priorisiert werden können. Instabile Abmessungen oder eine ungünstige Reihenfolge der Aktualisierungen können stattdessen zu Layoutverschiebungen und ablenkenden visuellen Änderungen führen.

So hilft Transloadit beim progressiven Rendering

Der Robot /image/resize von Transloadit verfügt über den Parameter progressive, der Interlacing für die Ausgabe aktiviert, damit Browser zuerst eine niedrig aufgelöste Version des gesamten Bildes anzeigen können; die Funktion ist standardmäßig deaktiviert. Bei Formaten, für die das nicht gilt, kann ein Step, der ein Bild erzeugt, mit output_meta einen BlurHash oder ThumbHash extrahieren, einen kompakten Platzhalter zur Anzeige, während das vollständige Bild lädt. Bildergebnisse im Assembly Status enthalten außerdem width, height und aspect_ratio in ihren Metadaten. Diese Angaben benötigt eine Seite, um den Platz für das Bild zu reservieren, bevor es eintrifft.

Die Robot-Dokumentation nennt eine Zunahme der Dateigröße für progressive, ohne die betroffenen Ausgabeformate anzugeben. Das unterscheidet sich von den obigen Angaben der libjpeg-Dokumentation zu progressiven JPEGs. Messen Sie daher mit Ihren eigenen Bildern und Ihrem Ausgabeformat. Die ThumbHash-Extraktion wird als Metadatengebühr abgerechnet; die aktuellen Konditionen finden Sie in der Robot-Dokumentation.

Entdecken Sie Transloadits Möglichkeiten zur Auslieferung

Quellen

Machen Sie aus Medienwissen eine funktionierende Pipeline

Verbinden Sie Uploads, Verarbeitung, KI, Storage und Auslieferung über eine deklarative API – um Encoding-Stack, Skalierung und ständig wechselnde Formate müssen Sie sich nicht selbst kümmern.

Transloadit kostenlos ausprobieren