Auf dem WordCamp Nürnberg hat Jan Thiel einen tollen Vortrag zum Theme Performance gehalten: WordPress Performance Mythbuster. Den Vortrag könnt Ihr Euch hier auf wordpress.tv anschauen.

Performance ist ein wichtiges Thema, nicht nur seit Google ein Auge drauf hat. Je langsamer eine Seite lädt, desto schlechter ist die User Experience. Jede Millisekunde zählt, bei mobilen Geräten umso mehr.

Spannend fand ich, wie Jan herausgearbeitet hat, wo denn der Flaschenhals bei den Ladezeiten tatsächlich liegt. Vorsicht Spoiler: Weder die Server-CPU noch der PHP-Code vom WordPress-Core sind hier die Bremse, der PHP Code von Themes und Plugins ist es, der aufs Tempo drückt.

Was logischerweise bedeutet, dass noch’n Plugin Eure Seite nicht unbedingt schneller macht. Auch wenn Performance-Optimierung draufsteht. Ausnahmen bestätigen die Regel.

Das Experiment

Ich hab mir mal zwei Sachen vorgenommen, die Jan in seinem Vortrag erwähnt hat, mit denen man der Netzialisten-Seite Beine machen kann. Ich hab dazu das Google Page Speed Tool genutzt, obwohl ich ein etwas gespaltenes Verhältnis dazu habe: Die Angaben dort muss man mit Vorsicht geniessen und immer die Verhältnismäßigkeit im Auge behalten. Beispiel: Man kann schon „Punktabzug“ kriegen, wenn ein einziges 32KB-Bild nicht optimiert ist.

Die beiden Techniken, die ich mir angeschaut habe, sind:

  1. gzip -Komprimierung
  2. Browser-Caching

1. gzip aktivieren

Mit Gzip werden Dateien komprimiert und dekomprimiert.
Das Problem: Die Einstellungen dafür passieren in der htaccess-Datei. Und mit nichts kann man seine Seite so schnell und so gründlich kaputt machen wie mit einem missglückten Eingriff in die htaccess-Datei.
Also: Bitte Vorsicht beim Nachmachen, nicht gerade am laufenden Online-Shop Eures wichtigsten Kunden ausprobieren. Im Zweifelsfall lieber den freundlichen Hoster machen lassen.

Die Einstellungen für die htaccess sind ausserdem je nach Server-Version (Apache, Nginx etc.) unterschiedlich. Eine gute Übersicht habe ich bei GTMetrix gefunden.

Meine htaccess hat die gzip-Komprimierung ohne Unfall überstanden.
Google Page Speed hat die Komprimierung mit stolzen 14 Punkten honoriert:

2. Browser-Caching einsetzen

Eine zweite Massnahme, die laut Jan eine große Wirkung hat, ist der Einsatz von Caching-Techniken. Das Ziel dabei ist, die Seiten nicht mehr aus dem PHP rendern zu lassen (das kostet Zeit), sondern als HTML-Seiten zwischenzuspeichern und den schlanken HTML-Code auszuliefern.

Web-Speed-Tools beziehen bei dem Stichwort „Cache“ aber meist auf etwas anderes, nämlich das Browser-Caching, also auf den Arbeitsspeicher des Browsers. Auch das steuert man auf dem Server über einen Eintrag in die htaccess-Datei. Also Vorsicht beim Nachmachen.
Im Prinzip teilt man dem Browser mit, welche Daten er speichern soll und wann er wieder nach geänderten Daten gucken soll. Ein Beispiel für eine htaccess mit aktiviertem Browser-Cache gibt es bei WPRocket.

Für den aktivierten Browsercache schenkt mir Google Page Speed immerhin noch einmal 2 Punkte.

Google Font API

Eine Sache, die ich in letzter Zeit mehr und mehr mache, ist Schriften auf dem eigenen Server nachzuhalten und nicht über die Google API zu laden.
Das schlägt Google Page Speed zwar nicht vor, aber meiner Erfahrung nach ist das Warten auf die Google API eine der häufigsten (und lästigsten) Kunstpausen, die mir beim Aufrufen von Webseiten unterkommen.