WordPress ist eine nicht gerade kleine Software. Deshalb kann es durchaus vorkommen, dass das Laden von Artikel viel Zeit in Anspruch nimmt. Das ist nicht nur nervig, sondern auch unvorteilhaft für das Suchmaschinenranking. Man kann aber etwas dagegen tun: Caches.
Zunächst einmal ist es wichtig, eine PHP-Version mit Caching einzusetzen. Ab PHP 5.5 wurde OPCache per Default mitgeliefert. PHP 7 ist gegenüber PHP 5 aufgeräumt wurden, was es zusätzlich flotter macht.
Als zweiten Punkt sollte man Caching von WordPress selbst ins Auge fassen. Es gibt etliche Plugins in WordPress‘ Plugin-Directory, die man benutzen kann. Das beliebte W3 Total Cache ist übrigens mit WordPress 4.7.1 nicht mehr kompatibel. Update: Dieser Effekt betrifft scheinbar nicht alle WordPress-Installationen bzw. PHP-Konfigurationen.
Ich benutze daher WP Super Cache, was auch für Laien recht einfach zu benutzen ist, weil es diverse Einstellungen als empfohlen markiert. Daran kann man sich beim Einstellen orientieren.
Wenn man diesen Schritten folgt, baut WordPress die Seiten und Artikel schon ein gutes Stück schneller auf. Aber mitunter noch ausbaufähig. Eine weitere Möglichkeit ist ein auf Redis basierender Cache wie Redis Cache. Redis ist eine NoSQL-Datenbank mit einfacher Key-Value-Struktur.
In meinem Falle hat dieses Plugin den Seitenaufbau nochmals spürbar beschleunigt. Man verbindet das Plugin in den Einstellungen mit dem Redis Server (was z. B. über einen Unix-Socket läuft) und anschließend cached WordPress auch über Redis, was sich (zumindest in meinem Fall) fast schon deutlicher als die vorherigen Schritte bemerkbar gemacht hat. Nachteil hier ist eben nur, dass man sich um einen Redis-Server kümmern muss. Wenn man auf dem Webserver nur noch begrenzt Ressource frei hat, sollte man auf diese Maßnahme eher verzichten.
tl;dr
- Benutze PHP 7 oder eine PHP Version mit Opcache
- Benutze Caching Plugins wie WP Super Cache
- Benutze Redis Cache, falls möglich (benötigt zusätzlichen Redis-Server)
20 Antworten zu „WordPress Beine machen“
Ich habe mit einer anderen Kombination durchweg gute Erfahrungen gemacht: Nginx + PHP-FPM + Memcached + Cachify. Da die Memcached-Schnittstelle schon direkt in Nginx eingebaut ist, ist beim Abruf aus dem Cache nicht eine einzige Zeile PHP mehr mit im Spiel. Das spiegelt sich dann auch in den PageSpeed Insights wieder: 99 Mobil und 95 Desktop.
hallo
ich habe etwas mit redis rumgespielt und muss leider feststellen, dass der „make test“ einen fehler in der replikation hat. zumindest läuft es nicht auf einen quadcore. kennt jemand das problem? und gibt dafür eine passenden weg zur Erkenntnis?
Redis Version stable 3.2.6
System:
uname -a:
Linux zombi 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2+deb8u3 (2016-07-02) x86_64 GNU/Linux
lsb_release -a:
Distributor ID: Debian
Description: Debian GNU/Linux 8.7 (jessie)
Release: 8.7
Codename: jessie
Redis Error-Mess:
!!! WARNING The following tests failed:
*** [err]: Test replication partial resync: ok psync (diskless: yes, reconnect: 1) in tests/integration/replication-psync.tcl
Aber komischer Weise in nur einem Kern:
root@zombi /tmp/redis-stable # cd src/ && taskset -c 0 make test
Execution time of different units:
0 seconds – unit/printver
0 seconds – unit/type/incr
1 seconds – unit/scan
1 seconds – unit/keyspace
1 seconds – unit/auth
1 seconds – unit/quit
2 seconds – unit/protocol
3 seconds – unit/multi
11 seconds – unit/expire
14 seconds – unit/type/list
17 seconds – unit/type/hash
21 seconds – unit/type/string
21 seconds – unit/type/set
21 seconds – unit/other
4 seconds – integration/rdb
1 seconds – integration/logging
2 seconds – unit/pubsub
2 seconds – unit/slowlog
24 seconds – unit/type/zset
10 seconds – integration/aof
3 seconds – integration/convert-zipmap-hash-on-load
2 seconds – unit/introspection
2 seconds – unit/limits
30 seconds – unit/sort
5 seconds – unit/bitfield
7 seconds – unit/introspection-2
15 seconds – unit/bitops
38 seconds – integration/replication-2
19 seconds – unit/scripting
24 seconds – unit/maxmemory
20 seconds – unit/memefficiency
52 seconds – unit/dump
57 seconds – unit/type/list-2
57 seconds – unit/aofrw
65 seconds – integration/replication-3
46 seconds – unit/hyperloglog
88 seconds – integration/replication-4
74 seconds – unit/geo
105 seconds – unit/type/list-3
111 seconds – integration/replication-psync
126 seconds – integration/replication
106 seconds – unit/obuf-limits
\o/ All tests passed without errors!
Cleanup: may take some time… OK
da muss ich leider passen. Hier stellt der Hoster redis zur Verfügung. Ich werde mich erst demnächst damit beschäftigen, wenn ich meinen Serverumzug angehe. Aber das kann noch etwas dauern.
Fein, dein Kontakt ist im Verteiler… na wenn schon, dann komplett openSource, ich bin Fan von offenen Quelltexten, der auch veränderbar/anpassbar ist. Also sollten interessierte Leutchen auch damit machen können, was sie wollen. Bitte vorerst noch keine Trommel rühren, dass erzeugt nur Druck und es soll ja auch stabil funktionieren :o)
Hört sich cool an! Bin gespannt!
Alle Werte über 65 sind OK, zumindest sagt das google :o)
Nein erstmal ist es nur unausgegorene Spielerei, aber freigeben werde ich die Idee definitiv, genauso wie damals bei dem PEAR-Klassen.
Nur einmal muss ich die Idee bei einer Firma platzieren können, damit sich die Stunden der Entwicklung/Testen/UND wieder von Vorn auch lohnen. Man muss ja auch essen… :o) Aber wenn es OK ist, nehme ich deinen Kontakt mit in meinen Verteiler, und wenn was passiert, bekommst du die Info’s …
Cool! Meine Email ist me@0fury.de. Unter welche Lizenz willst Du das stellen? Je nachdem wenn es mal stabil (und freigegeben) ist kann ich gerne mal die Werbetrommel rühren.
hallo @all
gestern Nacht machte mein WP update auf 4.7.2, und warum soll W3 Total Cache nicht mehr funktionieren? Das kann ich nicht bestätigen. Läuft…
Ich sag mal redis ist ein sehr mächtiger Cache, Entstehungsjahr 2009, unterstützt div. Sprachen und was für mich besonders wichtig ist, dass man Redis replizieren kann, für HA-Anwendungen. Nachteil Redis unterstützt kein UNIX, Berechtigungskonzept und Verschlüsselung nur in der commercial Version erhältlich. Da meistens Webserver und Cache auf der selbem Dose laufen, kann man das verschmerzen, dass keine Verschlüsselung geht.
Auch ein Weg:
Wenn eine WP-Installation auf nur einem Server läuft, habe ich gute Werte mit der Kombi aus: dem guten altem Memcached und W3 Total Cache erzeilt. Einfach zu installieren und durch das phpmemcached-projekt ist auch die Speicherverwaltung von Memcached recht unkompliziert.
Bei mir lief es nicht mehr und hat mir mein Errorlog zugemüllt. Aber ich habe die entsprechende Textpassage gestrichen, scheint hier wohl nur eine Race Condition gewesen zu sein. Deine Kritik an Redis ist durchaus berechtigt, sind aber alles nur Vorschläge und Anregungen. Und wie so oft führen viele Wege nach Rom, eben auch deiner.
hallo christoph,
nein Kritik sollte das gar nicht sein, ich meinte nur, das man mit Redis etwas „Mit Kanonen auf Spatzen schießt“, plant man mit seinem Projekt in die Zukunft, ist Redis der bessere Ansatz, da gebe ich euch allen Recht … Fakt ist: Caching ist bei der Komplexität von WP enorm wichtig.
Man fühlt soo langsam auch bei WP in die alten Typo-Zeiten zurück versetzt, wo man nicht mehr wusste, wie man Typo noch peitschen sollte, damit es sich bewegt. :o)
Zum Glück sind die Typo-Zeiten vorbei….
WordPress wird leider immer größer und klobiger. Ich hoffe wirklich, dass es irgendwann besser wird, aber wie du passend festgestellt hast muss man Cachen. Ich nehm an, dass in einigen Jahren wohl ein Rewrite von WP auf uns zukommt. So was wie WP Calypso oder so.
An sowas ähnlichen bin ich schon dran.
Du musst wissen, ich gehöre zu einer Generation von Programmieren, als bei der PHP-Version noch (PHP/FI (PHP2)) als Versionsnummer stand. :o)
Das Backend von WP find ich gut, kann man mit Arbeiten, mich ägert eigentlich die vielen unnötig aufgeblasenen Plugins, also habe ich angefangen WP aufzubohren und mit thirdParts zu experimentieren. Auf meiner Stammzeite benutze ich nur noch WP-Backend zu adminstration und durch ein C-Script werden die Daten in das Codeigniter-Framework geblasen, ähnlich Mechnisem wie bei Ruby. Läuft stabil, aber ich habe auch keine Blog-Funktionalitäten auf meiner Stammseite. Im Blog läuft das noch nicht so gut. Ist halt nur eine Spielerei, aber bei google Insights erziele ich Werte über 94. Mit WP gleicher Unterbau um die 55.
Das klingt äußerst interessant Stellst Du deine Lösung irgendwo vor oder ist die nur für den Eigengebrauch im Hintergrund? Ich kratze bei PageSpeed Insights aktuell an den 70 bzw. 80 (Desktop), für mich ist das fürs erste okay. Mal schauen, ob ich noch iwann was tune.
Plugins wie W3 Total Cache haben bei mir erstaunlich wenig geholfen, weswegen ich auch kein solches Plugin mehr nutze.
Ich habe selbst Hand angelegt und habe mich mit Expires-Header, Kompression und der Optimierung von Grafiken usw. beschäftigt. Das hat bei mir merklich mehr gebracht als irgendwelche Plugins.
Ich habe Teile deiner erwähnten Punkte auch bei mir hier drin. Aber trotzdem musste ich noch darüber hinaus die erwähnten Maßnahmen ergreifen, damit das System flotter wird. Aber interessant zu wissen, dass es schonmal keinen goldenen Weg gibt.
Auf einem Webserver mit begrenzten Ressourcen ist WordPress vielleicht auch die falsche Wahl.
Übrigens: Das Deaktivieren der deutschen Sprachdatei halbiert den RAM-Verbrauch fast.
Das mit der Sprachdatei ist interessant, wenn auch zugegeben ulkig… Hast du da irgendwelche Quellen oder war das Eigenbeobachtung?
http://talkpress.de/artikel/deutsche-sprachdatei-wordpress-44-prozent-langsamer
danke, muss ich mir bei Gelegenheit zu Gemüte führen!
Ich dachte, dieser Umstand wäre erledigt. Habe die Sache mit dem halbiertem Ram durch Deaktivieren von der deutschen Sprachdatei selbst getestet und kann es bestätigen.