So machen Sie Ihr langsames WordPress Backend schnell (wp-admin)

10 rich­ti­ge Wege, um Ihr lang­sa­mes WP-Admin-Backend schnel­ler zu machen.

Wenn Sie frus­triert sind über ein lang­sa­mes Backend, das ewig braucht, um von einer Seite zur nächs­ten zu gelan­gen, dann kön­nen Sie mir glau­ben, dass ich Sie ver­ste­he. Frontend-Seiten sind viel ein­fa­cher zu cachen, aber das Backend ist es nicht.

Bedeutet das, dass Sie für immer mit mise­ra­blen Ladezeiten im Backend und ewig dau­ern­den Verwaltungsfunktionen geplagt sind?

NEIN!…ok, vielleicht…aber ich wer­de Ihnen hel­fen, das Beste aus Ihren Möglichkeiten zu machen.

Die Ursache für langsame Backend

Backends sind lang­sam, weil sie völ­lig dyna­misch sind.

Und mit "dyna­misch" mei­ne ich, dass sie bei jeder Seitenanforderung die Datenbank abfra­gen müs­sen. Die Datenbank wird auf­ge­ru­fen und jede Information wird von Grund auf neu ange­for­dert, als ob sie noch nie zuvor gese­hen wur­de. Es gibt kei­ne Zwischenspeicherung.

Es hilft auch nicht, dass das Backend manch­mal mehr Informationen anzeigt. Welche Nutzer, wel­che Inhalte, wel­che Kommentare, wie vie­le Verkäufe usw. Es wer­den oft Informationen berech­net, die gar nicht ange­zeigt wer­den. Außerdem läuft die Heartbeat-API stän­dig im Hintergrund, um Ihre Änderungen auto­ma­tisch zu speichern.

Datenbanken kön­nen auch lang­sa­mer wer­den, wenn sie grö­ßer wer­den. So wie die Suche nach Dingen in Ihrem Haus schwie­ri­ger wird, wenn Sie mehr Dinge haben. Datenbanken brau­chen län­ger, wenn Sie nach sehr kom­pli­zier­ten Daten suchen, die ver­gra­ben oder auf kom­ple­xe und/oder inef­fi­zi­en­te Weise orga­ni­siert sind.

Mit die­sem Wissen… sehen wir uns an, wie wir die­se dyna­mi­schen Backend-Anfragen opti­mie­ren kön­nen, um Ihre WP-Admin-Erfahrung zu beschleunigen.

1. Überprüfen Sie Ihre Plugins

Jedes Mal, wenn mich jemand wegen eines lang­sa­men Backends um Hilfe bit­tet, gilt er für mich sofort als "schul­dig, bis sei­ne Unschuld bewie­sen ist".

Überprüfen Sie alle Ihre Plugins und fin­den Sie her­aus, wel­che zu die­ser gott­ver­damm­ten lang­sa­men Backend-Last beitragen.

"Aber wie?!"

Etwa so…

1. Deaktivieren Sie eini­ge unwich­ti­ge Plugins, um zu sehen, ob es schnel­ler läuft. Dann deak­ti­vie­ren Sie noch mehr. Machen Sie so wei­ter, bis Sie zu dem Punkt kom­men, an dem kei­ne Plugins mehr akti­viert sind. Ich bin sicher, Sie wis­sen inzwi­schen, wel­che es sind.
2. Sie soll­ten auch Ihr Theme über­prü­fen. Versuchen Sie, bei akti­vier­ten Plugins für eine Sekunde zum Standard-Theme zu wech­seln. Hat es geholfen?

Hahaha, ich mache nur Spaß… igno­rie­ren Sie die ers­ten 2 Schritte (rui­nie­ren Sie nicht Ihre Live-Site) und machen Sie es wie ein Profi. Installieren Sie Query Monitor und sur­fen Sie dann eini­ge Seiten im Frontend, wäh­rend Sie das Diagnose-Panel am unte­ren Rand Ihres Browsers stu­die­ren. Es gibt nur zwei Dinge, die Sie über­prü­fen müs­sen – lang­sa­me Abfragen und Abfragen nach Komponenten. Nur so kön­nen Sie fest­stel­len, wel­che Themen, Plugins oder Abfragen die größ­ten Verzögerungen ver­ur­sa­chen. Sie soll­ten sich auch den Speicherverbrauch (in der obe­ren Verwaltungsleiste) und die Anzahl der Abfragen jedes Plugins ansehen.

Sobald Sie her­aus­ge­fun­den haben, was die Ursache ist, soll­ten Sie sie ersetzen!

• Langsames Slider-Plugin? – Besorgen Sie sich ein neu­es Slider-Plugin!
• Langsames Theme? – Besorgen Sie sich ein ande­res Theme!

Einige von Ihnen wer­den Bindungsschmerzen haben, wenn sie sich von ihren kost­ba­ren Plugins tren­nen müs­sen… aber ich ver­spre­che Ihnen eines… was auch immer für ein beschis­se­nes Plugin Ihr Backend ver­lang­samt, es besteht eine gute Chance, dass es ein qua­li­ta­tiv hoch­wer­ti­ge­res alter­na­tiv Plugin in Entwicklerqualität gibt, das kei­ne Alpträume von lang­sa­men Abfragen verursacht.

 

2. Prüfen Sie auf Fehler

• Error.log – fin­den Sie es in Ihrem public_html-Verzeichnis und schau­en Sie hin­ein. Sehen Sie vie­le Fehler?
• Konsolenfehler – öff­nen Sie die Entwicklertools und sehen Sie nach, ob es offen­sicht­li­che 404-Anfragen gibt.

In der Regel sind es nicht so sehr die Fehler, die das Problem ver­ur­sa­chen, son­dern die Plugins, die mit die­sen Fehlern in Verbindung stehen.

 

3. Prüfen Sie den hohen Speicherverbrauch

Drei Dinge, die Sie wis­sen müssen:

Wie viel Speicherplatz Ihre gesam­te Website ver­braucht. (Versuchen Sie WP Server Health Stats)
Wie viel Speicher Ihr Theme und Ihre Plugins ver­brau­chen. (Query Monitor)
Wie viel Speicherplatz Ihre Autoloads ver­brau­chen.

Von hier aus haben wir ein paar Taktiken.

Natürlich kön­nen Sie ver­su­chen, die Speichergrenzen Ihrer Website zu erhö­hen. Fügen Sie die fol­gen­den Zeilen in Ihre wp-config.php-Datei ein, und zwar ober­halb der Zeile "That's all, stop editing! Viel Spaß beim Bloggen.":

defi­ne( 'WP_MEMORY_LIMIT', '256M' );
defi­ne( 'WP_MAX_MEMORY_LIMIT', '256M' );

Die ers­te Option erhöht den Speicherbedarf für das Frontend, die zwei­te für das Backend. Für die meis­ten gut auf­ge­bau­ten Websites brau­chen Sie bei­des nicht. Sie kön­nen die zwei­te Option sogar auf 512 MB oder noch mehr erhö­hen, aber das Problem ist, dass die­ses Limit immer noch durch das glo­ba­le PHP-Speicherlimit des Servers begrenzt ist. Wenn Sie Ihren eige­nen VPS-Server haben, kön­nen Sie so viel ein­stel­len, wie Sie wol­len. Wenn Sie auf einem beschis­se­nen Shared Host sind, ist es wahr­schein­lich sehr begrenzt und der Versuch, es höher zu set­zen, wird nichts bringen.

Wenn es gesagt wer­den muss, soll­ten Sie Plugins los­wer­den, die so viel Speicher ver­brau­chen. Und ver­ges­sen Sie bit­te nicht, Ihre Autoloads zu über­prü­fen. Oft gibt es vie­le alte Themes oder Plugins, die Sie nicht mehr haben und die immer noch Speicher fres­sen! Sie sit­zen in der Datenbank her­um und laden ihre Indizes, auch wenn kein Plugin sie benutzt!

 

4. Upgrade Ihres Web-Hostings (oder Web-Servers)

Haben Sie alle Ihre auf­ge­bläh­ten Plugins ersetzt?

• NEIN?!
• WARUM NEIN? Weil Sie Geld spa­ren wollten?

Nun, heu­te kön­nen Sie das gespar­te Geld für ein bes­se­res Hosting aus­ge­ben. Tut mir leid, Kumpel, Sie müs­sen für bes­se­re Qualität bezahlen!

Ok, sei­en wir fair… viel­leicht haben eini­ge von Ihnen Ihre Plugins ersetzt. Oder Sie haben gese­hen, dass Ihre Plugins nicht das Problem waren!

Die Antwort ist die­sel­be… der ein­fachs­te Weg, um von die­sem Punkt aus kei­ne Probleme zu haben, ist ein bes­se­rer Webhost oder ein stär­ke­rer Webserver. Beachten Sie, dass ich nicht gesagt habe, dass Sie sich einen teu­ren Webhost suchen sol­len. Nein!

Unabhängig davon, in wel­cher Kategorie von Webhosting Sie sich befin­den (Shared Hosting, VPS usw.), ich garan­tie­re Ihnen, dass es wahr­schein­lich einen ande­ren Webhost gibt, der bes­ser ist und preis­lich nicht so weit entfernt.

Aber sei­en Sie vor­sich­tig… die­ser ein­fa­che Ausstiegsknopf funk­tio­niert nicht so, wie Sie den­ken. Der neue Server darf nicht ein­fach nur teu­rer oder grö­ßer sein, er muss Ihrer Website tat­säch­lich mehr Ressourcen bie­ten! Nur weil Sie sich für einen grö­ße­ren oder stär­ke­ren Server ent­schei­den, bedeu­tet das nicht, dass Ihre Website auto­ma­tisch Zugang zu mehr CPU und Speicher erhält. Ich habe schon vie­le Leute gese­hen, die ein Upgrade durch­ge­führt und das Doppelte bezahlt haben und trotz­dem kei­ne bes­se­re Leistung erhal­ten haben.

Was soll­te ein guter Server haben?

Das ist schwer zu sagen, denn alle Spezifikationen oder Statistiken, die ich Ihnen gebe, könn­ten leicht durch fal­sches Marketing erlo­gen sein (genau wie Sie in Ihre der­zei­ti­ge miss­li­che Lage gera­ten sind). Am ein­fachs­ten ist es zu spü­ren, ob er schnell ist oder nicht.

Aber wenn Sie dar­auf bestehen, ist es gut zu wis­sen, ob sie das neu­es­te PHP und MySQL haben. Schnelle Festplatten mit guten E/A‑Raten. Und aggres­si­ve Einstellungen. Außerdem ist es gut, wenn der PHP-Speicher anstän­dig ist.

 

5. Verringern Sie das Heartbeat-API-Intervall

Dies ist eine nied­rig hän­gen­de Frucht, mit der man ohne gro­ßen Aufwand eini­ge gute Ergebnisse erzie­len kann. Es gibt eini­ge spe­zia­li­sier­te Plugins, die dies tun, wie Heartbeat Control… aber es ist viel bes­ser, wenn Sie es von Ihrem Caching-Plugin (wie Swift, Rocket, LiteSpeed) ver­wen­den können.

Meine Empfehlungen dazu:

• Sie kön­nen Heartbeat (wahr­schein­lich) sicher auf allen Seiten im Frontend und Backend deak­ti­vie­ren, außer im Beitragseditor.
• Deaktivieren Sie ihn nicht im Beitragseditor, da der Heartbeat dort für die auto­ma­ti­sche Speicherung ver­wen­det wird.
• Wenn Sie vie­le Autoren haben, die sich gleich­zei­tig ein­log­gen und arbei­ten, kön­nen Sie das Heartbeat-Intervall für den Beitragseditor ver­län­gern, aber deak­ti­vie­ren Sie es trotz­dem nicht!
• Klicken Sie hier, um mehr über WordPress Heartbeat API zu erfah­ren.

 

6. Objekt-Caching

Sicherlich haben Sie schon ein­mal von Schlagwörtern wie "Memcache" und "Redis" gehört. Redis (heut­zu­ta­ge das bes­se­re und Standardmodul) ist ein Servermodul, mit dem Sie Ihre Datenbankabfragen zwi­schen­spei­chern kön­nen. Es ist sehr schnell, da es die Informationen im Speicher und nicht auf der Festplatte spei­chert (wie beim typi­schen Seiten-Caching).

Es gibt vie­le Vorbehalte und Variablen, die zu beach­ten sind… Ich wer­de im Folgenden all­ge­mei­ne Empfehlungen geben und Sie kön­nen den Rest recher­chie­ren, wenn Sie neu­gie­rig sind:

• Objekt-Caching benö­tigt viel Speicherplatz. Daher ist es nor­ma­ler­wei­se nur bei VPS-Paketen erlaubt und fast nie bei Shared Hosting. Selbst wenn Ihr Shared Hosting Objekt-Caching erlaubt, ist es wahr­schein­lich kastriert.
• Eine gute Ablaufzeit für den Objekt-Cache liegt zwi­schen 5 und 60 Minuten. Ist sie zu kurz, läuft der Cache ab, bevor Sie von ihm pro­fi­tie­ren kön­nen. Bei einer zu lan­gen Zeit ist Ihr dyna­mi­scher Inhalt ver­al­tet, bis der Objekt-Cache abläuft (aber viel­leicht ist das für Sie in Ordnung).
• Objekt-Caching funk­tio­niert wie Seiten-Caching, aber mit kür­ze­ren Cache-"Nutzen"-Zeiten. Die ers­ten paar Treffer sind lang­sam, die fol­gen­den schnell, bis der Cache abläuft (und neu auf­ge­baut wer­den muss).
• Objekt-Caching ist hilf­reich, wenn Sie viel im Backend arbei­ten. Wenn Sie nur ein paar Minuten pro Tag ein- und aus­ge­hen, sind Sie wahr­schein­lich ohne Objekt-Caching schneller.

Falls Sie sich wun­dern, heißt es Objekt-Caching, weil es die Datenbankabfragen (auch bekannt als "Datenbankobjekte") zwi­schen­spei­chert… was Ihnen erlaubt, die meis­ten Ihrer dyna­mi­schen Funktionen bei­zu­be­hal­ten, aber von schnel­le­ren Geschwindigkeiten zu pro­fi­tie­ren (da eini­ge Abfragen bereits erstellt sind und nicht bei jedem Klick nach­ge­schla­gen wer­den müssen).

 

7. Zwischenspeichern von Admin-Bereichen und eingeloggten Benutzern.

Also gut, das hier ist ein abso­lu­ter Verzweiflungsmodus. Meistens ist es eine schlech­te Idee, aber in man­chen Situationen kann es funk­tio­nie­ren. Hier ist, wann es hilft und wann es nicht hilft:

HILFT, wenn…

• Sie vie­le ein­ge­logg­te Benutzer haben.
• Ihre ein­ge­logg­ten Benutzer sehen haupt­säch­lich sta­ti­sche Inhalte.

HILFT NICHT, wenn…

• Sie nicht vie­le ein­ge­logg­te Benutzer haben.
• Ihr gesam­tes Backend voll­stän­dig auf dyna­mi­sche Daten ange­wie­sen ist.

Wenn Sie wirk­lich dar­über nach­den­ken, hilft Ihnen das Caching nur, wie­der­hol­te Inhalte schnel­ler zu laden. Wenn Sie kei­ne sta­ti­schen Backend-Inhalte oder genü­gend Benutzer haben, um davon zu pro­fi­tie­ren, ist das Zwischenspeichern des Admin-Bereichs IMO nicht von gro­ßem Nutzen. Wenn über­haupt, dann wird Ihre Website dadurch noch lang­sa­mer! (Langsamer, weil Ihre Server-Ressourcen jetzt für den Aufbau und die Löschung von Caches ver­schwen­det wer­den, die nicht ein­mal genutzt werden).

WIE man das Backend cachen kann?

Aktivieren Sie die fol­gen­den Funktionen in Ihrem Cache-Plugin:

• Cache-Administrationsbereich – soll­te ein­fach genug sein.
• Cache für ein­ge­logg­te Benutzer – Sie müs­sen even­tu­ell ent­schei­den, wel­che Bereiche öffent­lich oder pri­vat sind. Öffentlich bedeu­tet, dass alle Benutzer den­sel­ben Inhalt sehen. Privat bedeu­tet, dass alle Benutzer unter­schied­li­che Inhalte sehen (z. B. ihre "Konto"-Seiten).
• ESI-Cache – Sie kön­nen mit die­ser Löcherstanztechnologie spie­len, aber ich war­ne Sie, dass dies nichts für Heimwerker ist. Sie brau­chen einen Entwickler, um das rich­tig zu machen. Wenn Sie LiteSpeed Server und Caching ver­wen­den, ist es am ein­fachs­ten, ESI zu nut­zen, wenn Ihr Inhalt über Shortcodes oder in einem Widget bereit­ge­stellt wird.

 

8. Überprüfen Sie Ihr Sicherheits-Plugin

Haben Sie Wordfence oder Sucuri? Nun, Sie müs­sen sie nicht los­wer­den, aber Sie soll­ten wis­sen, dass sie das Backend stark ver­lang­sa­men. Denn sie über­prü­fen jeden Seitenaufruf auf die Ausführung von Hacks und so weiter.

Sicherlich haben Sie schon Anleitungen gese­hen, die Ihnen raten, das Scannen zu ver­lang­sa­men… aber das macht wirk­lich nicht viel aus. Das liegt dar­an, dass die­se Sicherheitsplugins jeden Seitenaufruf pro­to­kol­lie­ren und auf poten­zi­ell schäd­li­che Codeausführungen überprüfen.

 

9. Verhindern Sie unnötige Plugin-Last im Backend

Willkommen bei der "Freude" des Asset Load Management. Hier deak­ti­vie­ren wir alle unnö­ti­gen CSS/JS-Aufrufe aus dem Backend.

Ich neh­me zurück, was ich über den vor­he­ri­gen Schritt gesagt habe. Es gibt einen Schritt, der noch ver­zwei­fel­ter ist als der vor­he­ri­ge. Früher habe ich ver­sucht, bis zu die­sem Grad zu opti­mie­ren, aber ich habe erkannt, dass das dumm ist. Ihr Leben ist wert­vol­ler, als damit Zeit zu ver­schwen­den. Es hat über­haupt kei­nen Sinn … das ist so, als wür­de man am Abend vor dem Schlammlaufen am nächs­ten Tag die Sohlen sei­ner Schuhe putzen.

• Sie soll­ten ein Qualitäts-Theme haben.
• Mit Qualitäts-Plugins.
• Auf einem guten Webserver.
• Und Ihre Autoloads soll­ten von allen Überbleibseln alter Themes/Plugins befreit sein.

Wenn Sie hier sind und ver­su­chen, eine Zeitreise durch Ihr Leben zu machen, indem Sie CSS/JS-Assets ein- und aus­schal­ten, liegt das dar­an, dass Sie bei einem frü­he­ren Schritt stur waren. Ich emp­feh­le Ihnen drin­gend, zurück­zu­ge­hen und alles ande­re zu tun. Sie wer­den am Ende so viel mehr Arbeit machen, als wenn Sie nur Ihre Themes/Plugins aus­tau­schen wür­den. UND Sie könn­ten ver­se­hent­lich Ihre Website beschä­di­gen oder zukünf­ti­ge Vorgänge beein­träch­ti­gen und ver­ges­sen, dass Sie etwas deak­ti­viert haben.

Wollen Sie trotz­dem wei­ter­ma­chen? *seufz* Ok, Sie haben gewon­nen. Empfehlungen unten:

• Ich bevor­zu­ge Asset CleanUp: Page Speed Booster gegen­über all den ande­ren Asset-Loadern oder Plugin-Organizer-Plugins da draußen.
• Perfmatters kann auch ganz nett sein.
• WP Gonzalez und Plugin Load Filter sind eben­falls in Ordnung.
• Der Rest ist ent­we­der 1) zu kom­pli­ziert und schlecht zu bedie­nen, oder 2) sie fügen ihre eige­ne Last hin­zu, die die Last, die sie ent­fernt haben, zunich­te macht!
• Versuchen Sie nicht, jedes ein­zel­ne Asset aus jedem Plugin zu ent­fer­nen. Konzentrieren Sie sich auf die wich­tigs­ten auf­ge­bläh­ten Plugins!

Der ein­zi­ge pro­fes­sio­nel­le Weg, um unnö­ti­gen Ballast aus Plugins zu entfernen:
Forken Sie das Plugin und hacken Sie es.

 

10. Widerstehen Sie den dummen Ideen

Ich habe gehört, dass Kunden von Zeit zu Zeit vie­le dum­me Taktiken aus­he­cken. Sie lesen zufäl­li­ge Worte im Internet und den­ken, dass sie zutref­fen. Ich freue mich, sie im Folgenden für Sie zu widerlegen:

• Ein bes­se­res Cache-Plugin - lei­der nein. Cache-Plugins sind in der Regel für den Einsatz im Frontend gedacht.
• Installation von Performance-Plugins – Ich habe all die dum­men Booster-Plugins für WooCommerce, Pagebuilder und so wei­ter gese­hen. Im bes­ten Fall bean­spru­chen sie nur mehr Speicher über Autoloads, so dass das Plugin schnel­ler läuft, wäh­rend der Rest Ihrer Website lang­sa­mer wird.
• Erhöhen des Speicherlimits – dies ermög­licht ledig­lich, dass Ihre lang­sa­me Website wei­ter­läuft, anstatt Fehler zu machen. Dies führt nicht dazu, dass Ihre Website ihren [ver­schwen­de­ri­schen] Speicherverbrauch reduziert.
• Cloudflare zwi­schen­spei­chern Ihren Admin – DUMM! NEIN!
• Statische Seiten – nein, sta­ti­sche Seiten sind nur für das Frontend gedacht.
• Load Balancing oder Cluster-Setup – wenn Ihre Website zu auf­ge­bläht ist, um auf einem Server zu laden, wird das Hinzufügen eines wei­te­ren Proxys nicht hel­fen oder die Last in irgend­ei­ner Weise umver­tei­len. Das ist so, als wür­de man ver­su­chen, einen Kuchen mit 2 Küchen zu backen, anstatt mit einer. Lastausgleich ist für hohen Datenverkehr gedacht, nicht für lang­sa­men Code.
• Remote Datenbank – lol, nein! Ihre lang­sa­me Datenbank läuft jetzt noch lang­sa­mer, da sie sich nicht auf dem­sel­ben Server befindet.
• Asset-Organisation (Schritt 7 oben) – denn selbst wenn Sie die Assets her­aus­schnei­den, wer­den Sie die Abfragen nicht her­aus­schnei­den. Und beden­ken Sie, dass die Asset-Verwaltung meist nur den Frontend-Benutzern hilft, da die Backend-Benutzer die­se Assets nicht ein­mal zum Laden verwenden.
• Tuning der MySQL-Konfigurationen – Ich bezweif­le stark, dass dies Ihr Problem ist.

Eine gewis­se Geschwindigkeitsoptimierung ist für Nicht-Entwickler wirk­lich nicht zu machen. Selbst wenn Sie Ihre Website nicht kaputt machen, ver­bes­sern Sie Ihre lang­sa­me Geschwindigkeit viel­leicht nur um 10 % (wenn Sie sie nicht sogar noch ver­schlim­mern). Ich emp­feh­le Ihnen, einen Entwickler zu enga­gie­ren, wenn Sie so weit gekom­men sind.