HTTP/3, Brotli und OPcache: Moderne Server-Technik erklärt

HTTP/3, Brotli und OPcache sind drei Techniken, die an unterschiedlichen Stellen ansetzen: HTTP/3 verbessert den Transport zwischen Server und Browser, Brotli macht die übertragenen Daten kleiner, und OPcache beschleunigt die Ausführung von PHP auf dem Server. Keine davon ist ein Allheilmittel, zusammen bilden sie aber eine solide technische Grundlage für schnelle Seiten. Wo Sie solche Einstellungen selbst verantworten und wo der Hoster, erklärt der Ratgeber Server-Hosting.

Die drei Ebenen im Überblick

Technik	Ebene	Was sie verbessert	Wer sie meist konfiguriert
HTTP/3	Übertragungsprotokoll	Verbindungsaufbau, Verhalten bei Paketverlust, Mobilfunk	Webserver, CDN oder Load Balancer
Brotli	Kompression	Größe von HTML, CSS, JavaScript, SVG und JSON	Webserver, CDN, Build-Prozess
OPcache	PHP-Ausführung	Rechenzeit pro Anfrage bei PHP-Anwendungen	PHP-Konfiguration auf dem Server

HTTP/3: Schnellerer Transport mit QUIC

Was HTTP/3 anders macht

HTTP/1.1 und HTTP/2 laufen über TCP. HTTP/3 nutzt stattdessen QUIC, ein Protokoll auf Basis von UDP, das Verschlüsselung mit TLS 1.3 fest integriert. Daraus ergeben sich mehrere Vorteile:

• Schnellerer Verbindungsaufbau: Verbindungs- und Verschlüsselungsaushandlung werden zusammengefasst. Bei wiederholten Besuchen ist mit 0-RTT sogar ein Start ohne zusätzliche Wartezeit möglich.
• Kein Blockieren durch verlorene Pakete: Bei HTTP/2 über TCP hält ein verlorenes Paket alle parallelen Übertragungen der Verbindung auf. QUIC behandelt die einzelnen Datenströme unabhängig.
• Verbindungswechsel: Wechselt ein Smartphone vom WLAN ins Mobilfunknetz, kann die Verbindung bestehen bleiben, statt neu aufgebaut zu werden.

Den größten Nutzen haben Besucher mit instabilen oder langsamen Verbindungen. In einem stabilen Büronetz fällt der Unterschied zu HTTP/2 meist gering aus.

Wie Browser HTTP/3 finden

Browser beginnen oft mit HTTP/2. Der Server teilt im Header Alt-Svc mit, dass HTTP/3 verfügbar ist, und der Browser nutzt es für folgende Anfragen. Alternativ kann ein DNS-Eintrag vom Typ HTTPS das Protokoll vorab ankündigen. Ist HTTP/3 nicht erreichbar, etwa weil eine Firewall UDP blockiert, fällt der Browser automatisch auf HTTP/2 zurück.

Was der Server braucht

• einen Webserver oder Proxy mit HTTP/3-Unterstützung, zum Beispiel aktuelle Versionen von Nginx, LiteSpeed oder Caddy, oder ein vorgeschaltetes CDN,
• geöffneten UDP-Port 443 in Firewall und Netzwerk,
• ein gültiges TLS-Zertifikat, das ohnehin Pflicht ist.

Bei 0-RTT ist Vorsicht angebracht: Daten, die in dieser frühen Phase gesendet werden, lassen sich unter Umständen wiederholt einspielen. Webserver erlauben 0-RTT deshalb meist nur für Anfragen ohne Nebenwirkungen oder lassen es standardmäßig aus.

Brotli: Kleinere Dateien, schnellere Übertragung

So funktioniert die Kompression

Bevor der Server eine Textdatei ausliefert, kann er sie komprimieren. Der Browser gibt im Header Accept-Encoding an, welche Verfahren er versteht, der Server antwortet mit Content-Encoding. Brotli wurde von Google entwickelt und ist als offenes Verfahren standardisiert. Für typische Webinhalte erreicht es meist kleinere Dateien als gzip. Browser bieten Brotli in der Regel nur über HTTPS an.

Statisch und dynamisch komprimieren

Brotli kennt Qualitätsstufen von 0 bis 11. Hohe Stufen komprimieren stärker, brauchen aber deutlich mehr Rechenzeit. Daraus ergibt sich eine einfache Faustregel:

Inhalt	Empfehlung
Statische Dateien (CSS, JavaScript, SVG, Schriften im Textformat)	einmal beim Build oder Deployment mit hoher Stufe vorkomprimieren und fertig ausliefern
Dynamische Seiten (HTML aus PHP, JSON aus APIs)	bei jeder Anfrage mit mittlerer Stufe komprimieren, damit die Antwortzeit nicht leidet
Bilder, Videos, ZIP-Archive	nicht zusätzlich komprimieren, sie sind bereits komprimiert

Neben Brotli gewinnt Zstandard als weiteres Verfahren an Bedeutung, das von aktuellen Browsern zunehmend unterstützt wird. Gzip bleibt als Rückfallebene aktiv.

Brotli prüfen

Öffnen Sie im Browser den Netzwerk-Tab der Entwicklerwerkzeuge, wählen Sie eine HTML- oder CSS-Datei und sehen Sie in den Antwort-Headern nach. Steht bei Content-Encoding der Wert br, ist Brotli aktiv.

OPcache: PHP ohne ständiges Neuübersetzen

Was ohne OPcache passiert

PHP ist eine Skriptsprache. Ohne Zwischenspeicher liest der Server bei jeder Anfrage die PHP-Dateien, übersetzt sie in einen internen Bytecode und führt diesen aus. Bei einem CMS mit Hunderten Dateien kostet das spürbar Zeit. OPcache speichert den übersetzten Bytecode im gemeinsamen Arbeitsspeicher, sodass folgende Anfragen ihn direkt nutzen. OPcache ist seit Langem Bestandteil von PHP und auf den meisten Hosting-Angeboten aktiv.

Wichtige Einstellungen

Einstellung	Bedeutung	Hinweis
opcache.enable	schaltet OPcache für Webanfragen ein	sollte im Produktivbetrieb aktiv sein
opcache.memory_consumption	Größe des Zwischenspeichers	bei großen Anwendungen wie Shops eher großzügig wählen
opcache.max_accelerated_files	maximale Zahl gespeicherter Dateien	muss zur Dateianzahl von CMS, Plugins und Bibliotheken passen
opcache.validate_timestamps	prüft, ob Dateien geändert wurden	ausgeschaltet am schnellsten, dann aber nach jedem Deployment Cache leeren
opcache.revalidate_freq	Abstand der Änderungsprüfung in Sekunden	nur relevant, wenn Zeitstempel geprüft werden

Ist der Speicher zu klein, verdrängt OPcache ständig Einträge, und der Vorteil schrumpft. Viele Control Panels und Statusseiten zeigen Füllstand und Trefferquote an. Eine Trefferquote nahe 100 Prozent ist das Ziel.

OPcache ist kein Seitencache

OPcache beschleunigt nur die Ausführung des Codes. Datenbankabfragen und das Zusammenbauen der Seite finden trotzdem statt. Für spürbar kürzere Antwortzeiten braucht es zusätzlich einen Seitencache für Besucher ohne Anmeldung und einen Objektcache wie Redis für wiederkehrende Datenbankabfragen. Gerade bei WordPress greifen diese Ebenen ineinander, mehr dazu im Ratgeber WordPress-Hosting.

Der JIT-Compiler, den PHP seit Version 8 mitbringt, ist eine Erweiterung von OPcache. Für typische Webanwendungen, die vor allem auf Datenbank und Dateisystem warten, bringt er wenig. Er ist eher bei rechenintensiven Aufgaben interessant.

In welcher Reihenfolge optimieren?

Nicht jede Technik bringt auf jeder Website gleich viel. Eine sinnvolle Reihenfolge für PHP-Websites:

1. OPcache prüfen: Er ist fast immer verfügbar, kostet nichts und wirkt bei jeder dynamischen Anfrage. Ist er aus oder zu klein, ist das der schnellste Gewinn.
2. Seitencache und Objektcache einrichten: Sie verkürzen die Antwortzeit des Servers meist stärker als jede Protokolländerung.
3. Kompression aktivieren: Brotli für Text, mit gzip als Rückfallebene. Das verkleinert vor allem große JavaScript- und CSS-Dateien.
4. HTTP/2 und HTTP/3 einschalten: Am meisten profitieren Besucher mit mobilen oder instabilen Verbindungen.
5. Messen statt vermuten: Vergleichen Sie Antwortzeit des Servers, übertragene Datenmenge und Ladezeit vor und nach jeder Änderung. Ändern Sie dabei möglichst nur eine Sache auf einmal.

Auf Shared Hosting sind die ersten und letzten Punkte oft schon vom Hoster erledigt. Fragen Sie im Zweifel nach, welche Protokolle und Kompressionsverfahren aktiv sind und ob Sie OPcache-Werte selbst anpassen dürfen.

Was davon bei Node.js und Python gilt

HTTP/3 und Brotli betreffen jede Website, unabhängig von der Programmiersprache, und werden im vorgeschalteten Webserver oder CDN eingerichtet. OPcache ist dagegen eine reine PHP-Funktion. Node.js- und Python-Anwendungen bleiben als dauerhafter Prozess ohnehin im Speicher. Was diese Anwendungen sonst vom Hosting brauchen, steht im Artikel Node.js- und Python-Hosting.

Checkliste

• HTTP/2 aktiv, HTTP/3 aktiv oder über ein CDN verfügbar
• UDP-Port 443 bei eigenem Server freigegeben
• Brotli für Textinhalte aktiv, gzip als Rückfallebene
• Statische Dateien vorkomprimiert, keine Doppelkompression von Bildern
• OPcache aktiv, Speicher und Dateianzahl passend zur Anwendung
• Cache-Leerung von OPcache im Deployment-Ablauf vorgesehen
• Seitencache und Objektcache ergänzend eingerichtet
• Ergebnis im Browser geprüft: Protokoll h3, Content-Encoding br