Zwischen dem Klick auf einen Link und dem ersten Byte HTML passiert auf dem Server eine Menge: Routing, Session, Datenbankabfragen, Template-Rendering, oft noch ein Aufruf an ein Warenwirtschafts- oder Preissystem. Der Browser wartet in dieser Zeit - und er wartet untätig. Ohne Markup kennt er weder das LCP-Bild noch das kritische Stylesheet, und er hat nicht einmal Verbindungen zu den beteiligten Fremd-Origins aufgebaut. Im Feld ist diese Wartezeit kein Randfall: Nur 44 Prozent (HTTP Archive Web Almanac 2025) der mobilen Websites erreichen einen guten TTFB unter 0,8 Sekunden, 40 Prozent liegen im Mittelfeld und 17 Prozent gelten als schlecht (HTTP Archive Web Almanac 2025). Der informationelle Statuscode 103 aus RFC 8297 schließt genau diese Lücke: Der Server sendet schon während der Denkzeit Link-Header mit preconnect- und preload-Hinweisen, und der Browser beginnt zu arbeiten, bevor die finale Antwort überhaupt existiert (IETF RFC 8297). Dieser Artikel zeigt, was 103 tatsächlich leistet, wie es sich sauber von Resource Hints im HTML-Head und von der TTFB-Senkung selbst abgrenzt, wie die Umsetzung auf Web-Server- und Proxy-Ebene aussieht - und wo die Grenzen verlaufen.
Das Wichtigste in Kürze
- Der informationelle Statuscode 103 aus RFC 8297 vom Dezember 2017 sendet schon während der Serverdenkzeit Link-Header mit preconnect- und preload-Hinweisen, sodass der Browser Verbindungen aufbaut und kritische Dateien lädt, bevor das erste Byte HTML existiert.
- Early Hints senkt den TTFB um keine Millisekunde, sondern füllt nur die Wartezeit. Antwortet der Server ohnehin sofort, sind die regulären Hinweise in der Hauptantwort die bessere Wahl; unter rund 200 Millisekunden Denkzeit lohnt der Aufwand meist nicht.
- Als Kandidaten eignen sich renderblockierende Ressourcen und das LCP-Element: kritisches Stylesheet, Web-Font mit crossorigin, Hero-Bild und preconnect zu Fremd-Origins. Vier bis sechs Einträge genügen, prefetch wird über 103 nicht unterstützt (Chrome for Developers).
- nginx reicht 103-Antworten von Proxy-Backends seit Version 1.29.0 vom 24. Juni 2025 über die Direktive early_hints durch (nginx Changelog). Erzeugt werden die Hinweise in der Applikation oder als Profil je URL-Muster auf der Reverse-Proxy-Ebene.
- Bei einem Treffer im Full-Page-Cache bleibt kaum Denkzeit zu füllen. Der Nutzen liegt bei nicht cachebaren Antworten: personalisierte Startseiten, eingeloggte Zustände, Warenkorb und Checkout sowie Suchergebnisse mit Facetten.
- Safari wertet preload über 103 nicht aus, Cross-Origin-Weiterleitungen verwerfen die Hinweise, und Browser verarbeiten nur die erste 103-Antwort (MDN Web Docs). Den Effekt belegen erst Felddaten über mindestens 28 Tage vor und nach der Aktivierung.
Die stille Zeit zwischen Anfrage und erstem Byte
Ein Wasserfall-Diagramm macht das Problem in Sekunden sichtbar. Der erste Balken gehört der Navigationsanfrage, und bei dynamischen Seiten ist er häufig der längste: Verbindung steht, Anfrage ist raus, danach passiert auf der Leitung nichts mehr. Der Server setzt das Dokument erst zusammen. Solange kein Markup vorliegt, kann der Browser auch nichts entdecken - kein Stylesheet, keine Schrift, kein Hero-Bild. Der Preload-Scanner, der sonst so zuverlässig vorausliest, braucht Bytes zum Lesen, und die gibt es noch nicht. Im Wasserfall ist diese Phase ein leerer Streifen.
Im Feld hat dieser Streifen Gewicht. 55 Prozent (HTTP Archive Web Almanac 2025) der Desktop-Websites und 44 Prozent (HTTP Archive Web Almanac 2025) der mobilen Websites erreichen einen guten TTFB unterhalb von 0,8 Sekunden; 12 beziehungsweise 17 Prozent liegen über der Schwelle von 1,8 Sekunden und gelten als schlecht (HTTP Archive Web Almanac 2025). Beim Largest Contentful Paint sieht die Verteilung ähnlich gestaffelt aus: 74 Prozent der Desktop-Seiten, aber nur 62 Prozent (HTTP Archive Web Almanac 2025) der mobilen Seiten erreichen einen guten Wert, und auf Mobilgeräten ist der Anteil schlechter Werte mit 13 gegenüber 7 Prozent fast doppelt so hoch (HTTP Archive Web Almanac 2025). Da der LCP als Summe mehrerer Phasen entsteht - TTFB, Verzögerung bis zum Start der Ressource, Ladedauer, Renderverzögerung (HTTP Archive Web Almanac 2025) -, wandert jede Millisekunde Serverdenkzeit direkt in den Metrikwert.
Die naheliegende Antwort lautet: Serverantwortzeit senken. Das bleibt der richtige erste Schritt, und der Beitrag zur Senkung der Serverantwortzeit im Detail zeigt die üblichen Hebel von Query-Profiling bis Objekt-Cache. Nur ist die Denkzeit selten auf null zu bringen. Ein Produktdetail mit Live-Verfügbarkeit, ein personalisierter Warenkorb, eine Suchergebnisseite mit Facetten: Solche Antworten kosten Rechenzeit, die sich reduzieren, aber nicht wegdefinieren lässt. Genau an dieser Stelle setzt Early Hints an - es macht die verbleibende Denkzeit nutzbar, statt sie zu bekämpfen.
Zwei Fragen, die man auseinanderhalten sollte
Was der Statuscode 103 tatsächlich tut
RFC 8297 wurde im Dezember 2017 veröffentlicht und definiert 103 als informationellen Statuscode: Er zeigt dem Client an, dass der Server vermutlich eine finale Antwort mit den in der informationellen Antwort enthaltenen Header-Feldern senden wird (IETF RFC 8297). Wichtig ist das Wort informationell. Eine 103-Antwort beendet den Austausch nicht. Sie ist ein Zwischenruf auf derselben Verbindung, dem die eigentliche Antwort - typischerweise 200, 301 oder 404 - später folgt. Der Client darf die Hinweise nutzen, muss aber damit rechnen, dass die finale Antwort anders ausfällt.
Der Nutzinhalt steckt im Link-Header. Praktisch relevant sind zwei Beziehungstypen: preconnect baut die Verbindung zu einem Origin auf, also DNS-Auflösung, TCP-Handshake und TLS-Aushandlung, und preload startet den Download einer konkreten Datei (MDN Web Docs). Für Fremd-Origins sind dabei zwei getrennte preconnect-Angaben nötig, wenn sowohl CORS-freie als auch CORS-geschützte Ressourcen vom selben Host kommen - etwa Bilder und Schriften -, denn die Verbindungen sind nicht austauschbar (MDN Web Docs). Auch ein Content-Security-Policy-Header darf in der Early-Hints-Antwort stehen; er gilt während der Verarbeitung der Hinweise und kann von der finalen Antwort überschrieben werden (MDN Web Docs).
GET /produkt/laufschuh-x HTTP/2
Host: www.beispiel.invalid
# Server hat die Anfrage angenommen und rechnet noch:
HTTP/2 103
Link: </assets/critical.css>; rel=preload; as=style
Link: </img/hero-1600.avif>; rel=preload; as=image
Link: <https://assets.beispiel.invalid>; rel=preconnect
Link: <https://assets.beispiel.invalid>; rel=preconnect; crossorigin
# ... 350 ms später, das Rendering ist fertig:
HTTP/2 200
Content-Type: text/html; charset=utf-8
Link: </assets/critical.css>; rel=preload; as=styleDer Browser darf die Hinweise nutzen, um Verbindungen aufzuwärmen und Subressourcen anzufordern, während er auf die Hauptressource wartet (Chrome for Developers). Über preload geholte Dateien landen im HTTP-Cache und werden von der Seite später von dort gelesen (Chrome for Developers). Genau deshalb ist der Effekt kein Trick, sondern schlicht Parallelisierung: Dieselbe Arbeit passiert früher.
Regeln, die man aus der Spezifikation kennen sollte
Abgrenzung: Head-Hints und TTFB-Senkung
Die häufigste Rückfrage im Projekt lautet: Wir haben doch schon preload im Head - warum noch 103? Die Antwort steckt im Zeitpunkt. Ein Resource Hint im HTML-Head kann frühestens wirken, wenn der Browser den Head geparst hat, und dafür braucht er das erste Byte plus ein paar Pakete. Wie diese klassischen Hinweise funktionieren und wo sie sinnvoll sind, ist im Beitrag zu Resource Hints mit preload und prefetch beschrieben. Early Hints verschiebt denselben Impuls nach vorne - vor das erste Byte der finalen Antwort.
Ebenso wichtig ist die zweite Abgrenzung: Early Hints senkt den TTFB nicht. Die Serverdenkzeit bleibt exakt so lang, wie sie war; nur ihre Wirkung auf nachgelagerte Ressourcen fällt kleiner aus. Wer eine Antwortzeit von 1,8 Sekunden hat, behält sie auch nach der Aktivierung - der LCP kann trotzdem früher eintreten, weil Stylesheet und Bild bereits im Cache liegen, wenn das HTML ankommt. Umgekehrt gilt: Wenn der Server die finale Antwort ohnehin sofort schicken kann, sind Early Hints nutzlos, und die regulären Hinweise in der Hauptantwort sind die bessere Wahl (Chrome for Developers).
Die dritte Verwechslung betrifft die Transportebene. HTTP/3 und QUIC verkürzen den Verbindungsaufbau, ändern aber nichts an der Zeit, die eine Applikation zum Rendern braucht; die Unterschiede sind im Beitrag zu HTTP/3 und QUIC in der Praxis aufgeschlüsselt. Early Hints wirkt auf einer anderen Achse - es füllt Wartezeit, statt sie zu verkürzen.
| Verfahren | Wirkt ab | Was es leistet | Was es nicht leistet |
|---|---|---|---|
| Early Hints 103 | während der Serverdenkzeit | Verbindungsaufbau und Downloads kritischer Dateien vor dem ersten Byte | senkt den TTFB nicht, wirkt nur bei Navigationsanfragen |
| preload/preconnect im Head | nach dem ersten Byte | Priorisierung entdeckter und nicht entdeckter Ressourcen im Dokument | kann die Denkzeit davor nicht nutzen |
| TTFB-Optimierung | vor der Antwort | kürzere Denkzeit durch Caching, Query- und Applikationsarbeit | hat Grenzen bei personalisierten und dynamischen Antworten |
| Full-Page-Cache | bei einem Cache-Treffer | Antwort ohne Applikationslauf, TTFB im zweistelligen Millisekundenbereich | greift nicht bei personalisierten oder nicht cachebaren Seiten |
Welche Ressourcen Kandidaten sind
Die Empfehlung aus der Praxis ist eng: Hinweise auf renderblockierende Subressourcen wie synchrones JavaScript, Stylesheets oder Web-Fonts, ergänzt um die Ressourcen, die am stärksten auf LCP und First Contentful Paint wirken (Chrome for Developers). Bemerkenswert ist der Zusatz, dass die Auswahl für Early Hints von der Auswahl für Head-Hints abweichen darf (Chrome for Developers): Was man vor dem ersten Byte anstößt, folgt anderen Regeln als das, was man im Dokument priorisiert.
Das LCP-Bild
Das Hero- oder Produktbild ist auf 85,3 Prozent der Desktop-Seiten und 76 Prozent der mobilen Seiten das LCP-Element (HTTP Archive Web Almanac 2025). Ein preload mit as=image vor dem ersten Byte spart den Zeitraum, den der Preload-Scanner sonst erst nach dem HTML-Parsing eröffnet.
Das kritische Stylesheet
Renderblockierendes CSS hält den ersten Frame auf. Wer ohnehin mit Critical CSS above the fold arbeitet, kennt die Datei bereits; sie ist stabil, klein und damit ein idealer Kandidat für as=style.
Der Web-Font
Schriften werden spät entdeckt, weil sie erst nach der CSS-Auswertung angefordert werden. Ein preload mit as=font und crossorigin verkürzt diese Kette. Wie Ladestrategie und font-display zusammenspielen, zeigt der Beitrag zur Web-Font-Performance.
Der Fremd-Origin
Asset-Host, Medien-Domain oder Bild-Dienst: Für jede zusätzliche Herkunft fallen DNS, TCP und TLS an. Ein preconnect erledigt das während der Denkzeit. Für CORS-geschützte und CORS-freie Ressourcen sind zwei Angaben nötig (MDN Web Docs).
Ebenso wichtig ist die Negativliste. prefetch funktioniert über Early Hints nicht - unterstützt werden ausschließlich preconnect und preload (Chrome for Developers). Und Ressourcen, die nicht cachebar sind oder deren URL sich häufig ändert, gehören nicht in den Header: Bei versionierten Dateinamen wie main.fa231e9c.css droht ein Doppelabruf, wenn der Hinweis noch auf die vorige Version zeigt (Chrome for Developers). Wer priorisierte Ressourcen ohnehin über fetchpriority und Priority Hints steuert, sollte die Liste konsistent halten, statt zwei Wahrheiten zu pflegen.
- Höchstens vier bis sechs Hinweise - jeder zusätzliche konkurriert um dieselbe Bandbreite
- Nur Ressourcen, die auf praktisch jeder Seite dieses Typs gebraucht werden
- Stabile URLs bevorzugen; bei jedem Deploy wechselnde Hashes brauchen einen automatisierten Abgleich
- Keine Datei hinweisen, die im Dokument am Ende gar nicht verwendet wird - das ist bezahlte Bandbreite ohne Gegenwert
- Pro Seitentyp getrennt entscheiden: Startseite, Kategorie, Produktdetail und Suchergebnis haben unterschiedliche kritische Pfade
Umsetzung in nginx und auf der Proxy-Schicht
Auf der Web-Server-Ebene ist der Weg inzwischen klar beschrieben. nginx unterstützt seit Version 1.29.0 vom 24. Juni 2025 den Statuscode 103 von Proxy- und gRPC-Backends und bringt dafür die Direktive early_hints mit (nginx Changelog). Sie steht in den Kontexten http, server und location und definiert die Bedingungen, unter denen eine 103-Antwort an den Client durchgereicht wird: Ist mindestens einer der Parameter nicht leer und nicht 0, geht die Antwort raus (nginx Dokumentation). Empfangene 103-Antworten reicht nginx dabei unverändert weiter, ohne sie zu interpretieren (nginx Dokumentation).
# Nur fuer echte Navigationen und nur ueber HTTP/2 oder HTTP/3
map $http_sec_fetch_mode $early_hints {
navigate $http2$http3;
}
server {
listen 443 ssl;
http2 on;
location / {
early_hints $early_hints;
proxy_pass http://app_backend;
}
}Die Applikation bleibt damit die Quelle der Hinweise: Sie sendet die 103-Antwort samt Link-Headern, sobald sie weiß, welcher Seitentyp gerendert wird - und rechnet danach weiter. In PHP übernimmt das je nach Setup die SAPI, in Node oder Go der HTTP-Server direkt. Wer keine Kontrolle über den Applikationscode hat, kann die Hinweise auch auf der Reverse-Proxy- oder CDN-Ebene erzeugen, indem dort pro URL-Muster ein statisches Hinweisprofil hinterlegt wird. Das ist weniger präzise, aber deutlich schneller ausgerollt und für Shops mit klaren Seitentypen oft ausreichend.
- Transport prüfen: HTTP/2 oder neuer muss stehen, sonst gehört 103 abgeschaltet (IETF RFC 8297)
- Seitentypen bestimmen und je Typ ein Hinweisprofil festlegen
- Hinweise erzeugen: in der Applikation vor dem teuren Teil der Verarbeitung, oder am Proxy pro URL-Muster
- Durchreichen aktivieren:
early_hintsim passenden Location-Block setzen (nginx Dokumentation) - Gegenprobe im Netzwerk-Panel: Die 103-Antwort muss vor der 200 sichtbar sein und die genannten Ressourcen müssen früher starten
- Feldwerte über mindestens 28 Tage beobachten, bevor eine Bewertung erfolgt
Zusammenspiel mit dem Full-Page-Cache
Hier liegt der Punkt, an dem viele Projekte falsch abbiegen. Wenn eine Seite aus dem Full-Page-Cache kommt, liefert der Reverse Proxy sie in wenigen Millisekunden aus - es gibt schlicht keine Denkzeit, die sich füllen ließe. Early Hints bringt bei einem Cache-Treffer entsprechend wenig, und der Aufwand für Header-Erzeugung und Pflege steht dann in keinem guten Verhältnis. Wie sich Cache-Ebenen sinnvoll schichten lassen, beschreibt der Beitrag zu Caching-Strategien mit Varnish und Redis.
Der Nutzen liegt bei den nicht cachebaren Antworten
Zwischen beiden Welten liegt ein praktischer Sonderfall: Cache-Miss auf einer grundsätzlich cachebaren Seite. Auch dann entsteht volle Denkzeit, und 103 wirkt. In der Praxis lohnt es sich daher, die Hinweise an den Cache-Status zu koppeln, statt sie hart pro Route zu setzen. Die Aussagekraft der Analyse der Serverkonfiguration steigt deutlich, wenn Cache-Trefferquote und Denkzeit je Seitentyp erst einmal getrennt vorliegen.
Die ehrlichen Grenzen
Early Hints ist ein Fortschritt für einen Teil des Traffics, kein Allheilmittel. Das beginnt bei der Browserunterstützung: preconnect über Early Hints wird ab Chrome und Edge 103, Firefox 120 und Safari 17 ausgewertet; preload ab Chrome und Edge 103 sowie Firefox 123, in Safari dagegen nicht (Chrome for Developers). Wer also vor allem auf das Vorladen des LCP-Bildes zielt, erreicht damit einen überwiegend Chromium- und Firefox-geprägten Teil der Nutzerschaft - für die übrigen bleibt die Seite so schnell wie zuvor, aber eben nicht schneller.
- Transport: Über HTTP/1.1 wird von 103 abgeraten, solange nicht bekannt ist, dass der Client informationelle Antworten korrekt behandelt - ein Client, der sie als finale Antwort missversteht, kann alle Folgeantworten derselben Verbindung falsch zuordnen (IETF RFC 8297)
- Nur die erste Antwort: Der Server darf mehrere 103-Antworten senden, Browser verarbeiten aber nur die erste (MDN Web Docs)
- Cross-Origin-Redirect: Landet die Navigation nach einer Umleitung auf einem anderen Origin, werden die Hinweise verworfen (MDN Web Docs)
- Nur Navigationen: Für Unterressourcen, XHR oder Fetch-Aufrufe gilt der Mechanismus nicht (Chrome for Developers)
- Kein prefetch: Vorausschauendes Laden der nächsten Seite gehört in Speculation Rules für Instant-Navigation, nicht in den 103-Header (Chrome for Developers)
- Verbreitung: Die Nutzung im Feld ist niedrig und übersteigt 6 Prozent nur im Segment der Top-1-Million auf dem Desktop; in den übrigen Ranggruppen liegt sie meist unter 5 Prozent (HTTP Archive Web Almanac 2025)
Es wird empfohlen, 103-Antworten nur über HTTP/2 oder neuer zu senden, sofern nicht bekannt ist, dass der Client informationelle Antworten korrekt verarbeitet.
Der Trend zeigt allerdings nach oben: Über die vergangenen drei Jahre ist die Nutzung von gut 1 Prozent auf rund 4 Prozent gestiegen (HTTP Archive Web Almanac 2025). Zum Vergleich: fetchpriority="high" findet sich inzwischen auf 17 Prozent der mobilen Seiten mit LCP-Bild, klassisches preload für das LCP-Bild dagegen nur bei 2,1 bis 2,2 Prozent (HTTP Archive Web Almanac 2025). Der Werkzeugkasten rund um den frühen kritischen Pfad wird also insgesamt breiter genutzt.
Messplan: vorher, nachher, im Feld
Ein Effekt, der sich nicht belegen lässt, ist im Zweifel keiner. Deshalb steht am Anfang eine Basismessung und nicht die Konfiguration. Veröffentlichte Messungen großer Plattformbetreiber nennen LCP-Verbesserungen von mehreren hundert Millisekunden; in einem Vergleich unter gedrosselten Mobilbedingungen lag der Unterschied bei bis zu einer Sekunde (Chrome for Developers). Solche Werte sind Anhaltspunkte, keine Prognose für ein konkretes Projekt - die eigene Denkzeit, der eigene kritische Pfad und die eigene Nutzerstruktur entscheiden.
- Basis erheben: LCP und TTFB aus Felddaten, getrennt nach Gerätekategorie und Seitentyp, über mindestens 28 Tage
- LCP-Subparts aufschlüsseln: TTFB, Verzögerung bis zum Ressourcenstart, Ladedauer der Ressource, Renderverzögerung - der zweite Teil ist der, den Early Hints verkleinern soll
- Labormessung dagegenstellen: identische Bedingungen vor und nach der Aktivierung, mit realistischer Drosselung statt schneller Büroleitung
- Schrittweise ausrollen: ein Seitentyp zuerst, Kontrollgruppe behalten, erst danach ausweiten
- Doppelabrufe suchen: im Netzwerk-Panel prüfen, ob eine hingewiesene Datei zweimal geladen wird - das wäre ein Zeichen für falsche Cache-Header
- Nach 28 Tagen bewerten: Felddaten erneut ziehen und mit der Basis vergleichen, nicht mit dem Bauchgefühl
Der Unterschied zwischen Labor- und Felddaten ist dabei kein Detail, sondern der Kern der Bewertung; die Systematik dahinter ist im Beitrag zu Felddaten gegenüber Labormessungen beschrieben. Ergänzend lohnt der Blick auf zwei Nachbarthemen dieser Woche: Wie sich Rendering-Arbeit im Browser sparen lässt, zeigt der Beitrag zu content-visibility und eingesparter Rendering-Arbeit; wie stark ein Einwilligungsdialog den LCP verzögern kann, beschreibt der Beitrag zu Cookie-Bannern und ihrer Wirkung auf die Core Web Vitals.
Wann sich der Aufwand rechnet
Nach unserer Projekterfahrung ist Early Hints selten das erste Thema einer Optimierung und häufig ein sinnvolles fünftes. Vor ihm stehen die Klassiker: Bildformate und -größen, renderblockierendes CSS, Skriptlast von Drittanbietern, Cache-Schichten. Danach aber, wenn die Denkzeit strukturell nicht weiter sinkt, ist 103 einer der wenigen verbliebenen Hebel, die ohne Eingriff in Layout oder Redaktionsprozesse wirken.
Lohnt sich eher
Dynamische, personalisierte oder schlecht cachebare Seiten mit einer Denkzeit deutlich über 200 Millisekunden, stabile kritische Ressourcen, überwiegend Chromium-basierte Nutzerschaft.
Lohnt sich kaum
Statische Seiten aus dem Edge-Cache mit sehr kurzem TTFB, häufig wechselnde Datei-Hashes ohne Automatisierung, Angebote mit stark Safari-lastigem Publikum.
Erst prüfen
Setups hinter Legacy-Proxys, HTTP/1.1-Strecken im internen Netz und Routen mit Cross-Origin-Weiterleitungen - dort kann der Nutzen ausbleiben oder der Aufwand steigen.
Praktisch ist Early Hints damit ein typisches Ergebnis eines Server-Audits: Die Analyse zeigt, wo Denkzeit entsteht und wo sie sich nicht weiter senken lässt; die Umsetzung passiert anschließend auf Web-Server- und Proxy-Ebene, ohne dass das Frontend umgebaut werden muss. Welche weiteren Bausteine dazugehören - von der Kompression über die Cache-Schichtung bis zur Verbindungsebene -, fasst die Übersicht der Leistungen rund um Ladezeit und Core Web Vitals zusammen. Wer die Serverantwortzeit gezielt angehen möchte, findet die zugehörigen Schritte auf der Seite zur TTFB-Optimierung.
Quellen und Studien
early_hints, Version 1.29.0 vom 24. Juni 2025) sowie HTTP Archive Web Almanac 2025 (Kapitel Performance, Feldverteilungen zu TTFB und LCP). Ergänzt um Erfahrungswerte aus eigenen Server- und Frontend-Projekten (Projekterfahrung).preconnect verarbeiten Chrome und Edge ab Version 103, Firefox ab 120 und Safari ab 17; preload verarbeiten Chrome und Edge ab 103 sowie Firefox ab 123, Safari dagegen nicht (Chrome for Developers). Der Nutzen fällt damit je nach Publikum unterschiedlich aus, und ein Teil des Traffics bleibt unberührt - schneller wird die Seite dort nicht, langsamer aber auch nicht.Verwandte Artikel
PHP-Laufzeit optimieren: OPcache, JIT und FPM-Worker
Zwischen Webserver und Datenbank liegt die PHP-Laufzeit. Wie OPcache, Preloading, JIT und die FPM-Worker die Antwortzeit unter Last bestimmen.
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.
Den LCP in vier Phasen zerlegen: die Subpart-Analyse
Den Largest Contentful Paint nicht blind optimieren: TTFB, Ladeverzögerung, Ladezeit und Renderverzögerung einzeln messen und den größten Hebel gezielt angehen.