WordPress Beine machen

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)

 

Christoph

Programmierer. Linuxuser. Blogger. Macher vom Distrochooser. Auch unter me@0fury.de erreichbar (PGP).

Das könnte Dich auch interessieren...

20 Antworten

  1. tux sagt:

    Auf einem Webserver mit begrenzten Ressourcen ist WordPress vielleicht auch die falsche Wahl.

    Übrigens: Das Deaktivieren der deutschen Sprachdatei halbiert den RAM-Verbrauch fast.

  2. Fryboyter sagt:

    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.

    • Christoph sagt:

      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.

  3. Steffen sagt:

    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.

    • Christoph sagt:

      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.

      • Steffen sagt:

        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….

        • Christoph sagt:

          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.

          • Steffen sagt:

            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.

          • Christoph sagt:

            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.

  4. Steffen sagt:

    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 …

  5. Steffen sagt:

    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)

  6. Steffen sagt:

    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

    • Christoph sagt:

      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.

  7. Jens sagt:

    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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.