Was ist OPcache? PHP Cache für schnellere Websites erklärt

Was ist OPcache und wofür braucht PHP ihn?

OPcache ist der eingebaute Bytecode Cache von PHP. Er legt kompilierte Skripte im gemeinsamen Arbeitsspeicher ab. Dadurch muss PHP dieselben Dateien nicht bei jeder Anfrage neu lesen, analysieren und kompilieren. Daher spart der Server Rechenzeit, die CPU Last sinkt und dynamische Seiten antworten meist schneller.

In diesem Leitfaden erklären wir zunächst, was OPcache ist. Danach gehen wir die wichtigsten php.ini Einstellungen, die Prüfschritte und das Zurücksetzen nach einem Deployment durch. Wir stützen uns dabei auf die offizielle PHP Dokumentation. Unser Team macht digitales Marketing und Webentwicklung, wir sind kein Hostinganbieter.

Wir schreiben für zwei Gruppen. Erstens sprechen wir Besitzer an: Die erste Gruppe besitzt eine Website oder einen Onlineshop und möchte mit dem Hoster auf Augenhöhe sprechen. Zweitens sprechen wir Administratoren an: Die zweite Gruppe verwaltet einen VPS oder ein cPanel Konto und sucht Befehle für jeden Schritt. Deshalb haben wir für beide Hinweise eingebaut.

Was ist OPcache im Ablauf einer PHP Anfrage genau?

Bevor PHP ein Skript ausführt, erledigt es mehrere Schritte. Es liest die Datei von der Platte, zerlegt sie in Tokens, prüft die Syntax und kompiliert sie zu Opcodes. Erst danach führt die Zend Engine diese Opcodes aus. OPcache speichert die erste Hälfte dieser Kette, also den Kompiliervorgang.

Bei aktivem OPcache kompiliert PHP die Datei bei der ersten Anfrage noch. Danach legt es das Ergebnis im gemeinsamen Speicher ab. Spätere Anfragen überspringen das Parsen und Kompilieren und nutzen direkt die gespeicherten Opcodes. Sie cachen also den kompilierten Code, nicht die Seitenausgabe.

Dieser Unterschied ist wichtig, denn er zeigt die Grenzen von OPcache. Ein Seitencache speichert fertiges HTML. OPcache dagegen lässt PHP jede dynamische Seite weiter neu aufbauen. Er senkt nur die Kosten für die Vorbereitung des Codes. Daher werden Ihre Datenbankabfragen und externen API Aufrufe durch OPcache allein nicht schneller.

• Übersprungen: Datei lesen, parsen und kompilieren.
• Nicht übersprungen: Code ausführen, Datenbankabfragen, Template Ausgabe.
• Gespeichert: kompilierte Opcodes im gemeinsamen Speicher.

Die technische Antwort auf die Frage, was ist OPcache, passt also in einen Satz: einmal kompilieren, das Ergebnis teilen. Alles andere ist Feinabstimmung der Größe und der Aktualisierung.

Ist OPcache auf Ihrem Server aktiv?

Die PHP Dokumentation nennt für opcache.enable den Standardwert 1, also aktiv. Allerdings kann Ihr Hoster die php.ini geändert haben. Außerdem heißt eine installierte Erweiterung nicht, dass sie auch läuft. Eine verlässliche Antwort liefert nur Ihre eigene Umgebung.

Sie haben drei Möglichkeiten. Erstens listen Sie auf der Kommandozeile die geladenen Module auf. Zweitens suchen Sie in der phpinfo Ausgabe nach dem Abschnitt Zend OPcache. Drittens rufen Sie opcache_get_status auf. Die Funktion liefert false, wenn OPcache aus ist, und sonst ein Statusarray.

php -m | grep -i opcache
php -i | grep -E "opcache.(enable|memory_consumption)"

Beachten Sie, dass diese Befehle die CLI Variante zeigen. Laut Dokumentation steht opcache.enable_cli standardmäßig auf 0. Deshalb muss die CLI Ausgabe nicht zu dem passen, was Ihre Website sieht. Für die Webseite brauchen Sie eine Seite, die über den Webserver läuft; das beschreiben wir weiter unten.

Wie verändert OPcache die Geschwindigkeit von WordPress oder WooCommerce?

WordPress lädt bei jeder Anfrage Kerndateien, ein Theme und Plugins. Das können Dutzende oder sogar Hunderte PHP Dateien sein. Deshalb hilft OPcache bei dateireichen Anwendungen wie WordPress besonders. Wie groß der Gewinn ausfällt, hängt von Plugins, Hardware und Traffic ab. Einen festen Prozentwert versprechen wir nicht.

Wer wissen will, was ist OPcache bei WordPress, sollte zwei Dinge wissen. Erstens liefert PHP ihn bereits mit. Zweitens ersetzt er kein Cache Plugin für Seiten. Ein Seitencache liefert fertiges HTML und überspringt PHP oft ganz. OPcache entlastet PHP, wenn es doch läuft. Beide Ebenen ergänzen sich also.

In Onlineshops ist der Unterschied deutlicher. Warenkorb, Kasse und Kundenkonto umgehen meist den Seitencache, daher läuft PHP jedes Mal. Auf diesen dynamischen Seiten leistet OPcache echte Arbeit. Den Zusammenhang zwischen Tempo und Umsatz erklärt unser Beitrag Ladezeit im Onlineshop und Umsatz.

Welche OPcache Einstellungen sind am wichtigsten?

OPcache bietet Dutzende Direktiven, aber fünf oder sechs decken die meisten Websites ab. Die Tabelle unten nennt die Standardwerte von der offiziellen OPcache Konfigurationsseite. Allerdings weist die Dokumentation darauf hin, dass sich manche Standardwerte zwischen Versionen ändern. Prüfen Sie die Seite daher für Ihre PHP Version.

Die meisten dieser Direktiven ändern Sie nur auf php.ini Ebene. Die Dokumentation führt memory_consumption, max_accelerated_files und enable_cli als INI_SYSTEM. Somit können Sie sie nicht per ini_set aus einem Skript ändern.

Wie wählen Sie opcache.memory_consumption richtig?

Diese Direktive legt fest, wie viel gemeinsamen Speicher OPcache nutzen darf, in Megabyte. Die Dokumentation nennt 128 MB als Standard und erzwingt mindestens 8 MB. Außerdem kommt der Puffer für interned Strings aus dieser Gesamtmenge. Die 8 MB für Zeichenketten sind also ein Teil der 128 MB.

Den richtigen Wert raten Sie nicht, Sie messen ihn. Lassen Sie die Website eine Weile mit normalem Traffic laufen. Lesen Sie dann used_memory, free_memory und wasted_memory in der Ausgabe von opcache_get_status. Bleibt der freie Speicher dauerhaft nahe null oder zeigt cache_full den Wert true, erhöhen Sie den Wert.

Andererseits verschwendet ein zu großer Wert Arbeitsspeicher. Auf einem kleinen VPS zählt jedes Megabyte auch für andere Dienste. Erhöhen Sie die Zahl daher in kleinen Schritten, und prüfen Sie nach jeder Änderung die Statusausgabe.

• Messen Sie zunächst die aktuelle Nutzung.
• Erhöhen Sie den Wert dann um einen vernünftigen Schritt.
• Starten Sie schließlich PHP neu und lesen Sie den Status erneut.

Warum ist opcache.max_accelerated_files wichtig und wie dimensionieren Sie es?

Diese Direktive begrenzt die Zahl der Skript Schlüssel in der Hash Tabelle des Caches. Der Standard ist 10000. Laut Dokumentation gilt als echter Wert die erste Primzahl aus der Menge 223, 463, 983, 1979, 3907, 7963, 16229, 32531, 65407, 130987, 262237, 524521 und 1048793, die größer oder gleich Ihrer Einstellung ist.

Beispielrechnung: Ihre Website hat etwa 12000 PHP Dateien, einschließlich Plugins und vendor Ordner. Nach der Primzahlliste der Dokumentation rundet der Standard 10000 auf 16229 auf, also passen 12000 Dateien hinein. Bei 20000 Dateien würde der Wert auf 32531 springen. Diese Zahlen sind nur Beispiele, daher zählen Sie Ihre eigenen Dateien.

Zum Zählen genügt ein einfacher Befehl im Projektordner.

find /var/www/example.com -name "*.php" | wc -l

Bedenken Sie, dass die Zahl alle Skripte umfasst, die in den Cache gelangen, nicht nur die viel genutzten. Erreichen Sie das Limit, bleiben neue Dateien draußen, und bei manchen Anfragen kehrt der Kompilieraufwand zurück. Die Dokumentation nennt einen gültigen Bereich von 200 bis 1.000.000.

Sollte opcache.validate_timestamps an oder aus sein?

Das ist die wichtigste Abwägung bei OPcache. Ist die Direktive an, prüft OPcache alle revalidate_freq Sekunden, ob sich eine Datei geändert hat. Ist sie aus, prüft er nie. Die Dokumentation sagt, dass Sie dann opcache_reset oder opcache_invalidate aufrufen oder den Webserver neu starten müssen, damit Änderungen sichtbar werden.

Welche Variante passt zu Ihnen? In der Entwicklung lassen Sie die Prüfung an, denn Sie wollen nach jeder Änderung nicht an Resets denken. Auf einer Live Seite wirkt Ausschalten verlockend. Tun Sie es allerdings nur, wenn Ihr Deployment den Cache automatisch zurücksetzt.

Bei WordPress ist das Risiko höher. Aktualisieren Sie ein Plugin oder Theme im Dashboard, ändern sich Dateien auf der Platte. Bei ausgeschalteter Prüfung kann alter Code im Speicher bleiben, und die Seite verhält sich, als hätte sie nur halb aktualisiert. Schalten Sie die Prüfung daher nicht aus, wenn Sie die Live Seite nicht vollständig kontrollieren.

Was bewirken revalidate_freq, save_comments und der Puffer für interned Strings?

Bei aktiver Zeitstempelprüfung legt revalidate_freq das Prüfintervall in Sekunden fest. Der Standard ist 2. Laut Dokumentation bedeutet der Wert 0, dass OPcache bei jeder Anfrage nach Änderungen sucht. Ist validate_timestamps aus, ignoriert PHP diese Direktive.

Die Direktive save_comments steht standardmäßig auf 1. Schalten Sie sie aus, wirft OPcache Dokumentationskommentare weg, und der Cache schrumpft etwas. Die Dokumentation warnt jedoch, dass Frameworks mit Annotationen in Kommentaren dann brechen können, darunter Doctrine, Zend Framework 2 und PHPUnit. Lassen Sie sie also an, solange Sie die Abhängigkeiten Ihres Codes nicht kennen.

Der Puffer für interned Strings hält jeweils eine Kopie wiederkehrender Zeichenketten. Der Standard liegt bei 8 MB. Bei einer großen Codebasis kann dieser Bereich volllaufen, und Sie sehen das in der Statusausgabe. Dann können Sie eine Erhöhung erwägen, messen Sie aber zuerst.

• revalidate_freq: Prüfintervall, nur relevant bei aktiver Zeitstempelprüfung.
• save_comments: behält Kommentare, die Annotationen nutzender Code braucht.
• interned_strings_buffer: Bereich für Zeichenketten, aus dem Gesamtspeicher genommen.

Wie sieht eine Beispielkonfiguration für OPcache aus?

Der folgende Block ist ein Beispiel, keine offizielle Empfehlung und kein Standardwert. Passen Sie die Zahlen an Ihre eigenen Messungen an. Erlaubt Ihr Hoster keine Änderung der php.ini, fragen Sie diese Werte über die PHP Optionen im Kundenmenü oder über den Support an.

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=2

Wir haben validate_timestamps bewusst eingeschaltet gelassen. Ausschalten setzt voraus, dass Ihr Deployment einen Reset Schritt enthält. Außerdem hängt der Speicherort der Konfigurationsdatei von Distribution und Aufbau ab. Die richtige Datei finden Sie in der Zeile Loaded Configuration File der phpinfo Ausgabe.

Nach einer Änderung muss PHP die Einstellungen neu lesen. INI_SYSTEM Direktiven ändern sich nicht zur Laufzeit. Deshalb starten Sie den PHP FPM Prozess oder den Webserver neu oder laden ihn neu. Der Dienstname unterscheidet sich je nach Aufbau.

Wie prüfen Sie mit phpinfo und opcache_get_status, ob die Einstellungen greifen?

Eine Einstellung zu schreiben reicht nicht, Sie müssen sie auf der Webseite wirken sehen. Am einfachsten legen Sie eine temporäre PHP Datei an, die phpinfo aufruft. Suchen Sie den Abschnitt Zend OPcache und vergleichen Sie Ihre Werte damit. Löschen Sie die Datei sofort danach, denn phpinfo verrät Serverdetails.

Für mehr Details nutzen Sie opcache_get_status. Übergeben Sie false als Parameter include_scripts, entfällt die lange Skriptliste, und die Ausgabe wird lesbarer. Diese eine Zeile genügt als Dateiinhalt, das öffnende PHP Tag ergänzen Sie selbst.

var_dump(opcache_get_status(false));

Achten Sie auf vier Feldgruppen. Die Felder opcache_enabled und cache_full zeigen den Gesamtzustand. Danach nennt memory_usage den belegten, freien und verschwendeten Speicher. Dann liefert opcache_statistics die Werte num_cached_scripts, hits, misses und opcache_hit_rate. Schließlich trennen oom_restarts und hash_restarts die Gründe für Neustarts.

Wie setzen Sie OPcache nach einem Deployment zurück?

Wenn Sie neuen Code ausliefern, können alte Opcodes im Speicher bleiben. Bei aktiver Zeitstempelprüfung erledigt sich das nach Sekunden. Bei ausgeschalteter Prüfung müssen Sie selbst zurücksetzen. PHP bietet zwei Funktionen: opcache_reset leert den ganzen Cache, opcache_invalidate macht eine einzelne Datei ungültig.

Zu opcache_invalidate nennt die Dokumentation zwei Hinweise. Standardmäßig macht die Funktion die Datei nur ungültig, wenn deren Änderungszeit neuer ist als die der gecachten Opcodes. Der Parameter force erzwingt das ohne Bedingung. Außerdem erzwingt sie nur eine Neukompilierung und entfernt den Eintrag nicht. Sie ersetzt also opcache_reset nicht, wenn der Cache voll ist.

Warum verhält sich OPcache bei CLI und Web unterschiedlich?

In den meisten Aufbauten sind die PHP Version auf der Kommandozeile und die PHP Version hinter Ihrem Webserver oder FPM getrennte Prozesse mit getrennten Opcode Caches. Nutzerhinweise im PHP Handbuch sagen es klar: Ein opcache_reset von der CLI leert den Webcache nicht. Die Funktion kann true liefern, und die Webseite bleibt trotzdem unverändert.

Dieses Detail verursacht also viele Fehler. Jemand verbindet sich per SSH, führt einen Reset aus und glaubt, das Problem sei erledigt. Währenddessen liefert die Website weiter alten Code aus. Stellen Sie daher sicher, dass Sie den Reset auf der Webseite ausführen.

Außerdem steht enable_cli standardmäßig auf aus. OPcache in der CLI als aus zu sehen, ist also für sich kein Problem. Entscheidend ist die Einstellung, die Ihre Webanfragen sehen. Prüfen Sie deshalb immer über eine HTTP Anfrage.

• Die CLI Ausgabe zeigt den Webzustand nicht zwingend.
• Ein Reset von der CLI berührt den Webcache womöglich nicht.
• Ein Skript, das über den Webserver läuft, liefert die verlässliche Prüfung.

Wie nutzen Sie eine OPcache Reset Adresse sicher?

Nutzerhinweise im Handbuch empfehlen einen gängigen Trick: ein kleines, per Web erreichbares Skript schreiben und aufrufen. Technisch funktioniert das. Lassen Sie das Skript aber für alle offen, kann jeder Ihren Cache immer wieder leeren und Ihre Seite grundlos verlangsamen.

Beachten Sie deshalb zwei Regeln. Erstens lassen Sie das Skript nie ohne Anmeldung stehen und erlauben nur die eigene Adresse des Servers. Zweitens legen Sie es nicht auf einen erratbaren Pfad. Noch besser ist es, das Skript gar nicht zu behalten und den Reset als Schritt in Ihrem Deployment Werkzeug auszuführen.

Auch ein temporäres Skript mit Token oder Passwort im Dokumentenstamm ist riskant. Zudem kann eine vergessene Datei monatelang offen bleiben. Für einen breiteren Blick auf Sicherheit ist unser Leitfaden zu den OWASP Top 10 Sicherheitslücken ein guter Start.

Können Sie keinen sicheren Aufbau selbst bauen, bitten Sie Ihren Hoster oder Ihr Entwicklungsteam um den Reset nach dem Deployment.

Was passiert, wenn OPcache volllaufen?

Ist OPcache voll, kann er keine neuen Skripte mehr cachen. Das Statusarray der Dokumentation enthält das Feld cache_full und den Zähler oom_restarts. Der Zähler oom_restarts zeigt Neustarts wegen Speichermangel. Dagegen zählt hash_restarts Neustarts, die mit einer vollen Schlüsseltabelle zusammenhängen.

Die Anzeichen sind meist indirekt. Die CPU Auslastung des Servers bleibt womöglich höher als erwartet, und manche Seiten öffnen zeitweise langsam. Außerdem sieht opcache_hit_rate niedrig aus. Allerdings können auch andere Ursachen dieselben Zeichen erzeugen. Lesen Sie daher die Statusausgabe für eine sichere Diagnose.

• Steht cache_full auf true, ist der Speicher oder das Dateilimit voll.
• Steigt oom_restarts weiter, ist memory_consumption zu klein.
• Steigt hash_restarts weiter, prüfen Sie max_accelerated_files.
• Eine niedrige Trefferquote kann heißen, dass der Cache nie warm wurde oder zu oft zurückgesetzt wird.

Die Lösung ist meist, die passende Direktive zu erhöhen und den Dienst neu zu starten. Bestätigen Sie trotzdem zuerst, dass das Problem wirklich von OPcache kommt.

Was ist OPcache JIT und müssen Sie ihn einschalten?

JIT ist ein Compiler innerhalb von OPcache, der Opcodes in Maschinencode übersetzt. Laut PHP Dokumentation wurde der Standard von opcache.jit mit PHP 8.4.0 auf "disable" gesetzt, frühere Versionen nutzten "tracing". Steht jit_buffer_size auf null, bleibt JIT ohnehin aus. Prüfen Sie das Handbuch für Ihre Version.

Eine typische WordPress Seite oder ein Shop wartet vor allem auf die Datenbank und auf Ein und Ausgabe. Erwarten Sie von JIT daher keinen großen Gewinn. JIT lohnt sich eher bei rechenintensiven Aufgaben. Stellen Sie deshalb zuerst die gewöhnlichen OPcache Einstellungen richtig ein.

Außerdem sagt das Handbuch, dass bei aktivem JIT das gemeinsame Speichersegment memory_consumption plus jit_buffer_size umfasst. Das verändert also Ihre Speicherplanung. Schalten Sie JIT erst nach einer Messung Ihrer eigenen Last ein und halten Sie das Ergebnis fest.

Wie unterscheiden sich OPcache, Redis, Memcached, Varnish und Seitencache?

Man verwechselt diese Werkzeuge leicht, weil alle als Cache gelten. Tatsächlich arbeitet jedes an einem anderen Glied der Kette. Man fragt oft, was ist OPcache im Vergleich zu den anderen. Er speichert Code, Redis und Memcached speichern Daten, Varnish oder ein Seitencache speichern HTTP Ausgabe. Keines ersetzt also ein anderes, sie ergänzen sich.

Das Daten Caching erklären wir bereits ausführlich in Caching erklärt mit Redis und Memcached, deshalb wiederholen wir es hier nicht. Merken Sie sich nur: Hoster installieren OPcache meist schon, die anderen Ebenen brauchen eigene Entscheidungen.

Wie messen Sie die Wirkung von OPcache?

Einstellungen ohne Messung zu ändern, ist Raten. Testen Sie vor dem Eingriff dieselben Seiten unter denselben Bedingungen und danach noch einmal. Die nützlichste Kennzahl ist, wie schnell der Server das erste Byte sendet. Sie sehen sie in den Entwicklertools des Browsers oder in einem Lighthouse Bericht.

Testen Sie nicht nur einmal. Netzwerk und Serverlast schwanken, wiederholen Sie jede Messung also mehrfach. Außerdem ist die erste Anfrage vor dem Aufwärmen des Caches immer langsamer. Vergleichen Sie deshalb die Ergebnisse mit warmem Cache.

Lighthouse erklären wir in unserem Lighthouse Leitfaden zur Website Performance. Den Bezug zur Sichtbarkeit in der Suche zeigt wie die Ladezeit SEO beeinflusst. Zum Beispiel finden Sie LCP und INP in unserem Leitfaden zu den Core Web Vitals.

Eine Zahl versprechen wir nicht. Das Ergebnis hängt von Codebasis, Plugins und Server ab.

Wann sehen Besucher eine Codeänderung bei aktivem OPcache?

Die Antwort hängt von zwei Direktiven ab. Ist validate_timestamps an, prüft OPcache alle revalidate_freq Sekunden die Änderungszeit der Datei. Der Standard sind 2 Sekunden. Daher geht eine neue Version kurz nach der Änderung live.

Ist validate_timestamps aus, ändert sich das Bild. OPcache schaut nie auf die Datei und liefert die alten Opcodes, bis Sie etwas anderes sagen. Das Handbuch rät außerdem, opcache_invalidate vor dem Löschen einer Datei aufzurufen. Sonst kann der Eintrag im Cache liegen bleiben.

In der Praxis liefern Sie einen Fix aus, aber Besucher sehen weiter das alte Verhalten. Schließen Sie zuerst die Cache Ebenen der Reihe nach aus. Prüfen Sie den Browser, dann den Seitencache, dann OPcache. So finden Sie die schuldige Ebene schnell.

Was können Sie Ihren Hoster zu OPcache fragen?

Verwalten Sie den Server nicht selbst, ist die richtige Frage die halbe Lösung. Supportteams geben oft allgemeine Antworten. Stellen Sie konkrete und messbare Fragen, löst der Hoster das Problem schneller, und Sie erfahren, was sich geändert hat.

• Ist OPcache für die Webseite dieses Kontos aktiv?
• Welche Werte haben memory_consumption und max_accelerated_files?
• Ist validate_timestamps an, und wenn nicht, wie setzen Sie nach einem Deployment zurück?
• Kann ich diese Werte im Kundenmenü oder per Support Ticket ändern?
• Verursacht ein Neustart des PHP Dienstes einen kurzen Ausfall?

Notieren Sie die Antworten und führen Sie ein Protokoll. Tritt später nach einem Update ein Problem auf, erleichtert es Ihre Arbeit, wenn Sie wissen, welche Einstellung sich wann geändert hat. Prüfen Sie Ihre eigenen Werte dann mit den Messschritten aus diesem Leitfaden.

Wann überlassen Sie OPcache besser Ihrem Hoster?

Bei Shared Hosting ist Ihre Kontrolle über die php.ini begrenzt, und das ist normal. Der Hoster verwaltet OPcache sehr wahrscheinlich mit einer Konfiguration für alle Konten. In diesem Fall bringt eine konkrete Frage an den Support mehr, als Einstellungen hinterherzujagen.

Überlassen Sie die Arbeit dem Hoster oder jemandem, der die Infrastruktur kennt, in diesen Fällen. Teilen sich mehrere Websites einen Server, trifft ein einziger falscher Wert alle. Auch Experimente an einem Live Shop sind riskant. Wissen Sie außerdem nicht, ob ein Neustart des Dienstes einen Ausfall verursacht, lassen Sie die Finger davon.

• Ohne Zugriff bitten Sie den Support um die aktuellen Werte und die Reset Methode.
• Bei einem Live Shop testen Sie die Änderung zuerst an einer Testkopie.
• Ändern Sie nie Servereinstellungen ohne Backup.

Für den Backup Plan lesen Sie unsere Website Backup Strategie. Bei der Hostingwahl hilft Webhosting auswählen weiter.

Welche Fehler passieren bei OPcache am häufigsten?

Die meisten Fehler entstehen nicht durch die Einstellung selbst, sondern durch die Prüfung am falschen Ort. Die Liste unten fasst die Verwechslungen zusammen, die wir in der Dokumentation am häufigsten sehen. Alle folgen aus dem Verhalten laut offizieller Dokumentation, nicht aus eigener Serverpraxis.

• Aus der CLI Ausgabe auf den Webzustand schließen.
• validate_timestamps ausschalten und den Reset nach dem Deployment vergessen.
• Das Reset Skript für alle offen lassen.
• max_accelerated_files wählen, ohne die Dateien zu zählen.
• save_comments ausschalten und Code mit Annotationen brechen.
• Nach einer Änderung den Neustart des Dienstes vergessen.

Ein weiterer Fehler ist, OPcache für das Heilmittel jeder Langsamkeit zu halten. Eine langsame Datenbankabfrage oder schwere Bilder werden mit OPcache nicht besser. Suchen Sie daher zuerst den Engpass. Wie Ihre Website von außen aufgebaut ist, zeigt unser CMS Checker.

Was sollten Sie nach der OPcache Optimierung als Nächstes tun?

Ist OPcache gut eingestellt, kommen die anderen Ebenen an die Reihe. Messen Sie zuerst, dann wählen Sie den größten Engpass. Bei den meisten Websites sind das Bilder, schwere Skripte oder ein aufgeblähtes Theme samt Plugins. Servereinstellungen sind nur ein Teil des Bildes.

Um den Zusammenhang zwischen Tempo und Suchergebnissen zu sehen, schauen Sie auch auf die SEO Seite. Möchten Sie technische Gesundheit und Inhaltsplan gemeinsam angehen, deckt das unsere SEO Beratung ab. Für eine neue Website mit Tempozielen von Anfang an sehen Sie sich unser Webdesign an.

Wir sind kein Hostinganbieter und versprechen keinen Serverbetrieb. Als Web und Marketing Team helfen wir Ihnen aber zu verstehen, wie eine Hostingentscheidung Leistung und Sicherheit beeinflusst. Kurz gesagt: Probieren Sie die Schritte aus diesem Leitfaden selbst aus und fragen Sie Ihren Anbieter oder uns, wo Sie unsicher sind.