JPEG XL galt im Web lange als Format ohne Mehrheit: Safari zeigt es seit Version 17.0 vom September 2023 (WebKit), Chrome hatte einen frühen Versuch hinter einem Schalter wieder entfernt, Firefox wartete ab. Im Oktober 2026 ändert sich die Lage. Chrome 155 dekodiert JPEG XL ohne Schalter (Chrome for Developers), Firefox 158 soll eine Woche später folgen (Mozilla Release Calendar). Für Online-Shops stellt sich damit eine praktische Frage: Lohnt ein weiteres Bildformat neben AVIF und WebP, und wenn ja, für welche Bilder? Dieser Beitrag ordnet ein, was JPEG XL kann, wo es AVIF und WebP ergänzt und wo nicht, wie sich der vorhandene JPEG-Bestand verlustfrei umpacken lässt und wie Sie das Format mit sicherem Rückfall ausliefern – über das picture-Element oder per Accept-Header mit passend eingestelltem Cache.
Das Wichtigste in Kürze
- Chrome dekodiert JPEG XL ab Version 155 ohne Schalter (Chrome for Developers); der Chromium-Zeitplan nennt den 6. Oktober 2026 für die stabile Version (Chromium Dash). Firefox 158 ist für den 13. Oktober 2026 geplant (Mozilla Release Calendar).
- Safari zeigt JPEG XL seit Version 17.0 (WebKit), laut caniuse aber ohne progressive Dekodierung und ohne Animation (caniuse). Mit Firefox 158 unterstützen dann erstmals alle drei großen Browser-Engines das Format, wenn auch nicht im gleichen Umfang.
- Bestehende JPEGs lassen sich verlustfrei in JPEG XL umpacken und bitgenau zurückwandeln; sie werden dabei im Schnitt um 20 Prozent kleiner (WebKit). Beim LCP-Bild nutzen 57 Prozent der Desktop-Seiten JPEG (HTTP Archive Web Almanac 2025).
- Sicher ausgeliefert wird über das
picture-Element:image/jxlzuerst, dann AVIF, WebP und ein JPEG als Rückfall. Der Browser überspringt jede Quelle, deren Typ er nicht unterstützt (MDN Web Docs), und nimmt die erste passende, nicht die kleinste. - Wer per Accept-Header verhandelt, braucht
Vary: Accept(IETF RFC 9110) und muss wissen, dass Safariimage/jxldort nicht ankündigt (MDN Web Docs). Safari-Nutzer erhalten dann trotz Unterstützung die Rückfallvariante. - Vor dem Umstieg des ganzen Katalogs lohnt ein Pilot mit einer Kategorie: Bytes je Bild, Kodierzeit je Aufwandsstufe (libjxl: Stufen 1 bis 10) und den LCP getrennt nach Browser messen, danach entscheiden.
Was sich im Oktober 2026 geändert hat
Chrome 155 bringt die Dekodierung von JPEG XL in die Render-Engine Blink, umgesetzt mit jxl-rs, einem speichersicheren Dekoder in Rust (Chrome for Developers). Der Eintrag in Chrome Platform Status führt die Auslieferung ab Version 155 für Desktop und Android und als Plan die Freischaltung für alle Nutzer (Chrome Platform Status). Für die stabile Version nennt der Chromium-Zeitplan den 6. Oktober 2026 (Chromium Dash). Im Quellcode dieser Version ist die Funktion standardmäßig eingeschaltet, und Chrome kündigt das Format bei jeder Bildanfrage im Accept-Header an: image/jxl steht dort vor image/avif und image/webp (Chromium).
Firefox zieht nach. Die Versionshinweise zur Beta von Firefox 158 melden die Unterstützung von JPEG XL (Mozilla), und der Veröffentlichungskalender von Mozilla nennt für Firefox 158 den 13. Oktober 2026 (Mozilla Release Calendar). Safari zeigt JPEG XL bereits seit Version 17.0 (WebKit), allerdings mit Einschränkungen: Laut caniuse fehlen die progressive Dekodierung und animierte Bildfolgen (caniuse). Mit Firefox 158 unterstützen dann erstmals alle drei großen Browser-Engines das Format, wenn auch nicht im gleichen Umfang. Für Edge führt caniuse bislang keine Unterstützung, obwohl der Browser auf Chromium aufbaut; ob und wann Microsoft die Funktion freischaltet, sollten Sie an der eigenen Besucherstatistik und am echten Browser prüfen.
Neu ist das Format für Chrome nicht. Von Version 91 bis 109 ließ sich ein früher Dekoder über einen Schalter aktivieren, mit Version 110 verschwand er wieder (caniuse). Chrome Platform Status vermerkt dazu knapp, die experimentelle Umsetzung hinter einem Schalter sei entfernt worden (Chrome Platform Status). Der neue Anlauf setzt auf einen Dekoder in Rust, den Chrome ausdrücklich als speichersicher beschreibt (Chrome for Developers). Für Shopbetreiber zählt vor allem das Ergebnis: Ein Format, das bisher nur Safari-Nutzer zu sehen bekamen, erreicht jetzt auch Chrome- und in Kürze Firefox-Nutzer. Die folgende Übersicht fasst den Stand für vier verbreitete Browser zusammen; die Versionsangaben stammen aus den Daten von caniuse (caniuse), der Termin für Firefox aus dem Kalender von Mozilla.
| Browser | WebP | AVIF | JPEG XL |
|---|---|---|---|
| Chrome (Desktop, Android) | ab Version 32 | ab Version 85 | ab Version 155 |
| Edge | ab Version 18 | ab Version 121 | bis Version 154 nicht unterstützt, neuere Versionen bei caniuse noch nicht erfasst |
| Firefox | ab Version 65 | ab Version 93 für Standbilder, ab 113 mit Animation | ab Version 158, geplant für den 13. Oktober 2026 |
| Safari (macOS, iOS) | ab Version 14, unter macOS ab Big Sur | ab Version 16.4, teilweise ab 16.1 | teilweise ab Version 17.0: ohne progressive Dekodierung, ohne Animation |
Was JPEG XL technisch mitbringt
JPEG XL ist als ISO/IEC 18181 genormt (JPEG Committee). Chrome Platform Status fasst die Merkmale so zusammen: progressive Dekodierung für eine schneller wahrgenommene Ladezeit, großer Farbraum, HDR, hohe Bittiefe und Animation (Chrome Platform Status). Das JPEG-Gremium nennt darüber hinaus Alphakanal, Ebenen, Vorschaubilder sowie verlustfreie und progressive Kodierung und zählt E-Commerce ausdrücklich zu den Anwendungsfällen (JPEG Committee). Für Produktbilder sind drei Eigenschaften wirklich relevant, die übrigen betreffen eher Fotografie, Bildbearbeitung und Spezialanwendungen.
Verlustfreies Umpacken
Vorhandene JPEGs werden ohne erneute Kompression in JPEG XL überführt und lassen sich bitgenau in die Ausgangsdatei zurückwandeln. Eine weitere Generation mit neuen Artefakten entsteht nicht.
Progressive Anzeige
Das Bild baut sich während des Ladens in Stufen auf, Besucher sehen früher eine brauchbare Vorschau. Safari unterstützt diesen Teil laut caniuse bislang nicht.
Farbraum und HDR
Großer Farbraum, hohe Bittiefe und HDR sind im Format vorgesehen. Das hilft Sortimenten, in denen Farbtreue zählt, etwa Mode, Kosmetik oder Wohnaccessoires.
Die wichtigste Eigenschaft für bestehende Shops ist das verlustfreie Umpacken. Das JPEG-Gremium beschreibt, dass vorhandene JPEG-Dateien verlustfrei in JPEG XL überführt und dabei deutlich verkleinert werden können und dass sie sich wieder in exakt dieselbe JPEG-Datei zurückverwandeln lassen (JPEG Committee). Ein Server kann damit nur eine JPEG-XL-Datei speichern und daraus sowohl Browser mit als auch ohne JPEG-XL-Unterstützung bedienen. Apple beziffert die Ersparnis beim Umpacken auf durchschnittlich 20 Prozent (WebKit), bei einer Neukodierung aus dem Original auf bis zu 60 Prozent gegenüber JPEG (WebKit). Beide Werte sind Herstellerangaben ohne offengelegte Bildmenge; für Ihre eigenen Produktfotos gilt nur, was Sie an ihnen messen.
JPEG XL, AVIF oder WebP: wann was passt
Im Web dominiert weiterhin JPEG. Die Auswertung des HTTP Archive für 2024 zählt auf mobilen Seiten 32,4 Prozent aller Bilder als JPEG, 28,4 Prozent als PNG und 12 Prozent als WebP (HTTP Archive Web Almanac 2024). AVIF kommt auf 1,0 Prozent (HTTP Archive Web Almanac 2024). Der JPEG-Anteil ist dabei spürbar gesunken: von 40 Prozent im Jahr 2022 auf 32 Prozent im Jahr 2024 (HTTP Archive Web Almanac 2024). JPEG XL taucht in der Zählung nicht auf, weil der Messbrowser auf Chromium-Basis das Format damals nicht annahm.
Für die Ladezeit zählt vor allem das größte sichtbare Element. Auf 85,3 Prozent der Desktop-Seiten und 76,0 Prozent der mobilen Seiten ist es ein Bild (HTTP Archive Web Almanac 2025). Bei diesen LCP-Bildern liegt JPEG mit 57 Prozent der Desktop-Seiten vorn, gefolgt von PNG mit 26 und WebP mit 11 Prozent (HTTP Archive Web Almanac 2025); AVIF erreicht 0,7 Prozent (HTTP Archive Web Almanac 2025). Wer an der Dateigröße des LCP-Elements arbeitet, hat es also meist mit einem JPEG zu tun – und genau dort setzt das verlustfreie Umpacken an. Welche weiteren Hebel beim LCP-Bild greifen, beschreibt unser Beitrag zu fetchpriority und Priority Hints.
Das Format allein entscheidet dabei weniger, als der Name vermuten lässt. Im Median kommen JPEG-Bilder auf mobilen Seiten auf 2,0 Bit je Pixel, AVIF auf 1,4 und WebP auf 1,3 (HTTP Archive Web Almanac 2024). Dass WebP im Median knapp vor AVIF liegt, spricht nicht gegen AVIF, sondern zeigt, wie stark Kodiereinstellungen und Motive das Ergebnis prägen. Für eine Formatentscheidung taugen deshalb nur Messungen an den eigenen Bildern, nicht Mittelwerte aus fremden Beständen. Die folgende Tabelle ordnet typische Ausgangslagen im Shop ein.
| Ausgangslage im Shop | Naheliegende Wahl | Begründung |
|---|---|---|
| Großer Bestand an Produkt-JPEGs | JPEG XL, verlustfrei umgepackt | kleinere Dateien ohne Qualitätsverlust, Ausgangsdatei bitgenau wiederherstellbar |
| Neue Fotos aus hochwertigen Originalen | AVIF oder JPEG XL, verlustbehaftet | beide Formate an Stichproben vergleichen und je Motivgruppe entscheiden |
| Logos, Symbole, Grafiken mit Text | SVG, sonst verlustfreies WebP oder PNG | Vektoren skalieren ohne Mehrgewicht, Fotoformate helfen hier wenig |
| Animierte Produktansichten | kurzes Video statt Bildanimation | Videokodierung ist für Bewegtbild ausgelegt, Safari zeigt animiertes JPEG XL nicht |
| Farbkritische Sortimente mit HDR-Material | JPEG XL oder AVIF | beide Formate tragen großen Farbraum und hohe Bittiefe |
| Bilder ohne Pipeline, von Hand gepflegt | WebP als Grundlage | breite Unterstützung, einfache Werkzeuge, wenig Pflegeaufwand |
Bestehende JPEGs verlustfrei umpacken
Das verlustfreie Umpacken ist der risikoärmste Einstieg, weil es keine Entscheidung über Qualitätsstufen verlangt. Die freie Referenzimplementierung libjxl (libjxl), auf die das JPEG-Gremium für Teil 4 der Norm verweist (JPEG Committee), erledigt das mit Bordmitteln: Bekommt der Kodierer cjxl eine JPEG-Datei, wendet er standardmäßig die verlustfreie Neukompression an, und der Dekoder djxl stellt die ursprüngliche JPEG-Datei wieder her, wenn die Ausgabedatei auf .jpg endet (libjxl). Damit bleibt jede Umwandlung umkehrbar – ein wichtiges Argument gegenüber jeder verlustbehafteten Neukodierung, bei der sich Artefakte von Generation zu Generation addieren.
# Produkt-JPEG verlustfrei nach JPEG XL umpacken (Standard bei JPEG-Eingabe)
cjxl produkt-1600.jpg produkt-1600.jxl
# Gegenprobe: JPEG aus der JXL-Datei zurückgewinnen und Byte für Byte vergleichen
djxl produkt-1600.jxl kontrolle.jpg
cmp produkt-1600.jpg kontrolle.jpg && echo "bitgenau identisch"
# Größen in Byte gegenüberstellen
stat -c '%s %n' produkt-1600.jpg produkt-1600.jxlRechenzeit ist der zweite Punkt, den Sie vor einem Katalog-Umstieg kennen sollten. libjxl bietet in der Regel Aufwandsstufen von 1 bis 10, dazu eine Stufe 11 als Expertenoption für verlustfreie Kodierung; höhere Stufen kodieren langsamer, setzen mehr Werkzeuge ein und suchen gründlicher (libjxl). Für verlustbehaftete Kodierung steuert der Parameter --distance die Treue zum Original in Einheiten einer gerade wahrnehmbaren Abweichung: 0 ist verlustfrei, der nützlichste Bereich liegt laut Dokumentation bei 0,5 bis 3,0 (libjxl). Für einen Katalog mit vielen Tausend Bildvarianten lohnt es, die Laufzeit je Stufe an einer Stichprobe zu messen, bevor der Stapellauf eingeplant wird. Sonst konkurriert die Umwandlung um Rechenzeit mit dem Server, der eigentlich Bestellungen ausliefern soll.
Gegenprobe gehört in den Stapellauf
Auslieferung mit sicherem Rückfall
Der robusteste Weg ins Frontend ist das picture-Element. Es enthält eine oder mehrere source-Angaben mit einem MIME-Typ und am Ende ein normales img. Unterstützt der Browser den angegebenen Typ nicht, überspringt er die Quelle (MDN Web Docs) und prüft die nächste; ganz am Ende greift das img mit dem JPEG. Apple empfiehlt genau dieses Vorgehen, um JPEG XL an unterstützende Browser zu liefern und allen übrigen ein Rückfallformat zu geben (WebKit). Verbreitet ist das Element trotzdem wenig: Auf 9,3 Prozent der mobilen Seiten kommt picture zum Einsatz (HTTP Archive Web Almanac 2024).
<picture>
<source type="image/jxl"
srcset="/media/regal-800.jxl 800w, /media/regal-1600.jxl 1600w"
sizes="(min-width: 1024px) 50vw, 100vw">
<source type="image/avif"
srcset="/media/regal-800.avif 800w, /media/regal-1600.avif 1600w"
sizes="(min-width: 1024px) 50vw, 100vw">
<source type="image/webp"
srcset="/media/regal-800.webp 800w, /media/regal-1600.webp 1600w"
sizes="(min-width: 1024px) 50vw, 100vw">
<img src="/media/regal-800.jpg"
srcset="/media/regal-800.jpg 800w, /media/regal-1600.jpg 1600w"
sizes="(min-width: 1024px) 50vw, 100vw"
width="800" height="800" fetchpriority="high"
alt="Wandregal aus Eiche, Frontansicht">
</picture>Entscheidend ist die Reihenfolge. Der Browser nimmt die erste Quelle, deren Typ er kennt, nicht die kleinste Datei. Steht JPEG XL oben, laden Chrome ab Version 155 und Safari ab Version 17.0 die JXL-Variante (caniuse), auch wenn eine AVIF-Datei desselben Motivs kleiner wäre. Bei verlustfrei umgepackten JPEGs kann genau das passieren, denn das Umpacken behält die ursprüngliche JPEG-Kompression bei, während AVIF neu und verlustbehaftet kodiert. Sinnvoll ist darum eine Regel je Bildgruppe: Die Pipeline vergleicht die Dateigrößen und schreibt nur die Formate in das picture-Element, die gegenüber der nächsten Stufe tatsächlich etwas einsparen. Für das LCP-Bild bleibt es bei fetchpriority="high" und ohne Lazy Loading, wie im Beitrag zur progressiven Bildanzeige mit LQIP beschrieben.
Accept-Header, CDN und Vary
Die Alternative zum picture-Element ist die Aushandlung auf dem Server. Der Browser schickt bei jeder Bildanfrage einen Accept-Header mit den Formaten, die er annimmt; Server oder CDN liefern unter derselben Adresse die passende Variante. Chrome 155 setzt image/jxl an den Anfang dieser Liste (Chromium). Safari dagegen nennt für Bilder image/webp, image/png und image/svg+xml, aber kein image/jxl (MDN Web Docs), obwohl es das Format dekodieren kann. Eine reine Accept-Aushandlung liefert Safari-Nutzern deshalb die Rückfallvariante. Auch für Firefox 158 sollten Sie den tatsächlich gesendeten Header am echten Browser prüfen, bevor Sie sich darauf verlassen; die Übersicht bei MDN führt für Firefox bislang image/avif und image/webp, aber kein JPEG XL (MDN Web Docs).
Wer per Accept-Header verhandelt, muss den Cache darauf einstellen. RFC 9110 beschreibt, dass der Vary-Header den Cache-Schlüssel erweitert, der zu einem gespeicherten Eintrag passen muss (IETF RFC 9110). Ohne Vary: Accept kann ein Zwischenspeicher die JXL-Variante an einen Browser ausliefern, der sie nicht darstellen kann. Mit Vary: Accept entsteht dagegen je unterschiedlichem Accept-Wert ein eigener Eintrag; wie stark das die Trefferquote drücken kann, zeigt unser Beitrag zu Cookies, Vary und der Trefferquote. Viele Bilder laufen ohnehin über fremde Hosts: Auf mobilen Seiten kamen 2024 schon 62 Prozent der Bilder von einer anderen Domain als die Seite selbst (HTTP Archive Web Almanac 2024). Dann entscheidet der Bilddienst oder das CDN, ob JPEG XL erzeugt, gespeichert und korrekt ausgehandelt wird – ein Punkt, den wir bei Caching-Strategien für Shops regelmäßig mitprüfen.
# Liefert produkt.jpg.jxl statt produkt.jpg, wenn der Browser image/jxl ankündigt
map $http_accept $jxl_suffix {
default "";
"~*image/jxl" ".jxl";
}
server {
location ~* \.jpe?g$ {
types { image/jpeg jpg jpeg; image/jxl jxl; }
add_header Vary Accept;
try_files $uri$jxl_suffix $uri =404;
}
}Zwei Fallen bei der Aushandlung
add_header, erbt dieser Block standardmäßig die add_header-Anweisungen der übergeordneten Ebenen nicht mehr (nginx-Dokumentation). Sicherheits- und Cache-Header müssen dort deshalb erneut stehen. Zweitens: Ein CDN, das Vary: Accept ignoriert oder den Header nicht in den Cache-Schlüssel übernimmt, liefert womöglich die falsche Variante aus. Prüfen Sie beides mit zwei Anfragen, die sich nur im Accept-Header unterscheiden.Shopsystem, Bildpipeline und Rechenzeit
Ob JPEG XL im Shop ankommt, hängt selten am Browser, häufiger an der Kette davor. Prüfen Sie für jedes Glied, ob es das Format lesen, schreiben und weiterreichen kann: den Upload im Backend, die Erzeugung der Vorschaubilder und Größenvarianten, den Medienspeicher, das CDN und den Teil der Vorlage, der die Bildadressen schreibt. Wo ein Glied fehlt, gibt es zwei Wege. Entweder entsteht die JXL-Variante außerhalb des Shopsystems in einem eigenen Verarbeitungsschritt, der neben jedes erzeugte JPEG eine JXL-Datei legt, oder Sie warten, bis das Shopsystem das Format selbst unterstützt.
In Shopware und vergleichbaren Systemen entstehen die Größenvarianten beim Upload oder per Konsolenbefehl. Ein eigener Schritt für JPEG XL setzt danach an: Er sucht neue oder geänderte JPEG-Varianten, packt sie verlustfrei um, prüft die Rückwandlung und legt die Datei unter einem vorhersagbaren Namen ab. Die Vorlage ergänzt das picture-Element nur dann um die JXL-Quelle, wenn die Datei existiert. So bleibt der Shop funktionsfähig, auch wenn der Schritt einmal ausfällt – Besucher bekommen dann AVIF, WebP oder JPEG. Die Rechenzeit fällt einmal je Bildvariante an, nicht je Aufruf, sofern das Ergebnis gespeichert wird. Wie wir Shops darüber hinaus beschleunigen, zeigt die Seite zur Shopware-Performance; die Anpassung der Vorlagen gehört bei uns zur Frontend-Optimierung.
- Eine Kategorie mit typischen Produktfotos auswählen, deren Seiten nennenswert Besuche haben.
- Alle JPEG-Varianten dieser Kategorie verlustfrei umpacken und die Rückwandlung bitgenau prüfen.
- Bytes je Bild für JPEG, JPEG XL, AVIF und WebP gegenüberstellen und je Motivgruppe die Reihenfolge im
picture-Element festlegen. - Die Varianten ausliefern und mit mehreren Browsern gegenprüfen, welche Datei tatsächlich geladen wird.
- Felddaten zum Largest Contentful Paint getrennt nach Browser über mehrere Wochen beobachten.
- Erst danach über den gesamten Katalog, den Speicherbedarf und die Rechenzeit des Stapellaufs entscheiden.
Lohnt sich der Umstieg? Eine nüchterne Rechnung
Den größten Nutzen haben Shops mit einem großen JPEG-Bestand, der bisher nicht oder nur teilweise in moderne Formate überführt wurde. Hier spart das Umpacken Übertragungsvolumen, ohne dass jemand über Qualitätsstufen entscheiden muss, und das Original bleibt erhalten. Ein zweiter Fall sind Sortimente, bei denen Farbtreue oder HDR-Material zählt. Weniger bringt der Schritt dort, wo AVIF und WebP bereits sauber ausgeliefert werden: Dann konkurriert JPEG XL mit Formaten, die ihre Stärken schon ausspielen, und der Gewinn muss sich gegen eine weitere Variante im Speicher, zusätzliche Rechenzeit und mehr Testaufwand behaupten.
Faustregel für die Reihenfolge
picture-Element ist darum eine Messentscheidung je Bildgruppe und keine Grundsatzfrage zum Format.Messen Sie den Effekt dort, wo er entsteht. Laborwerte zeigen, ob die richtige Datei geladen wird und wie groß sie ist. Ob der Largest Contentful Paint sinkt, zeigen erst Felddaten, und zwar getrennt nach Browser: Eine JXL-Datei erhalten überhaupt nur Chrome-, Firefox- und Safari-Nutzer ab den genannten Versionen, die Safari-Nutzer davon nur über das picture-Element. Ein Vergleich über alle Besucher hinweg verwässert den Effekt und führt schnell zu dem Schluss, die Umstellung habe nichts gebracht.
So gehen wir bei einer Formatumstellung vor
In unseren Projekten zur Bilder-Optimierung beginnen wir mit einer Bestandsaufnahme: welche Formate ausgeliefert werden, welche Bilder das LCP-Element stellen und wie die Varianten heute entstehen. Danach bauen wir einen Pilotlauf für eine Kategorie auf, mit verlustfreiem Umpacken, Gegenprobe, picture-Kaskade und sauberem Cache-Verhalten. Erst wenn die Felddaten einen Vorteil zeigen, weiten wir den Schritt auf den Katalog aus. Bei Bedarf verbinden wir das mit einer Performance-Analyse des gesamten Seitenaufbaus, denn ein kleineres Bild hilft wenig, wenn das LCP-Element durch ein spätes Skript oder einen langsamen Server ausgebremst wird.
Die Grundlagen zu WebP, AVIF und responsiver Auslieferung fasst unser Beitrag zur Bildoptimierung mit WebP und AVIF zusammen. JPEG XL ergänzt diese Kette um eine weitere Stufe, ersetzt sie aber nicht: Die Arbeit an Bildgrößen, srcset, Lazy Loading außerhalb des sichtbaren Bereichs und festen Seitenverhältnissen bleibt die Grundlage, auf der jedes neue Format erst seine Wirkung entfaltet.
Quellen und Daten
image/jxl ankündigt (Chromium). Safari nennt das Format im Accept-Header für Bilder nicht (MDN Web Docs) und bekäme so die Rückfallvariante. Zudem braucht jede ausgehandelte Antwort Vary: Accept, damit Zwischenspeicher die Varianten nicht vermischen (IETF RFC 9110).Verwandte Artikel
TYPO3-Performance: Caching und Ladezeit im Griff behalten
Wie der Seiten-Cache in TYPO3 arbeitet, welche Einstellungen ihn aushebeln und wie Cache-Hash, Backends und das Deployment die Ladezeit einer Seite bestimmen.
Ungenutztes CSS finden und entfernen: schlanker laden
Wie viel CSS eine Seite braucht, wie sich der ungenutzte Anteil messen lässt und in welcher Reihenfolge sich Ballast ohne Darstellungsschäden entfernen lässt.
Weiterleitungsketten: die Ladebremse vor dem ersten Byte
Jede Weiterleitung kostet einen Roundtrip vor dem ersten Byte. So spüren Sie HTTP-, www- und Slug-Ketten auf und reduzieren sie auf einen einzigen Hop.