Mit PHP 8.5 ist im November 2025 eine Version erschienen, die für Shop-Betreiber vor allem eine Konsequenz hat: Der Bytecode-Cache OPcache ist jetzt fest in die PHP-Binärdatei eingebaut und immer geladen (PHP-Projekt). Damit verschiebt sich die eigentliche Arbeit von der Frage, ob Sie OPcache nutzen, hin zu der Frage, wie Sie ihn und den JIT-Compiler auf die Lastprofile Ihres Online-Shops abstimmen. Dieser Leitfaden zeigt, welche OPcache-Stellschrauben in der Praxis Antwortzeit sparen, wann JIT-Tracing bei rechenintensiven Routen hilft und bei datenbanklastigen eher nichts bringt - und wie sich das Ganze im professionellen Hosting eines Shopware-Shops sauber verankern lässt.
Was sich mit PHP 8.5 für Shop-Server ändert
PHP ist nach wie vor das Fundament des Web-Handels: Rund 69,9 Prozent aller Websites mit bekannter serverseitiger Sprache laufen auf PHP (W3Techs), und 63,9 Prozent der PHP-Installationen laufen inzwischen auf Version 8 (W3Techs). Für Shop-Systeme wie Shopware, die auf dem Symfony-Framework aufsetzen, ist ein aktueller PHP-Zweig deshalb keine Kür, sondern Betriebsgrundlage. PHP 8.5 wurde am 20. November 2025 veröffentlicht (PHP.net) und führt die Linie der letzten Versionen fort: mehr Tempo aus dem Kern heraus, ohne dass Sie Ihren Anwendungscode umschreiben müssen.
Die wichtigste Änderung für den Betrieb betrifft OPcache. Bislang war der Bytecode-Cache eine optionale Erweiterung, die über zend_extension=opcache geladen wurde. In PHP 8.5 ist OPcache fest in die Binärdatei eingebaut und dauerhaft vorhanden - die separate Ladezeile entfällt und sollte aus alten Konfigurationen entfernt werden (PHP-Projekt). Praktisch heißt das: Der Cache ist da, doch seine Standardwerte sind konservativ. Genau hier liegt der Hebel, denn die Voreinstellungen sind für kleine Skripte gedacht, nicht für einen ausgewachsenen Shop mit zehntausenden Klassendateien.
In PHP 8.5 ist der OPcache-Bytecode-Cache nicht mehr optional, sondern Teil des Kerns (PHP-Projekt). Wer von PHP 8.4 migriert, sollte die Zeile zend_extension=opcache aus der Konfiguration nehmen, weil die Erweiterung ohnehin geladen ist. Das reine Vorhandensein von OPcache bedeutet aber noch keine optimale Konfiguration - die eigentliche Beschleunigung entsteht erst durch passend gesetzte Speicher- und Validierungswerte.
OPcache verstehen: Warum der Bytecode-Cache Ihren Shop trägt
OPcache setzt an einer strukturellen Eigenheit von PHP an. Ohne Cache liest der Interpreter bei jedem einzelnen Aufruf jede benötigte PHP-Datei neu von der Festplatte, zerlegt sie in Tokens und übersetzt sie in Opcodes - jene Zwischensprache, die die PHP-Engine tatsächlich ausführt. Bei einem Shopware-Shop mit vielen tausend Klassendateien fällt dieser Schritt bei jedem Seitenaufruf erneut an. OPcache speichert die fertig kompilierten Opcodes im gemeinsam genutzten Arbeitsspeicher. Ab dem zweiten Aufruf entfällt das teure Parsen und Kompilieren komplett, und die Engine springt direkt in die Ausführung.
Der Effekt ist gerade bei framework-lastigen Shops erheblich, weil dort pro Request sehr viele Dateien eingebunden werden. Wird der kompilierte Bytecode dauerhaft im Speicher gehalten, sinken die Antwortzeiten deutlich. Für einen Online-Shop ist das doppelt wertvoll: Schnellere Antwortzeiten verbessern nicht nur die Nutzererfahrung im Checkout, sondern zahlen auch auf die Core Web Vitals und damit auf die Sichtbarkeit in der Suche ein. Ein gut konfigurierter OPcache ist damit eine der günstigsten Performance-Maßnahmen überhaupt - sie kostet im Wesentlichen Arbeitsspeicher und ein paar Konfigurationszeilen.
OPcache richtig konfigurieren: die entscheidenden Stellschrauben
Der wichtigste Wert ist opcache.memory_consumption. Er legt fest, wie viel gemeinsamer Speicher für den Bytecode zur Verfügung steht. Der Standardwert liegt bei 128 MB (PHP.net) - für einen kleinen Blog ausreichend, für einen Shop mit umfangreichem Framework-Code oft zu knapp. Läuft der Cache voll, beginnt OPcache Einträge zu verdrängen, die Trefferquote sinkt und der Vorteil schrumpft. Für Shop-Server hat sich in der Praxis ein Bereich von 256 bis 512 MB bewährt (Projekterfahrung). Ein zu großzügiger Wert schadet nicht unmittelbar, er belegt lediglich Arbeitsspeicher, der an anderer Stelle fehlen könnte.
; Empfohlene Basis für einen Shop-Server
opcache.enable=1
opcache.memory_consumption=512
opcache.interned_strings_buffer=64
opcache.max_accelerated_files=1000000
opcache.validate_timestamps=0
opcache.save_comments=1Die zweite große Stellschraube ist opcache.validate_timestamps. Ist sie aktiv, prüft PHP bei jedem Request für jede Datei über einen Dateisystem-Aufruf, ob sich die Quelle geändert hat. In der Entwicklung ist das praktisch, in der Produktion ist es unnötiger Aufwand. Setzt man den Wert auf 0, entfällt dieser stat-Aufruf pro Datei und Request vollständig - dafür muss der Cache nach jedem Deployment von Hand zurückgesetzt werden (PHP.net). Wie viel Zeit das spart, hängt davon ab, wie viele Dateien ein Request einbindet, und gehört am eigenen Shop gemessen.
Wenn OPcache die Zeitstempel nicht mehr prüft, bemerkt PHP Codeänderungen nicht von selbst. Nach jedem Deployment muss der Cache deshalb aktiv geleert werden - über einen Neustart von PHP-FPM oder einen Aufruf von opcache_reset() (PHP.net). Wer diesen Schritt vergisst, wundert sich, warum neue Änderungen nicht greifen. In einer sauberen Deployment-Pipeline ist das Zurücksetzen des Caches ein fester, automatisierter Bestandteil.
| Einstellung | Standard | Shop-Produktion | Wirkung |
|---|---|---|---|
| opcache.memory_consumption | 128 MB | 256-512 MB | Mehr Klassen im Cache |
| opcache.max_accelerated_files | 10.000 | bis 1.000.000 | Alle Dateien werden gecacht |
| opcache.interned_strings_buffer | 8 MB | 32-64 MB | Weniger doppelte Zeichenketten |
| opcache.validate_timestamps | 1 (an) | 0 (aus) | Kein stat-Aufruf je Request |
Zwei weitere Werte runden die Konfiguration ab. opcache.max_accelerated_files begrenzt, wie viele Dateien im Cache liegen dürfen; der Standard liegt bei 10.000, das Maximum bei 1.000.000 (PHP.net) - für große Shops ist ein hoher Wert nötig, damit wirklich jede Klasse zwischengespeichert wird. opcache.interned_strings_buffer bestimmt, wie viel Speicher für intern zusammengefasste Zeichenketten reserviert ist; der Standard liegt bei 8 MB (PHP.net), bei framework-lastigen Anwendungen sind 32 bis 64 MB üblich, weil identische Strings nur einmal gehalten werden. Wichtig ist, die tatsächliche Trefferquote nach der Umstellung zu beobachten: Sie sollte stabil hoch bleiben, sonst ist der Speicher zu knapp bemessen.
JIT: Wann Tracing hilft und wann es bremst
Der JIT-Compiler (Just-in-Time) geht einen Schritt weiter als OPcache. Während OPcache kompilierte Opcodes zwischenspeichert, übersetzt JIT häufig durchlaufene Codepfade zur Laufzeit direkt in nativen Maschinencode, den die CPU ohne den Umweg über die PHP-Engine ausführt. Aktiviert wird der empfohlene Tracing-Modus über opcache.jit=tracing, was intern dem numerischen Wert 1254 entspricht (PHP.net). Das klingt nach reinem Gewinn - ist es aber nur für bestimmte Lastprofile.
Der Nutzen von JIT hängt entscheidend davon ab, womit Ihr Shop seine Zeit verbringt. Bei CPU-lastigem Code - etwa Bildverarbeitung, PDF-Erzeugung, aufwändige Preis- oder Rabattberechnungen oder große Datenimporte - kann JIT spürbar beschleunigen. Bei typischen Web-Anwendungen, die den Großteil ihrer Zeit mit Datenbankabfragen, Netzwerkzugriffen und dem Warten auf externe Dienste verbringen, fällt der Gewinn dagegen gering aus. Das ist keine Schwäche von JIT, sondern schlichte Mathematik: Wenn eine Route zu 60 Prozent auf Ein- und Ausgabe wartet, bringt selbst eine Verdopplung der übrigen 40 Prozent CPU-Anteil am Ende nur rund 20 Prozent.
; JIT nur, wenn Routen wirklich CPU-lastig sind
opcache.jit=tracing
opcache.jit_buffer_size=128MJIT ist kein Schalter, den man blind umlegt. Der Gewinn hängt so stark vom konkreten Lastprofil ab, dass nur eine Vorher-Nachher-Messung der echten Antwortzeiten Klarheit schafft - synthetische Benchmarks täuschen hier leicht. Erfahrungsgemäß lohnt sich JIT im klassischen Shop-Checkout selten, während rechenintensive Hintergrundprozesse wie Import, Bildskalierung oder Report-Erzeugung deutlich profitieren können. Wer beides trennt, holt das Maximum heraus, ohne die Latenz der Kundenrouten zu riskieren.
JIT tracing hilft
Rechenintensive Aufgaben ohne Wartezeiten: Preis- und Importlogik, Bildverarbeitung sowie PDF- und Report-Erzeugung. Hier sind spürbare Sprünge realistisch.
JIT bringt wenig
Datenbank- und I/O-lastige Routen wie Produktlisten oder der Checkout im B2B-Shop: Der Engpass ist die Wartezeit, nicht die CPU - der Zuwachs bleibt meist gering.
Preloading und weitere Hebel jenseits von OPcache
Über OPcache und JIT hinaus gibt es weitere Stellschrauben. Preloading lädt ausgewählte Klassen bereits beim Start des PHP-Prozesses in den Speicher, sodass sie über alle Requests hinweg sofort verfügbar sind. Das Symfony-Projekt nennt für reale Anwendungen eine Verbesserung von 30 bis 50 Prozent (Symfony). Entscheidend ist der Ausgangspunkt: Bei ohnehin schnellen Anwendungen fällt Preloading stark ins Gewicht, bei trägen Seiten geht der Gewinn dagegen im Rauschen unter. Wie viel es im eigenen Shop bringt, zeigt nur eine Vorher-Nachher-Messung.
Zwei weitere Punkte lohnen einen Blick. Der realpath_cache speichert aufgelöste Dateipfade und entlastet bei vielen Includes das Dateisystem - für große Shops sind höhere Werte sinnvoll. Und die Prozessverwaltung PHP-FPM entscheidet mit, wie viele parallele Anfragen ein Server verträgt: Zu wenige Worker bremsen unter Last, zu viele erschöpfen den Arbeitsspeicher. Diese Größen gehören zum Lastprofil des Shops passend dimensioniert, idealerweise auf Basis realer Messwerte statt pauschaler Faustregeln. Wer seine Infrastruktur ohnehin neu ausrichtet, sollte dabei auch die Frage der Datenhoheit und des Server-Standorts mitdenken.
Von PHP 8.4 auf 8.5 migrieren: der sichere Weg
Der Sprung von PHP 8.4 auf 8.5 ist für die meisten Shops unkritisch, will aber vorbereitet sein. Den vollständigen Ablauf für Shopware haben wir in einem eigenen Leitfaden zur PHP-8.5-Migration aus Agentursicht beschrieben; hier geht es um die tuning-relevanten Schritte. Wichtig ist, die genutzte Shop-Version auf ihre PHP-Kompatibilität zu prüfen: Shopware etwa hat die offizielle Unterstützung für PHP 8.5 mit einer Version aus dem Februar 2026 eingeführt (Shopware). Wer auf einem älteren Stand liegt, aktualisiert sinnvollerweise erst den Shop und dann PHP.
- Kompatibilität prüfen: Shop-Version, Plugins und eigene Erweiterungen auf PHP-8.5-Freigabe kontrollieren, bevor irgendetwas produktiv umgestellt wird.
- In der Staging-Umgebung testen: Eine exakte Kopie des Shops auf PHP 8.5 heben und alle kritischen Abläufe - Checkout, Zahlung, Import - vollständig durchspielen.
- Deprecations abarbeiten: Die im Log gemeldeten Hinweise beheben, damit sie nicht in einer späteren Version zu echten Fehlern werden.
- OPcache und JIT konfigurieren: Die oben beschriebenen Werte setzen und - wichtig - den Cache-Reset in die Deployment-Routine aufnehmen.
- Messen und live gehen: Antwortzeiten vor und nach der Umstellung vergleichen, dann kontrolliert produktiv schalten und die Trefferquote im Blick behalten.
Eine PHP-Migration berührt ohnehin die gesamte Laufzeitumgebung. Das ist der ideale Moment, um OPcache- und JIT-Werte, PHP-FPM-Dimensionierung und Deployment-Ablauf gemeinsam zu überprüfen. In der Beratung legen wir dafür je Shop ein realistisches Ziel fest, statt Standardwerte ungeprüft zu übernehmen - denn die passende Konfiguration ist erfahrungsgemäß jene, die zum tatsächlichen Lastprofil passt.
PHP-Performance dauerhaft im Hosting verankern
Tempo ist im E-Commerce kein einmaliges Projekt, sondern ein Betriebsmerkmal. OPcache und JIT entfalten ihren Wert erst, wenn sie zum Lastprofil passen, nach jedem Deploy sauber zurückgesetzt werden und ihre Trefferquote überwacht wird. Im Managed Hosting von XICTRON richten wir PHP 8.5 so ein, dass diese Punkte nicht dem Zufall überlassen bleiben, sondern fester Teil des Betriebs sind.
OPcache passend dimensioniert
Speicher, Dateilimit und Validierung auf Ihren Shop abgestimmt - mit überwachter Trefferquote statt konservativer Standardwerte.
JIT nach Lastprofil
Tracing dort, wo rechenintensive Prozesse laufen, und bewusst aus, wo I/O den Takt vorgibt.
Sicherer Deploy mit Cache-Reset
validate_timestamps=0 nur mit automatisiertem OPcache-Reset in der Deployment-Pipeline.
Messbar statt geraten
Antwortzeiten vor und nach jeder Änderung - auch für datenintensive ERP-Preislisten im B2B-Shop.
Ob frische Installation oder Migration von PHP 8.4: Entscheidend ist, dass OPcache und JIT nicht nach Faustregel, sondern nach den realen Lastprofilen Ihres Shops konfiguriert sind. Wir prüfen den aktuellen Stand Ihrer PHP-Konfiguration, migrieren kontrolliert auf PHP 8.5 und belegen jede Änderung mit einem Vorher-Nachher-Vergleich. Sprechen Sie unser Team an, um das Tempo Ihres Shops auf ein solides, messbares Fundament zu stellen.
Dieser Artikel stützt sich auf die offizielle PHP.net-Dokumentation zu OPcache und JIT, die Release-Angaben zu PHP 8.5, die UPGRADING-Hinweise des PHP-Projekts zur fest eingebauten OPcache-Erweiterung, die Preloading-Angaben von Symfony sowie die Nutzungsdaten von W3Techs und die Versionshinweise von Shopware. Genannte Zahlen sind Orientierungswerte und können je nach Anwendung, Hardware und Zeitpunkt abweichen; dieser Beitrag ersetzt keine individuelle Performance- oder Sicherheitsberatung. Stand: September 2026.
OPcache ist in PHP 8.5 fest in die Binärdatei eingebaut und dauerhaft verfügbar (PHP-Projekt). Die alte Zeile zend_extension=opcache ist damit überflüssig und sollte aus der Konfiguration entfernt werden. Aktiv ist der Cache dann zwar, aber mit konservativen Standardwerten - die eigentliche Beschleunigung entsteht erst durch angepasste Speicher- und Validierungseinstellungen.
Mit opcache.validate_timestamps=0 entfällt pro Datei und Request ein Dateisystem-Aufruf zur Änderungsprüfung. Wie viel Zeit das spart, hängt davon ab, wie viele Dateien ein Request einbindet, und lässt sich nur am eigenen Shop messen. Der Preis dafür: Nach jedem Deployment muss der Cache aktiv geleert werden (PHP.net), sonst greifen Codeänderungen nicht.
Das hängt vom Lastprofil ab. Bei rechenintensiven Aufgaben wie Bildverarbeitung oder Importlogik kann JIT im Tracing-Modus spürbar beschleunigen. Bei datenbank- und I/O-lastigen Web-Routen bleibt der Gewinn dagegen meist gering. Deshalb gilt: erst die echten Antwortzeiten messen, dann gezielt entscheiden statt pauschal aktivieren.
Der Standard von 128 MB (PHP.net) ist für größere Shops meist zu knapp. Bewährt hat sich ein Bereich von 256 bis 512 MB (Projekterfahrung), kombiniert mit einem hohen Wert für max_accelerated_files bis 1.000.000 (PHP.net), damit wirklich jede Klassendatei zwischengespeichert wird. Die Trefferquote sollte nach der Umstellung stabil hoch bleiben; fällt sie ab, ist der Speicher zu knapp bemessen.
OPcache speichert kompilierten Bytecode im Arbeitsspeicher, sodass Dateien nicht bei jedem Request neu geparst werden. JIT geht weiter und übersetzt häufige Codepfade zur Laufzeit in nativen Maschinencode. OPcache hilft praktisch jedem Shop, JIT vor allem CPU-lastigen Aufgaben. Für die meisten Web-Anwendungen ist ein gut konfigurierter OPcache der größere Hebel.
Wir prüfen Shop-Version, Plugins und Erweiterungen auf PHP-8.5-Freigabe, migrieren zunächst in einer Staging-Umgebung und arbeiten gemeldete Deprecations ab. Anschließend konfigurieren wir OPcache und JIT passend zum Lastprofil, verankern den OPcache-Reset in der Deployment-Pipeline und belegen jede Änderung mit einem Vorher-Nachher-Vergleich der Antwortzeiten. So wird PHP-Performance typischerweise zu einem festen, messbaren Bestandteil des Hostings (Projekterfahrung).