Wie man Local WP unter Windows optimiert, damit es schneller lädt

Um eine Website lokal zu klonen Local WP ist ziemlich gut. Das Problem ist, dass es manchmal langsam wird, sogar von Anfang an und auf leistungsstarken Rechnern.

Und klar: Wenn es langsam ist, nervt es ziemlich. Denn eigentlich arbeitet man lokal nicht nur aus Sicherheitsgründen, sondern auch, um schneller zu sein, nicht um jedes Mal drei Sekunden zu warten, wenn man eine Admin-Seite öffnet.

Bei meinem neuen Website-Projekt passierte mir genau das, aber ich wollte das Tool nicht wechseln. Ich wollte kein Docker aufsetzen, die Umgebung nicht wegwerfen und nicht bei null anfangen. Ich wollte, dass Local WP wieder (sehr) brauchbar wird.

Nachdem ich mehrere Dinge ausprobiert hatte, sind das die fünf Schritte, die bei mir wirklich funktioniert haben.

Es gibt noch mehr Optimierungsmöglichkeiten, aber ich habe mich auf diese beschränkt und jetzt läuft mein lokales Setup wie geschmiert.

1. Prüfen, ob Xdebug deaktiviert war

Als Erstes habe ich geprüft Xdebug.

Xdebug dient zum Debuggen von PHP. Wenn du Breakpoints setzen, Variablen inspizieren und ernsthaft debuggen willst, perfekt. Dafür ist es da.

Wenn du es aber nicht nutzt, kann es die Umgebung deutlich verlangsamen.

In Local WP prüfst du das über die Website-Ansicht:

Local WP > deine Website > Tab Overview / Tools > Xdebug

In meinem Fall war es bereits deaktiviert, also musste ich nichts ändern. Aber aus Erfahrung war es der erste Verdächtige, den man ausschließen musste.

Die Regel ist einfach: wenn du PHP nicht aktiv debuggst, Xdebug deaktiviert lassen.

Hier war es in meinem Fall nicht “die Lösung”, weil es schon ausgeschaltet war, aber es kostet nichts, das zu prüfen, bevor man sich mit anderen Dingen verrückt macht.

2. Die Domain von .local auf .test ändern

Diese Änderung hat man tatsächlich gemerkt.

Ich hatte die Website mit einer Domain, die auf .local endete (yg.local), und habe sie geändert zu yg.test.

In Local WP geht das so:

1. Local WP öffnen.
2. Die Website auswählen.
3. Zum Tab Overview gehen.
4. Das Feld Site domain suchen.
5. Klicke auf Change.
6. Die Domain von .local auf .test ändern.
7. Die Änderung bestätigen.
8. Die Website neu starten.

Danach rufst du sie über die neue URL auf:

https://yg.test

Oder, wenn SSL in Local nicht aktiv ist:

http://yg.test

Warum funktioniert das? 

Weil .local in manchen Umgebungen wegen der Auflösung auf Netzwerkebene Probleme machen kann. .test ist viel stärker für lokale Entwicklung gedacht und vermeidet einen Teil dieser absurden Reibung.

Es ist eine einfache Änderung, die in meinem Fall geholfen hat.

3. Die Local-WP-Ordner vom Windows-Antivirus ausschließen

Eine weitere wichtige Einstellung.

Wenn du mit Windows arbeitest, kann Windows Defender ständig die WordPress-Dateien prüfen, Plugins, Themes, Uploads, Datenbank, Logs, Caches und interne Dienste von Local.

Und klar, WordPress bewegt lokal Unmengen kleiner Dateien. Wenn der Antivirus anfängt, alles zu prüfen, was PHP, MySQL oder nginxanfasst, leidet die Performance.

Natürlich habe ich den Antivirus nicht deaktiviert, sondern Ausnahmen hinzugefügt.

In Windows:

1. Windows-Sicherheit öffnen.
2. Zu Viren- & Bedrohungsschutz gehen.
3. Bis zu Einstellungen für Viren- & Bedrohungsschutz scrollen.
4. Klicke auf Einstellungen verwalten.
5. Bis zu Ausschlüsse scrollen.
6. Klicke auf Ausschlüsse hinzufügen oder entfernen.
7. Ausschlüsse vom Typ Ordner hinzufügen.

Der wichtige Ordner ist der für die lokalen Websites:

C:UsersDEIN_BENUTZERLocal Sites

Und außerdem die internen Local-Ordner, die normalerweise in Pfaden wie diesen liegen:

C:UsersDEIN_BENUTZERAppDataLocalProgramsLocal

Und:

C:UsersDEIN_BENUTZERAppDataRoamingLocal

In meinem Fall war es besonders wichtig, Local Sites auszuschließen, denn dort liegt die Website tatsächlich: WordPress, Plugins, Themes, Uploads und alles, was Local ständig anfasst.

Nach dem Hinzufügen der Ausnahmen sollte man die Website in Local WP stoppen und wieder starten.

4. Plugins deaktivieren, die ich lokal nicht brauchte

Der nächste Schritt war ziemlich offensichtlich, aber manchmal vergisst man ihn oder macht ihn lieber nicht, um die Produktionsumgebung besser zu simulieren.

Es gibt Plugins, die externe Aufrufe machen, geplante Aufgaben starten, Sicherheitsprüfungen durchführen, Backups, Logs, Caches, SEO-Analysen, Newsletter-Integrationen, Monitoring, Bildoptimierung und tausend andere Dinge.

All das kann lokal überflüssig sein, je nachdem, was du gerade testest.

Also habe ich die Plugin-Liste geprüft und die deaktiviert, die ich für die Arbeit in diesem Moment nicht brauchte.

Die Frage war diese: 

Brauche ich dieses Plugin aktiv für das, was ich gerade mache?

Wenn die Antwort nein war, habe ich es deaktiviert.

In meinem Fall:

1. Backup-Plugins.
2. Genesis-Plugins.
3. Sicherheits-Plugins.
4. Cache-Plugins.
5. Analytics-Plugins.
6. Plugins, die geplante Aufgaben starten

Weniger aktive Plugins bedeuten weniger Last, weniger Hintergrundprozesse und weniger Dinge, die um Ressourcen konkurrieren.

Trotzdem habe ich hier keine große Verbesserung gesehen, deshalb wäre es vielleicht sinnvoll, diesen Schritt ans Ende zu setzen, falls alles andere nicht reicht.

5. Die Datenbank über die Local-Shell bereinigen

Der letzte Schritt war die Bereinigung der Datenbank.

WordPress sammelt sehr leicht Müll an: Revisionen, automatische Entwürfe, transients abgelaufene Einträge, Kommentare im Papierkorb, Spam, verwaiste Metadaten und Plugin-Reste.

Dafür habe ich die Website-Shell über Local WP geöffnet:

Local WP > deine Website > Open Site Shell

Vor der Bereinigung habe ich ein Backup der Datenbank erstellt:

wp db export backup-before-cleanup.sql

Dann habe ich diesen Bereinigungsblock ausgeführt:

wp post delete $(wp post list --post_type='revision' --format=ids) --force
wp post delete $(wp post list --post_status='auto-draft' --format=ids) --force

wp post delete $(wp post list --post_status='trash' --format=ids) --force

wp comment delete $(wp comment list --status=spam --format=ids) --force

wp comment delete $(wp comment list --status=trash --format=ids) --force

wp transient delete --expired

wp db query "DELETE pm FROM wp_postmeta pm LEFT JOIN wp_posts p ON p.ID = pm.post_id WHERE p.ID IS NULL;"

wp db query "DELETE cm FROM wp_commentmeta cm LEFT JOIN wp_comments c ON c.comment_ID = cm.comment_id WHERE c.comment_ID IS NULL;"

wp db query "DELETE tm FROM wp_termmeta tm LEFT JOIN wp_terms t ON t.term_id = tm.term_id WHERE t.term_id IS NULL;"

wp db query "DELETE um FROM wp_usermeta um LEFT JOIN wp_users u ON u.ID = um.user_id WHERE u.ID IS NULL;"

wp db optimize

Eine Sache ist wichtig: Das setzt voraus, dass der Tabellenpräfix wp_ ist.

Wenn du unter Windows bist und diese Variablensyntax bei dir nicht funktioniert, nutze direkt den zurückgegebenen Präfix:

wp db prefix

und ersetze ihn von Hand.

Dieser Schritt ist nichts, was man in Produktion leichtfertig machen sollte. Lokal, mit vorherigem Backup, ja.

Ergebnis

Nach diesen fünf Schritten lief Local WP deutlich besser. Logisch, denn mein Ryzen 7 2700 Pro mit NMVE und 24GB ist erheblich leistungsstärker als der Produktionsserver.

Deshalb war mir klar, dass es sich lohnte, ein kleines Weilchen zu investieren.

Jetzt läuft es, wie es soll, und ich habe mir viele kleine Weilchen gespart.

Die Zusammenfassung wäre:

1. Prüfen, ob Xdebug deaktiviert ist.
2. Die Domain von .local auf .test ändern.
3. Local-WP-Ordner in Windows Defender ausschließen.
4. Unnötige Plugins lokal deaktivieren.
5. Die Datenbank über die Shell bereinigen.

Im Grunde: der Umgebung Ballast abwerfen.

In diesem Fall ist Local WP nicht aus einem einzigen Grund langsam, sondern wegen der Summe kleiner Dinge: Domain-Auflösung, Antivirus, der jede Datei anschaut, überflüssige Plugins und eine Datenbank voller Reste.

Ich habe nicht alles mit der Stoppuhr gemessen, sondern nach Gefühl. Deshalb weiß ich, was bei mir funktioniert hat.

Jetzt habe ich meine lokale Kopie, die wie geschmiert läuft, also habe ich keine Ausrede mehr, in Produktion zu arbeiten und nicht zu testen.

Und du, nutzt du noch dieselbe Ausrede?