WordPress: Plugins und Performance – ein Widerspruch?

Waterfall First View
Nachdem ich mal wieder ein paar Stunden in die Performance-Optimierung der Webseite zu meinen Science-Fiction Thriller Der Kristall gesteckt habe, will ich die Erfahrungen, ein paar Tipps und Tricks und natürlich auch das Ergebnis gerne teilen.

Mit WordPress Webseiten bauen ist einfach. Man sucht sich ein Theme aus, das den eigenen Vorstellungen von Design und Layout weitestgehend entspricht, und kann sofort loslegen. Das ein oder andere Plugin ergänzt Funktionen, die dem Theme fehlen oder erweitert die Admin-Arbeitsumgebung um nützliche Helfer. Aber genau da liegt auch die Achillesferse, denn weil dies so leicht geht, greift man schnell zu und ignoriert die Konsequenzen. Die meisten Plugins fügen weitere CSS- und Javascript-Elemente hinzu, aber so gut wie immer werden diese zusätzlichen Skripte nicht perfekt und erst recht nicht selektiv in den HTML-Code integriert. Das drückt auf die Performance.

Ich gebe zu, ich bin Perfektionist und ich spiele gern. Bei mir haben sich daher über die Zeit über 100 Plugins angesammelt. Aber ich möchte auf keines verzichten, auch wenn ich von manchen Plugins nur eine einzelne Funktion aus einer Vielzahl nutze. Best of Bread Ansatz eben…

Da die Performance einer WordPress-Seite mit so vielen aktiven Plugins natürlich unterirdisch ist, habe ich schon sehr früh ein Caching-Plugin einsetzt, in diesem Fall WP Fastest Cache. Das Ergebnis konnte sich sehen lassen. Ein Google Page Speed Index von durchschnittlich 90 und Seitenladezeiten (TTI = Time to Interaction) von 2,5 – 3,5 Sekunden – beides durchschnittliche Werte.

Nun hatte ich in den letzten Tagen mal wieder Zeit, an der Webseite zu schrauben und habe ein paar neue Funktionen integriert, u. a. kann man sich jetzt die Leseproben aus dem Roman vorlesen lassen. Und ich habe mir auch die Performance der Seiten noch mal vorgenommen, denn in den Reports von Google Pagespeed Index und Webpagetest war doch noch so einiges Potenzial erkennbar.

Eine genauere Analyse der Messergebnisse und diverser Wasserfall-Diagramme von webpagetest.org ergab mehrere Handlungsfelder:

  1. Zu viel Code above the fold, insbesondere Javascript. Erschwerend kam hinzu, dass die vielen Plugins ihren Code auf jeder Seite auswerfen, auch wenn die jeweilige Funktion dort gar nicht gebraucht wird.
  2. Extern eingebundene Inhalte wurden nicht richtig gecached.
  3. Unzählige Elemente, die nachgeladen werden mussten, und die das Rendern blockierten.
  4. Jede Menge Code für WordPress-Funktionen, die gar nicht genutzt wurden.

Zeit also für einen Hausputz. Allerdings war ich mit den Mitteln eines reinen Caching Plugins hier am Ende – es mussten also weitere Plugins her. Das klingt erst mal wie ein Widerspruch, ist es aber nicht. Schauen wir uns die einzelnen Schritte der Reihe nach an:

Überflüssige WordPress-Funktionen eliminieren

Hierzu eignen sich zwei Plugins hervorragend – wp_head() cleaner und Clearfy. Beide stellen eine Reihe von Optionen zur Verfügung, mit denen man Elemente aus dem HTML-Code, insbesondere aus dem Header entfernen kann. Es gibt ein paar Überschneidungen, aber gerade die Kombination aus beiden Tools ergibt das perfekte Ergebnis. Hier die wichtigsten Einstellungen (Klicken zum Vergrößern):

wp_head Cleaner Settings
Clearfy Settings

Eingebettete Bilder lokal cachen

Wie so ziemlich jeder in der Blogging-Szene nutze ich auch schon mal das ein oder andere gemeinfreie oder unter CC-Lizenz stehende Bild aus dem Netz. In der Vergangenheit habe ich aus Bequemlichkeit einfach die entsprechende URL in meinen Beiträgen eingebunden. Und nicht selten meckert das Google Page Speed Tool dann fehlende Cache Header an. Hier hilft ein altes Plugin des WordPress Erfinders M. Mullenweg, dass remote eingebundene Bilder lokal cached. So können diese dann auch mit diesem Plugin von TinyPNG komprimiert und in das CDN hochgeladen werden, das ich auf meiner Seite für Bilder nutze.

CSS und Javascript selektiv ausspielen

Dies ist der größte Hebel, wenn man mit vielen Plugins jongliert und gleichzeitig performante Seiten haben möchte. Das Plugin WP Asset Cleanup Lite erlaubt es, einzelne Seiten vom Ballast der Plugins zu bereinigen, deren Funktionen dort nicht genutzt werden. Das macht ein wenig Arbeit, aber es lohnt sich.

Asset Cleanup Rules
Asset Cleanup Setting

CSS und Javascript optimieren

Bei meinen Analysen habe ich festgestellt, dass WP Fastest Cache zwar einen exzellenten Job beim Cachen macht, aber dass es jedoch für das Verkleinern und Zusammenfassen von CSS und JS bessere Plugins gibt. Ich setze auch hier wieder auf eine Kombination. WP Super Minify kümmert sich um das Komprimieren von Javascript und Autoptimize verkleinert den CSS-Code und führt alles zusammen. Zu erwähnen ist hier, dass ich den CSS-Code komplett inline ausspielen lasse und sämtliches Javascript, inkl. jQuery, in einer großen Javascript-Datei zusammenfassen und verzögert laden lasse. Wie schon gesagt, WP Fastest Cache managed nun nur noch den Cache und fügt Kompression und Cache-Information für den Browser hinzu. Die beiden folgenden Abbildungen zeigen die gewählten Einstellungen für Autoptimize:

Autoptimize Settings

Das reicht aber leider noch nicht, denn viele Plugins fügen Javascript-Code im Header ein, ein absolutes No-Go. Insbesondere das fette jQuery wird sogar von WordPress selber an dieser Stelle ausgespielt. An dieser Stelle müssen wir also etwas tiefer eingreifen und die Skripte in den Footer umhängen, was sich mit ein wenig PHP-Code in der functions.php-Datei des Child-Themes einfach bewerkstelligen lässt:

if (! is_admin()) {
    remove_action('wp_head', 'wp_print_scripts');
    remove_action('wp_head', 'wp_print_head_scripts', 9);
    add_action('wp_footer', 'wp_print_scripts', 1);
    add_action('wp_footer', 'wp_print_head_scripts', 1);
}


Das Ergebnis kann sich sehen lassen. Der Google Page Speed Index liegt nun über alle Seiten im Durchschnitt bei 99 für Desktop und bei 92 für Mobile. Viele Seiten erreichen nun die magischen 100 von 100 Punkten.
Google Pagespeed Index
Die Ladezeit der umfangreichsten Seite, der Homepage, ist weit unter eine Sekunde gefallen. Der gesamte Javascript Code wird erst ausgeführt, nachdem die Seite vollständig geladen und dargestellt ist. Die Time to first Interaction liegt bei den meisten Seiten ebenfalls unter einer Sekunde.
Pingdom Result
Und – last but not least – der Browser-Cache wird nun effektiv genutzt, wie das Wasserfall-Diagramm für ein erneutes Laden einer beliebigen Seite zeigt.
Waterfall Second View


Das Video der Ladesequenz für die Startseite, aufgenommen von Webpagetest:


Nachtrag: Natürlich habe ich auch den Google Pagespeed Index und die Ladezeit dieses Beitrags gemessen. 100/100 sowohl für Web wie auch für Mobile und eine Ladezeit von 528 Millisekunden. Mission accomplished…

Like
Like Love Haha Wow Sad Angry

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.