Ein Entwickler migriert einen PrestaShop-Shop auf ein „schnelleres“ VPS. Die Seiten bleiben weich. Die Profilerstellung zeigt 40 % der CPU-Zeit bei der PHP-Kompilierung. OPcache wurde in einer „php.ini“, die von einer alten freigegebenen Site kopiert wurde, deaktiviert. Zwei Zeilen korrigiert, TTFB halbiert – ohne den Prozessor zu berühren.
OPcache speichert den kompilierten Bytecode von PHP-Dateien im gemeinsam genutzten Speicher. Ohne sie liest und kompiliert jede Abfrage die Quellen erneut. Auf WordPress – darunter Hunderte von Dateien – sind die Auswirkungen enorm. Dies ist oft der erste Hebel, der überprüft werden muss, vor PHP-FPM, vor HTTP/3, vor dem Hostwechsel.
Überprüfen Sie den tatsächlichen Status – gehen Sie nicht davon aus
„Bash php -i | grep -E 'opcache.enable|opcache.memory'
Oder eine temporäre „phpinfo()“-Seite in der Vorproduktion. Kernpunkte:
| Richtlinie | Rolle | Warnsignal |
| --- | --- | --- |
| `opcache.enable=1` | Cache aktivieren | `0` in Produktion |
| `opcache.memory_consumption` | Dedizierter Speicher (MB) | Zu niedrig → häufige Räumungen |
| `opcache.max_accelerated_files` | Maximale Anzahl Dateien | WordPress + Composer > 10.000 → erhöhen |
| `opcache.validate_timestamps` | Neu kompilieren, wenn die Datei geändert wurde | Ohne Bereitstellungsprozedur deaktiviert = Ghost Bugs |
| `opcache.revalidate_freq` | Verifizierungsfrist | Zu hoch in Dev, akzeptabel in Stable Prod |
Auf PHP 8 und höher kann **JIT** bei intensiven Berechnungen helfen; geringfügiger Gewinn gegenüber klassischem CMS – priorisieren Sie es nicht vor einem gesunden OPcache.
:::Hinweis
**Beachten Sie:** OPcache ist leistungsfrei, solange es aktiviert und dimensioniert ist. Die Kosten fallen an, wenn „validate_timestamps“ deaktiviert ist und niemand den Cache bei der Bereitstellung löscht.
:::
## Pragmatische Einstellungen nach Kontext
**WordPress / Shared CMS** – bestätigen Sie „enable=1“ und „max_accelerated_files“ ≥ 10000; Behalten Sie häufig die Standardeinstellungen des Hosts bei. **VPS mit Git-Bereitstellungen** – „validate_timestamps=0“ in der Produktion, wenn Ihre Pipeline PHP-FPM neu lädt oder „opcache_reset()“ in der CLI nach der Bereitstellung aufruft. **Ephemere Container** – OPcache beginnt bei jedem Neustart von vorne; Ein Aufwärmskript kann hilfreich sein. **Multisite oder großes Monorepo** – „opcache_get_status()“ überwachen: Erfolgsquote < 95 % → unzureichender Speicher oder max_files.
## Links zu FPM und TTFB
Jeder PHP-FPM-Worker profitiert vom **gemeinsamen** OPcache-Speicher. Ein zu kleiner OPcache erzwingt Neukompilierungen und **bläht indirekt den Arbeitsspeicher pro Worker auf**. Logische Reihenfolge: OPcache korrigieren, dann Redis-Objektcache oder Seitencache, dann [PHP-FPM-Anpassung](/de/blog/php-fpm-reglage/), dann [TTFB-Diagnose](/de/blog/ttfb-diagnostic/). Das Ignorieren von OPcache und das anschließende Verdoppeln der Worker bedeutet, dass für denselben Fehler doppelt bezahlt wird.
## Oben: Der Bytecode-Cache erscheint nicht in PageSpeed
:::Höhepunkt
**PageSpeed wird Ihnen niemals „OPcache deaktiviert“ sagen.** Es wird ein hoher TTFB angezeigt und ein schnellerer Host vorgeschlagen. Dennoch hätte die Hälfte der „No-Win“-Migrationen, die wir auf PHP sehen, durch fünf Minuten phpinfo() in der Produktion vermieden werden können.
:::
Marketing verkauft Prozessorkerne; OPcache ist auf dem Verkaufsblatt unsichtbar – aber entscheidend für die Rechnung und die tatsächliche Latenz. Vergleichen Sie Hosts über das [Verzeichnis](/de/verzeichnis/) nur **nach** Überprüfung.
## Entscheide dich und gehe ohne blinden Fleck voran
Bestätigen Sie in der Produktion, dass opcache.enable aktiv ist, und notieren Sie die Cache-Trefferquote, bevor Sie weitere Optimierungen vornehmen. Passen Sie „memory_consumption“ und „max_accelerated_files“ entsprechend der tatsächlichen Größe des Projekts an – WordPress mit vielen Plugins überschreitet schnell zehntausend Dateien. Dokumentieren Sie den Dump-Vorgang während der Bereitstellung: Neuladen von PHP-FPM oder Zurücksetzen der CLI, niemals öffentlicher Endpunkt. TTFB vorher und nachher messen; erst dann FPM optimieren oder Host wechseln.
## Häufig gestellte Fragen
### Ist OPcache standardmäßig aktiviert?
Auf PHP 7 und höher in der Produktion oft ja – aber nicht immer auf alten Shared- oder Minimal-Container-Images. Überprüfen Sie dies mit phpinfo() oder `php -i | grep opcache`.
### „validate_timestamps“ in der Produktion aktiviert oder deaktiviert?
Deaktiviert und erneut bereitstellen, wodurch der OPcache geleert wird = maximale Leistung. Aktiviert und häufige Bereitstellungen = einfacher, ohne zu vergessen, den Cache zu leeren. Wählen Sie entsprechend Ihrer Pipeline, nicht nach einer allgemeingültigen Regel.
### Ersetzt OPcache Redis oder einen Seitencache?
Nein. OPcache speichert kompilierten PHP-Bytecode zwischen. Redis verbirgt Anwendungsdaten; Ein Seitencache vermeidet die Ausführung von PHP. Die drei ergänzen sich.
### Wie lösche ich den OPcache nach einer Bereitstellung?
Laden Sie PHP-FPM neu, rufen Sie „opcache_reset()“ in einer dedizierten Befehlszeile auf oder integrieren Sie das Zurücksetzen in das Bereitstellungstool – niemals, indem Sie reset() öffentlich im Web verfügbar machen.
---
Vor dem Kauf eines schnelleren Servers eine Frage: *Ist OPcache aktiviert und wie hoch ist seine Erfolgsquote?* Wenn Sie es sich noch nie angesehen haben, haben Sie PHP noch nicht optimiert.