Was dein Server mit deinem PageSpeed-Score macht.

Die meisten Performance-Ratschläge hören beim Browser auf: Bilder komprimieren, JavaScript verzögern, ungenutztes CSS entfernen. Das ist richtig, und es hat eine Obergrenze, denn jede dieser Optimierungen wirkt erst, nachdem der Server geantwortet hat. Wenn das erste Byte zu spät kommt, schlecht komprimiert ankommt oder aus einem Prozess stammt, der gerade geschlafen hat, holt keine Frontend-Arbeit diese Zeit zurück. Das haben wir gefunden, als wir aufgehört haben, an den Seiten zu drehen, und angefangen haben, die Maschine darunter zu messen — auf unseren eigenen drei Produktionsdomains, nicht auf einem Testsystem.

Die Server-Checkliste: was du prüfst und wie ein gutes Ergebnis aussieht

Geh sie in dieser Reihenfolge durch. Die ersten vier entscheiden, ob sich alles Weitere überhaupt verlässlich messen lässt; der Rest entscheidet, ob das Ergebnis bei echten Besuchern und Bots ankommt.

Dieselben Bytes, auf drei Arten

Byte-identische Inhalte, per SHA-256 geprüft, derselbe Server, dieselbe Anfrage. Gemessen auf unserem eigenen Hosting im August 2026.

Der Server hat kein eigenes Audit

PageSpeed Insights hat keinen Wert für „dein Hosting ist langsam“. Es gibt keine Kategorie dafür und keine Zahl, die ihn isoliert. Der Server taucht indirekt auf, in Metriken, die nach Frontend-Problemen aussehen: Die Zeit bis zum ersten Byte speist First Contentful Paint, das wiederum Largest Contentful Paint begrenzt, und Lighthouse benennt ihn — als Reduce initial server response time — erst dann, wenn es ohnehin schon offensichtlich schlecht ist.

Google wertet einen TTFB von 0,8 Sekunden oder weniger als gut und alles über 1,8 Sekunden als schlecht, gemessen vom Beginn der Navigation bis zum Eintreffen des ersten Bytes. Dieses Fenster enthält Weiterleitungen, DNS, Verbindungsaufbau und TLS-Aushandlung, nicht nur die Denkzeit deiner Anwendung — eine Redirect-Kette und ein langsamer Handshake werden dir also genauso angerechnet wie langsamer Code.

Genau deshalb wird die Serverebene übersprungen. Sie beschwert sich nie unter eigenem Namen. Sie deckelt nur still, was jede andere Optimierung erreichen kann.

Komprimierung: wir haben das „Brotli“ unserer Plattform gemessen, und es verlor gegen ihr eigenes gzip

Komprimierung ist die Servereinstellung mit der größten Hebelwirkung — und zugleich die, von der am häufigsten angenommen wird, sie sei längst erledigt. Bei uns war sie aktiviert. Der Antwort-Header sagte das auch. Alles sah korrekt aus.

Dann haben wir die Byte-Zahlen bei identischem Inhalt verglichen, und das Brotli der Plattform erzeugte größere Dateien als ihr eigenes gzip — 75.377 Byte gegenüber 54.284 beim selben HTML der Startseite, wie die Komprimierungstabelle oben zeigt. Die Ursache war eine Streaming-Implementierung mit einem sehr kleinen Komprimierungsfenster, die nie genug vom Dokument auf einmal sah, um jene Wiederholungen zu finden, für die sich Brotli überhaupt lohnt. Gegenüber einem sauber konfigurierten Brotli lieferte sie das 2,7-Fache an Bytes aus.

Ein Header, der sagt, etwas sei an, ist kein Beleg dafür, dass es wirkt. Der Test ist, dieselbe URL dreimal abzurufen — einmal mit Brotli, einmal mit gzip, einmal ohne — und die Byte-Zahlen selbst zu vergleichen. Wenn „Brotli“ nicht deutlich das Kleinste von dreien ist, tut es seine Arbeit nicht, egal was der Header behauptet.

Genau diese eine Einstellung zu reparieren hat alle drei unserer Domains auf einen mobilen Score von 99 bis 100 gebracht, und dafür musste keine einzige Seite geändert werden.

Die Langsamkeit, die in keinem Score auftaucht

Hier der Fehler, der uns überzeugt hat, dass diese Ebene einen eigenen Artikel verdient. Dieselbe URL, bei derselben Bytegröße, wurde fast immer in 20 bis 60 ms ausgeliefert — und gelegentlich in 700 bis 2000 ms. Startest du PageSpeed Insights, erwischst du meist die schnelle Variante. Startest du es erneut, erwischst du vielleicht die langsame und schiebst den Unterschied auf das Werkzeug.

Es war keine Streuung. Der Anwendungsprozess wurde alle zehn Minuten von einem Wartungsskript beendet und neu gestartet, und der nächste Besucher nach jedem Neustart bezahlte einen vollen Kaltstart. Im schlimmsten Zustand landeten 11,7 % der Anfragen auf einem Kaltstart von 1,1 bis 2,0 Sekunden; nach der Reparatur waren es 1,6 %, und die Prozesslaufzeit stieg von zehn Minuten auf über dreieinhalb Stunden.

Keine Frontend-Änderung behebt das, und keine einzelne PageSpeed-Messung bringt es ans Licht. Es ist ein Problem der Verteilung, und ein Score ist eine einzige Stichprobe. Der einzige Weg, es zu sehen: dieselbe URL ein paar hundert Mal abrufen, jede Antwortzeit erfassen und sich die langsamsten Prozent ansehen statt des Durchschnitts. Wenn dein p95 auf einer immer gleich ausgelieferten Seite das Zehnfache des Medians beträgt, liegt das Problem unter der Anwendung, nicht in ihr.

Bei Shared Hosting teilst du mehr als nur Speicherplatz

Shared-Tarife und günstige Managed-Tarife begrenzen, wie viele Prozesse ein Konto laufen lassen darf, und diese Grenze gilt meist fürs ganze Konto, nicht pro Website. Wir sind dagegen gelaufen: Jeder Deploy ließ einen alten Anwendungsprozess zurück, jeder hielt dauerhaft Speicher und einen Prozessplatz belegt, und sie summierten sich, bis das Konto nahe an seiner Grenze stand. Websites, die seit Wochen niemand angefasst hatte, wurden wegen Deploys auf einer anderen Domain langsamer.

Daraus folgen zwei Dinge. Lies die Prozess- und Speichergrenzen eines Tarifs, bevor du seinen Preis liest, denn sie entscheiden, ob eine Website an ihrer eigenen Wartung degradiert. Und behandle eine Verlangsamung, die „aus dem Nichts“ auftaucht, als Frage danach, was sonst noch auf dem Konto wohnt, nicht nur danach, was sich im Code geändert hat.

Die Schicht vor dem Server kann Google komplett aussperren

Ein CDN oder eine Web Application Firewall sitzt vor der Anwendung und beantwortet manche Anfragen, ohne sie je zu fragen. Genau das ist ihr Zweck — und genau dort richtet ein einziges Auswahlfeld echten Schaden an.

Auf einer unserer Domains begann eine auf „mittel“ gesetzte CDN-Sicherheitsstufe, die Sitemap mit einem 403 und einer Browser-Prüfseite zu beantworten. Ein Browser bestand diese Prüfung, ohne dass der Besucher etwas merkte. Googlebot löst keine JavaScript-Prüfung, um eine Sitemap abzuholen, also meldete die Search Console schlicht, sie könne die Datei nicht abrufen, mit null gefundenen Seiten — und am Code der Website war nichts falsch.

Nichts davon erscheint in PageSpeed Insights, denn PageSpeed fragt eine Seite an und bekommt eine Seite. Es erscheint Wochen später in der Search Console, als Indexierungsproblem. Die Prüfung, die sich lohnt: robots.txt und sitemap.xml mit einem Crawler-User-Agent abrufen und bestätigen, dass beide mit 200 und dem richtigen Content-Type antworten.

Cache-Header sind eine Serverentscheidung, keine des Frameworks

Dein Framework kann ein Cache-Verhalten vorschlagen; der Webserver, das CDN und das Hosting-Panel können es jeweils überschreiben. Wir haben erlebt, wie eine Regel weiter oben im Stapel eine Richtlinie auf Anwendungsebene komplett ersetzt hat, ohne dass die Anwendung davon wusste. RFC 9111 definiert, was die Direktiven bedeuten, aber nicht, wer in deinem Stapel das letzte Wort hat — das ist eine Eigenschaft deiner Konfiguration, und der einzige Weg, sie zu kennen, ist, die Antwort-Header an der Edge zu lesen statt den Code, der sie setzen wollte.

Unsere Regel ist simpel: Was von sich behauptet, im Cache zu liegen, rufst du zweimal ab und vergleichst. Zeigt die zweite Antwort keinen Cache-Treffer und kein Alter, liegt es nicht im Cache, egal was in der Konfigurationsdatei steht.

Und nicht nur PageSpeed

Den Score als Ziel zu behandeln ist genau das, was Serverarbeit optional wirken lässt — denn eine gut gebaute Seite kann auf einem schlecht konfigurierten Server meistens gut abschneiden. Die Kosten landen woanders.

Bots nehmen einen überproportionalen Anteil der langsamen Antworten mit, weil sie dauerhaft anfragen statt in den kurzen Schüben, die ein Mensch erzeugt — ein Fehler, der eine von neun Anfragen trifft, begegnet Google also ständig, über Tausende von URLs. Die Ersparnis aus der Komprimierung wird bei jeder Anfrage eingelöst, von jedem Besucher und jedem Bot, nicht einmalig beim Build. Und die Seite, die gelegentlich zwei Sekunden braucht, ist die, die entscheidet, ob jemand wartet — was dir kein Median in irgendeinem Bericht je zeigen wird.

Der Score ist ein nützlicher Indikator und ein schlechtes Ziel. Was du mit guter Serverkonfiguration in Wahrheit kaufst, ist das schlechteste Erlebnis auf deiner Website, nicht das übliche.

Wie wir das in der Praxis angehen

Wenn wir Hosting und Betrieb übernehmen, kommt der Serverdurchgang vor jeder Seitenarbeit — denn Seitenarbeit wird an dem gemessen, was der Server tut, und diese Messung ist wertlos, solange sich der Server darunter bewegt. Die Checkliste oben im Artikel ist genau die Reihenfolge, die wir verwenden, und sie ist bewusst sortiert: Die ersten vier Punkte entscheiden, ob du dem trauen kannst, was du danach misst, der Rest entscheidet, ob das Ergebnis wirklich bei Besuchern und Bots ankommt.

Nichts davon braucht Zugang zur Anwendung. Jeder Punkt lässt sich von außen mit einer Handvoll Anfragen prüfen, und genau das macht ihn auch zum schnellsten Weg herauszufinden, ob eine langsame Website ein Hosting- oder ein Code-Problem hat, bevor sich jemand auf einen Neubau festlegt.

Wenn du das als einmalige Leistung willst statt als laufende Zusammenarbeit, ist es die erste Hälfte unserer Technischen Analyse. Und wenn dich doch die Seitenebene ausbremst, deckt Wie du 100 Punkte bei PageSpeed erreichst die andere Seite der Linie ab.

Quellen

Die Schwellenwerte und Definitionen unten stammen von Google und der IETF. Die Messungen in diesem Artikel sind unsere eigenen, erhoben auf unseren drei Produktionsdomains im August und September 2026.

• web.dev — Time to First Byte (TTFB) ↗

  Definiert die Metrik und ihre Schwellenwerte — 0,8 s oder weniger ist gut, über 1,8 s ist schlecht — und listet auf, was das Fenster umfasst: Weiterleitungen, Start des Service Workers, DNS, Verbindung und TLS-Aushandlung sowie die Anfrage selbst.

• Chrome for Developers — Reduce initial server response time ↗

  Das Lighthouse-Audit, das Serverlatenz sichtbar macht, samt der Schwelle, ab der es sie meldet.

• Chrome for Developers — Lighthouse performance scoring ↗

  Die Gewichtung der Metriken hinter der einen Zahl — der Grund, warum der Zeitpunkt der Darstellung mehr zählt als die lange Audit-Liste, die PageSpeed darunter ausgibt.

• RFC 9111 — HTTP Caching ↗

  Was die Cache-Direktiven bedeuten. Die Norm definiert die Semantik, nicht welche Schicht deines Stapels sie zuletzt setzt.

• RFC 7932 — Brotli Compressed Data Format ↗

  Die Formatspezifikation, einschließlich des Schiebefensters, dessen Größe bestimmt, wie viel Wiederholung der Kompressor finden kann — der Parameter hinter den Messungen in der Tabelle oben.