Performance, Caching, PageSpeed: So macht man WordPress Beine

Performance-Optimierung ist in aller Munde, spätestens seit Google die Ladezeiten einer Website zum Ranking-Faktor erhoben hat. Aber was ist eigentlich Performance? Und warum brauchen Websites, die mit WordPress erstellt wurden, nicht selten extra Hilfe von speziellen Plugins, um ansprechend schnell zu laden? Das und mehr erfahren Sie in diesem ausführlichen Beitrag von Frank Bültge.

(Foto: Alternate Skate, Unsplash)

1. Einführung: Performance im Web

Performance beschreibt im Allgemeinen, wie sich eine Website in der Nutzung verhält:

  • Bauen sich ihre einzelnen Seiten zügig im Browser auf?
  • Lässt sie sich schnell navigieren?
  • Reagiert sie allgemein flüssig auf Eingaben und Klicks, fühlt sich die Nutzung angenehm und direkt an?

Während wir „harte“ Performance, nämlich Ladezeiten, in Millisekunden messen und oftmals mit technischen Mitteln recht bequem optimieren können, spielt „wahrgenommene“ Performance für den Erfolg einer Website eine mindestens genauso entscheidende Rolle.

download-iconDiesen und andere Artikel aus UPLOAD Magazin 44 herunterladen: Jetzt die E-Book-Version der Ausgabe kaufen (4,99 Euro, kostenlos für Abonnenten)

Warum ist Performance so wichtig für eine Website?

Ziel praktisch jeder öffentlich zugänglichen Website ist es, Menschen zu „halten“, bis sie eine konkrete Handlung vollzogen haben. Zum Beispiel:

  • eine Bestellung abschicken,
  • eine Telefonnummer wählen,
  • eine Telefonnummer nicht wählen, sondern stattdessen ein Kontaktformular ausfüllen,
  • auf eine Werbeanzeige klicken.

Das Vollziehen einer solchen Handlung wird Konversion genannt. Ein Mensch wechselt („konvertiert“) aus der Masse des anonymen Traffics ins Lager der engagierten Nutzer, oder gar der Kundschaft über.

Websites, die langsam laden oder anderweitig schlecht performen, schaden der Konversionsrate. Lässt nach einem Klick das antizipierte Ergebnis zu lange auf sich warten, wird der Besuch im Allgemeinen nach kurzer Zeit abgebrochen, die Website wird als nicht attraktiv abgehakt und verlassen – zurück zur Suchmaschine und zum nächsten Suchergebnis.

Apropos Suchmaschine: Google bestraft längere Ladezeiten und belohnt besser performende Seiten mit einem höheren Ranking!

Kurz: Ladezeiten und wahrgenommene Performance stehen in direktem Zusammenhang mit dem Erfolg einer Website.

Warum reagiert eine Website langsam?

Bandbreite: Je weniger „Balken“ im WLAN-Symbol, desto langsamer das Internet, desto schleppender die Ladevorgänge im Browser. 3G auf dem Smartphone sind vielerorts in Deutschland noch Realität. Selbst schlanke Webseiten brauchen dann länger für den Seitenaufbau.

Volumen: Die Summe der geladenen Dateien (HTML, Stylesheets, Skripte, Medien) wächst auf „trendig“ anmutenden Websites leider allzu schnell ins Inakzeptable.  Bei in Deutschland üblichen DSL-Verbindungen wird alles über 2 MB potenziell als störend langsam empfunden; bei langsameren mobilen Verbindungen gehen noch weniger MB als „schnell“ durch – es sei denn, es wird in Sachen wahrgenommener Performance gegengesteuert.

Requests (HTTP-Anfragen): Eine Verbindung zu einem Server aufzubauen kostet schon Zeit, bevor der Browser mit dem Herunterladen der eigentlich Daten für eine Website beginnt. Besonders Requests zu anderen Servern außerhalb der eigenen Domain, wie etwa zu Facebook, zu anderen sozialen oder Werbe-Netzwerken, oder zu Google-Diensten, können die Ladezeit empfindlich beeinflussen, weil die Antworten dieser Server nicht optimiert werden können.

Design-Fehler: Nicht selten wird Langsamkeit auf einer eigentlich zügig ladenen Webseite durch Fehler im Design künstlich erzeugt. Zwei besonders berüchtigte Beispiele für solche Anti Patterns:

  • Smooth Scroll: Angeblich „weiches“ Scrollverhalten, das sich aber überhaupt nicht weich anfühlt, sondern unnatürlich und störend, weil es das stufenlose Scrollen durch ein abgestuftes ersetzt.
  • Animierte Seitenübergänge: Beim Wechsel von einer Seite zur nächsten wird der Inhalt der neuen Seite so lange mit einer „weichen“ Animation verdeckt, bis dahinter alles vollständig geladen wurde; erst dann heißt es: Vorhang auf! Bei langsamen Verbindung wird daraus leider schnell ein nervtötendes „Wie Sie sehen, sehen Sie nichts“, denn es lässt sich noch nicht einmal abschätzen, wie weit die Inhalte bereits zugänglich sind. Wartende Nutzer, denen die Möglichkeit genommen wird, zu sehen, worauf sie eigentlich warten, geben in der Regel entnervt auf und suchen woanders weiter.

Generell kann eine ansprechend gestaltete Website nur dann ihre Wirkung entfalten, wenn sie auch gut performt. Kein noch so schönes Design, kein noch so aggressives Pop-over, kein Live-Chat-Modul kann zur Konversion eines Publikums beitragen, das schon wieder weg ist, weil eine Seite zwei Sekunden zu lange zum Laden braucht.

Allgemeine Ziele für eine schnelle Website

Noch einmal, bei der Performance-Optimierung geht es um zwei allgemeine Ziele:

  • Niedrige Ladezeit – als Faustformel bzw. Ideal dürfte ein Seitenaufbau in weniger als einer Sekunde gelten;
  • allgemein schnelle Reaktion, also keine Verzögerungen durch „Kosmetik“ oder Scripting-Fehler.

Wichtig: Eine HTML-Seite (auch eine aus WordPress generierte) kann sich, wenn sie geschickt aufgebaut wird, selbst dann schon reaktionsschnell anfühlen, wenn der Browser den tatsächlichen Ladevorgang noch gar nicht abgeschlossen hat.

Es muss also nicht notwendigerweise Abstriche in der Reichhaltigkeit der Inhalte geben, um eine Website schnell zu machen – Bilder, Videos und andere Medien sollten jedoch optimiert und in ihrer Präsentation sorgfältig durchdacht werden.

2. Schritte zur Performance-Optimierung

Serverseitige Komponenten nutzen

Eine PHP-Version mit einer 7 vor dem Punkt auf dem eigenen Webspace bedeutet nicht nur, dass ein Webhosting-Anbieter verantwortlich mit der Sicherheit seiner Kunden umgeht; PHP 7 bringt im Vergleich zu seinen Vorgängerversionen auch entscheidende Performance-Vorteile.

Von WordPress’ Seite aus gibt es mit PHP 7 keinerlei Probleme, ganz im Gegenteil, eine möglichst aktuelle PHP-Version wird sogar ausdrücklich empfohlen. Bei Plugins und Themes gibt es nur vereinzelt Probleme; sauber gewartete Erweiterungen laufen in der Regel ebenfalls fehlerfrei mit PHP 7  – im Zweifelsfall einfach die FAQ durchsuchen, oder die Anbieter direkt nach der Kompatibilität mit PHP 7 fragen.

Weitere Stichworte für Performance-Optimierung im Server-Bereich wären NGINX, Varnish und HTTP/2; die Verwendung solcher Komponenten erfordert jedoch in der Regel einiges an Fachwissen, so dass sie für Nutzer von Shared Webspaces (noch) eher selten in Frage kommen.

Seitenvolumen gering halten

Anders als mit den komplexen Zusammenhängen einer Serverkonfiguration, sieht es mit der WordPress-Installation selbst aus. Von der Auswahl des Themes und der genutzten Plugins, bis zur Gestaltung der Seiteninhalte lässt sich eigentlich fast überall Ladezeit einsparen.

„Mobile first“ beispielsweise stellt nicht nur ein Design-Modell und gleichzeitig ein wichtiges Qualitätsmerkmal für Themes dar, sondern lässt sich auch als Ansatz zur Performance-freundlichen Gestaltung von Inhalten nutzen.

Hinter dem Begriff verbirgt sich ein recht einfaches Konzept: Die Website „von klein nach groß“ zu denken, also mit der Konzeption einer mobilen Ansicht zu beginnen, nur solche Inhalte zu laden, die für das Nutzungserlebnis (und für Konversion) auf dem Smartphone maßgeblich sind, und diese Inhalte nur in einem Volumen aus WordPress abzurufen, in dem sie das jeweilige Gerät auch darstellen kann. Letzteres lässt sich gut automatisieren, beispielsweise mit sogenannten responsive images, also dem Vorhalten verschiedener Bildgrößen, aus denen sich der Browser eine passende aussuchen darf.

LazyLoad lautet der Name einer weiteren wichtigen Technologie aus der Performance-Trickkiste, wörtlich übersetzbar als „faules Laden“:

  • Per JavaScript werden die URLs von Bildern auf einer Website entfernt, bevor die Bilder abgerufen werden und durch ihr Größe (Megabytes) die Ladezeit der Seite in die Höhe treiben können.
  • Geladen und angezeigt werden zunächst nur die Bilder, die sich gerade im sichtbaren Bereich der Seite befinden. Beim Nach-unten-scrollen werden dann, je nach Scroll-Position, weitere Bilder nachgeladen und angezeigt.

Eine ähnliche Vorgehensweise gibt es für CSS- und JavaScript-Dateien. Auch solche lassen sich asynchron (async) bzw. verzögert (deferred) zum eigentlich Seitenaufbau laden, so dass das HTML-Dokument selbst schon nach ein paar hundert Millisekunden fertig dargestellt wird, während beispielsweise solche Skripte erst nachträglich abgerufen werden, die für Blog-Kommentare, für ein Newsletter-Formular, oder für Seitenstatistiken benötigt werden – also für Komponenten, die nicht gleich in den ersten Millisekunden vollständig benutzbar sein müssen.

Caching-Plugins und Plugins zur Performance-Optimierung bieten häufig Einstellungsmöglichkeiten sowohl für LazyLoad, als auch für asynchrones Scripting an. Gerade bei Letzterem ist allerdings definitiv Fachwissen aus der Webentwicklung gefragt, sonst gibt es, aufgrund nicht bedienter Abhängigkeiten im Quellcode, allzu leicht Bruch im Layout, oder bei wichtigen Funktionsmerkmalen der Website.

Ebenfalls zur Verringerung des Seitenvolumens dient das Komprimieren von statischen Dateien. Dazu gehören:

  • serverseitiges Komprimierung von statischen Dateien (HTML, CSS, JavaScript) mittels GZIP;
  • automatisiertes Entfernen von überflüssigen Leerzeichen und Zeilenumbrüchen in HTML-, CSS- und JavaScript-Dateien (Minification);
  • Komprimierung von Bilddateien mit Tools wie ImageOptim, Imagify, Optimus oder vergleichbaren.

Caching

Von Caching spricht man, wenn eine einmal geladene Ressource in einem Zwischenspeicher (Cache) vorgehalten wird, damit sie ohne eine weitere Abfrage aus der eigentlichen Quelle direkt zur Anzeige bereit steht – solange, bis sich etwas verändert hat und die Abfrage erneut gestartet werden muss, damit die Anzeige aus dem Cache die neuen Änderungen reflektiert.

Page Caching

Was einmal aus der WordPress-Datenbank als HTML-Dokument für den Browser generiert wurde, sollte in seiner statischen HTML-Form möglichst lange direkt verfügbar sein.

Normalerweise kommt die Anzeige einer WordPress-Seite im Browser ungefähr so zustande:

  • Browser sendet an Server eine URL als Anfrage;
  • Server meldet an WordPress: diese URL wird benötigt;
  • WordPress sucht in seiner Datenbank nach passenden Inhalten;
  • WordPress selbst, sowie alle möglichen Plugins und natürlich das Theme generieren aus den in der Datenbank gefundenen Inhalten ein fertiges HTML-Dokument zusammen;
  • Server schickt HTML-Dokument an Browser;
  • Browser beginnt mit dem Download aller notwendigen Dateien, sowie mit der Anzeige der Seite;
  • Browser beendet den Download, die Seite steht fertig zur Anzeige da.

Dieser vereinfacht dargestellte Vorgang benötigt auf einer durchschnittlichen WordPress-Website ungefähr zwischen 2 und 5 Sekunden – und zwar jedes einzelne Mal, wenn ein Anwender irgendwo diese spezielle URL im Browser aufruft.

Das geht natürlich einfacher:

  • Browser sendet an Server eine URL als Anfrage;
  • Server findet im Zwischenspeicher ein fertiges HTML-Dokument für diese URL;
  • Server schickt HTML-Dokument an Browser;
  • und so weiter.

Voilà, WordPress bleibt „stumm“, und die Seite steht in einem Bruchteil der Zeit fertig im Browser.

Browser Caching

Noch schneller geht es, wenn nicht nur der Server, sondern auch der Browser die einmal geladene Dateien in einem Cache zwischenspeichert. In diesem Fall kann sich der Ladevorgang nochmals signifikant verkürzen, wenn der Browser einige der herunter zu ladenden Dateien bereits in seinem eigenen lokalen Cache findet und von dort abruft. Auf diese Weise kann aus einer 2-5 Sekunden dauernden Datenbank-Abfrage ein auf wenige hundert Millisekunden eingedampfter Ladevorgang werden, und die HTML-Seite steht blitzschnell fertig im Browser-Fenster.

Sowohl für Page Caching, als auch für Browser Caching gilt: Ressourcen zu speichern, ist ziemlich einfach. Aber woher wissen Server und Browser, ob die gespeicherten Ressourcen noch aktuell sind? Vielleicht haben sich Inhalte oder Dateien seit dem letzten Aufruf geändert? Cache-Validierung ist eine extrem komplexe Aufgabe. Glücklicherweise gibt es leistungsstarke WordPress-Plugins, die den kompletten Caching-Vorgang automatisieren.

Alle Artikel bequem via E-Mail lesen!

Alle Artikel bequem via E-Mail lesen!

Jede Woche veröffentlichen wir ein bis zwei ausführliche Beiträge, geschrieben von namhaften Expertinnen und Experten. Sie erklären, geben Tipps und ordnen ein. Wenn Sie diese und weitere Artikel nicht verpassen wollen, schicken wir Sie ihnen gern per E-Mail zu – ganz bequem und in voller Länge! Im April lautet der Schwerpunkt „Das Gute im Netz“.

Mehr über die Ausgabe erfahrenJetzt E-Mail eintragen

Sparsam mit HTTP-Requests umgehen

Jedes Bild, jedes Video, jedes Like-Button, jedes Instagram-Feed, jeder Slider, jedes Formular – praktisch alles auf einer Website, was nicht Text ist, erzeugt HTTP-Anfragen zu Dateien außerhalb des HTML-Dokuments. Das ist normal und völlig in Ordnung.

HTTP-Anfragen erzeugen (Ausnahmen bestätigen die Regel) erneute Verbindungen zum Server, sowie zusätzliche Ladezeiten für das Herunterladen von Ressourcen in den Browser, damit die Webseite schlussendlich komplett angezeigt werden kann. Auch das ist normal und völlig in Ordnung.

Nicht in Ordnung, sondern kritisch wird es, wenn eine einzelne, aus WordPress generierte HTML-Seite hunderte solcher Requests abschickt und erst auf Antwort und auf den Download der entsprechenden Dateien warten muss, bis sie mit dem Laden weiterer Inhalte fortfahren kann.

Über 100 Requests pro Seite sind heutzutage leider überhaupt keine Seltenheit. Gerade bei WordPress-Websites, die per Do It Yourself erstellt und nicht von Fachleuten aus der Webentwicklung optimiert wurden, kommt schnell einiges zusammen:

  • Das Theme lädt CSS- und JavaScript-Dateien.
  • Der Slider lädt CSS- und JavaScript-Dateien, sowie ein halbes Dutzend Bilder (von denen meistens nur das erste überhaupt wahrgenommen wird).
  • Unter dem Slider werden für ein paar Teaser weitere Bilder geladen.
  • Das Newsletter-Formular-Plugin lädt CSS- und JavaScript-Dateien.
  • Das Social-Sharing-Plugin lädt CSS- und JavaScript-Dateien aus WordPress, sowie ein bis zwei Dutzend weitere von Facebook-, Instagram-, Pinterest-, Google- und Twitter-Servern (von denen niemand vorher wissen kann, wie zuverlässig sie gerade reagieren).
  • Das Ads-Plugin lädt Skripte, CSS, Bilder und Video-Anzeigen aus dem Werbe-Netzwerk.
  • Google Analytics lädt Skripte vom Google-Server.
  • Google Maps lädt weitere Skripte und Bilder vom Google-Server.
  • Und so weiter.

Wenn für ein solches Request-Gewitter Themes und Plugins zum Einsatz kommen, deren Anbieter Performance-Optimierung nicht als ein absolutes Muss auf dem Radar haben, kommt es allzu leicht zu sekunden-langen Verzögerungen. Starten, warten, Ende im Garten. Besucher verlassen die Seite, Konversion bleibt aus.

Auch hier können Performance- und Caching-Plugins helfen, indem sie beispielsweise automatisiert mehrere JavaScript- oder CSS-Dateien in jeweils einer größeren Datei zusammenfassen (Concatenation). Dadurch lässt sich zumindest die Anzahl der WordPress-internen HTTP-Anfragen verringern. Externe Requests zu Google, Facebook usw. bleiben aber ein Problem. Die angefragten Dateien liegen auf Servern, über die niemand anders Kontrolle hat, als eben Google, Facebook usw. Solche Requests können, wo es möglich ist, nur durch asynchrones Laden daran gehindert werden, den Seitenaufbau zu verlangsamen.

Sie möchten noch tiefer in die Materie einsteigen? Dann lesen Sie ergänzend dazu Torben Leuschners Artikel „Die wichtigsten Handgriffe für eine schnelle Website“. Dort geht er auf einige der hier genannten Themen genauer ein.

3. WordPress-Themes: Flexibilität mit Konsequenzen

Tausende WordPress-Themes, teils kostenfrei verfügbar, teils für relativ kleines Geld nutzbar – wie können Anwender ohne Programmierkenntnisse eine informierte Entscheidung für ein passendes Theme treffen? Eine nützliche Richtschnur kann vielleicht die grobe Unterscheidung von zwei Theme-Typen bilden: Mehrzweck-Themes (multi-purpose themes) und Nischen-Themes (niche themes).

Nischen-Themes liefern fertige Designs für einen bestimmten Anwendungsfall, zum Beispiel eine Restaurant-Website, oder ein Reise-Blog. Sie lassen sich in der Regel leicht personalisieren und bieten einen auf das konkrete Thema zugeschnittenen Funktions- und Design-Umfang. Gut gemachte Nischen-Themes entsprechen daher vielfach einem 4S-Standard: schlank, sauber, sicher, schnell – ein Qualitätsmerkmal, dem Mehrzweck-Themes so gut wie nie genügen, einfach weil sie nicht einem speziellen, klar definierten Zweck dienen, sondern ein möglichst breites Anwendungsspektrum abdecken sollen.

Mehrzweck-Themes werden mit einem einzigen Versprechen hergestellt und vermarktet: Menschen, die nicht unbedingt wissen, wie man eine Website baut, in die Lage zu versetzen, eine Website zu bauen. Aus der Performance-Perspektive entsteht aus dem Fokus auf Flexibilität heraus allzu leicht ein Konflikt. Wenn Flexibilität in der Nutzbarkeit für die Anbieter und Anwender von Mehrzweck-Themes gleichermaßen oberste Priorität hat, kommen Zugänglichkeit und Performance der letztlich erstellten Websites zwangsläufig an zweiter oder dritter Stelle.

Derlei Zusammenhänge mit einzubeziehen, kann unter Umständen dabei helfen, die eigenen Erwartungen an die Performance eines Themes zu validieren.

4. WordPress-Plugins: Qualität, nicht Quantität entscheidet

Beim Thema Performance konkrete Empfehlungen für oder gegen bestimmte Plugins aussprechen zu wollen, wäre angesichts der Zehntausenden verfügbarer WordPress-Plugins in mancherlei Hinsicht schlicht vermessen. Stattdessen wollen wir lieber mit einem der verbreitetsten Irrtümer über Plugins aufräumen:

Viele Plugins machen eine WordPress-Website nicht per se langsamer.

Theoretisch ist die Anzahl der verwendeten Plugins für die Performance einer WordPress-Website völlig egal, solange jedes einzelne Plugin sauber performt. Es gibt keine höhere Ladezeit, die allein durch die Anzahl von Plugins verursacht würde.

Rein statistisch betrachtet ist an dem Vorurteil aber leider doch etwas dran: Für Anwender ohne Code-Kompetenz steigt mit der Anzahl der verwendeten Plugins potenziell das Risiko, ein „faules Ei“ im Setup zu haben. Oder anders gesagt: Beim Thema Performance trennt sich ziemlich sicher die Spreu vom Weizen.

Zwar kann man mit WordPress sicherlich eine Website als Do-It-Yourself-Projekt starten. Der WordPress-Markt gleicht in vielerlei Hinsicht einem Lebensmittel-Discounter: Es gibt praktisch alles, was man im Haushalt und für den Kühlschrank benötigt, man braucht sich nur den Einkaufswagen voll zu packen.

Der Konsum maschinell verarbeiteter Fertignahrung fordert allerdings auf die Dauer einen Tribut. Wer sich lange genug von Junk ernährt, wird irgendwann Konsequenzen in der eigenen physischen Performance feststellen: Gewichtszunahme, Trägheit, Anfälligkeit für körperliche und seelische Beschwerden, erhöhtes Krankheitsrisiko. Fitness ist an diesem Punkt erst wieder mit einer vernünftigen Diät, gesunder körperliche Bewegung und letztlich einer Änderung des eigenen Konsumverhaltens zu erreichen.

Einer WordPress-Installation geht es nicht anders, wenn sie ohne Augenmerk für Qualität und Performance mit Plugins vollgestopft wird. Und wer dann am Ende erwartet, Performance-Optimierung einzig und allein mit der Installation eines Caching-Plugins abhaken zu können, wird ziemlich sicher enttäuscht werden: Caching-Plugins können viel, aber sie können natürlich nicht hexen. 200% schnellere Ladezeit mögen 200% schnellere Ladezeit sein – entscheidend bleibt aber am Ende die Frage: 200% von was?

Um die Ladezeiten einer adipösen WordPress-Website in den Griff zu bekommen, hilft häufig nur eine professionelle Code-Analyse und der Umbau des Setups mit Blick auf Plugin-Performance.

5. Das PageSpeed-Paradox

Ein Artikel über Performance-Optimierung wäre nicht komplett, wenn er Tools wie Google PageSpeed Insights, GT Metrix, YSlow und ähnliche unerwähnt ließe – und die teils absurden Mythen, die sich um die Beurteilung einer Website durch solche Dienste ranken.

Der vielleicht wichtigste Merksatz für die Nutzung von PageSpeed Insights und Konsorten könnte lauten: PageSpeed ist nicht dasselbe wie page speed.

  • PageSpeed Insights misst keine Ladezeiten, sondern nur einen von Google willkürlich festgelegten „Performance-Grad“ für eine Website. Dieser richtet sich ausschließlich nach dem Grad der Übereinstimmung mit einem speziellen Kriterienkatalog – also einer Art internen Checkliste des Tools.
  • Googles Such-Algorithmen berücksichtigen aber nicht den PageSpeed-Punktestand für das Ranking einer Website, sondern dafür ziehen sie ausschließlich die Ladezeit heran – die auf einem PageSpeed-Report nicht einmal erscheint.

Die Empfehlungen von PageSpeed Insights können, wenn sie mit dem entsprechenden fachlichen Hintergrundwissen gelesen werden, dabei helfen, eine Website schneller zu machen. Bei Anwendern ohne spezielle Fachkenntnisse stiften sie jedoch allzu häufig Verwirrung und resultieren in Stunden verschwendeter Zeit auf der Suche nach „Fehlern“, die gar keine sind.

Ein typisches Beispiel für das PageSpeed-Paradox ist die Beschwerde des Tools über nicht aktives Browser Caching. Beim näheren Hinsehen kommt nicht selten heraus, dass die Dateien, für die PageSpeed fehlendes Browser-Caching anmahnt, gar nicht vom eigenen Server geladen werden, sondern etwa von Google oder Facebook. Tja, wo war jetzt noch gleich die Telefonnummer von Google? Man möge doch bitte mal Browser-Caching für das Analytics-Skript aktivieren …

Ähnlich irreführend kann die Empfehlung bezüglich „CSS und JavaScript, die das Rendering blockieren“ ausfallen. Eine langsame WordPress-Website hat in der Regel einen Haufen Probleme mit einem viel zu hohen Seitenvolumen aufgrund arbiträrer Inhaltsgestaltung, trägen AJAX-Requests und zu vielen externen Ressourcen. Render-blocking JavaScript gehört für Code-Laien in der langen Liste sinnvoller Maßnahmen zur Performance-Optimierung ganz ans Ende.

6. Performance testen mit Pingdom Tools

Pingdom Tools bieten einen gesunden Kompromiss zwischen anspruchsvollen Performance-Tests und angenehmer Usability. Im folgenden eine Checkliste für das Testen der eigenen Website:

  • Passenden Server-Standort wählen. (Für deutschsprachige Websites: Schweden, weil es von den angebotenen Standorten am nächsten an Deutschland, Österreich und der Schweiz liegt.)
  • Auf Ladezeiten fokussieren!
    Den angezeigte Punktestand (kommt von PageSpeed Insights) zunächst außen vor lassen; 60/100 muss nicht unbedingt schlecht und 90/100 nicht automatisch gut sein.
  • Für eine detaillierte Analyse zur Tabellen „File requests“ hinunter scrollen und nach „Load time“ sortieren.
  • Langsame Requests identifizieren und wenn möglich beseitigen.
  • Wichtig: Immer mehrere Tests hintereinander vom selben Server-Standort ausführen, um einen repräsentativen Durchschnittswert zu erhalten.

Fazit

Performance-Optimierung für WordPress fängt bei der Wahl des Themes und der verwendeten Plugins für eine Website an. Die Gestaltung und Konzeption der Inhalte spielt eine zentrale Rolle – wer in Kriterien für Konversion denkt, anstatt blind Trends für Slider oder großformatigen Hintergrund-Videos zu folgen, hat schon halb gewonnen.

Spezielle Caching-Plugins können bei der Automatisierung von Standard-Maßnahmen wie Page Caching, Browser Caching, Minification und Concatenation, LazyLoad und asynchroner Skript-Abfragen helfen und einen „Boost“ der Ladezeiten unterstützen. Ihre optimierende Wirkung kann sich jedoch nur relativ zur ursprünglichen Performance einer Website entfalten.

Tipps zum Weiterlesen

Wer jetzt auf den Geschmack gekommen ist und noch mehr erfahren möchte, dem sei Torben Leuschners UPLOAD-Artikel rund um eine schnelle Website empfohlen. Darin u.a.: http-Requests reduzieren; durch serverseitige Komprimierung etliche KB einsparen; Dateien im Browser-Cache behalten; Bilder komprimieren, passend skalieren und Dateiformat hinterfragen; HTML-, CSS- und Javascript- Dateien reduzieren; CSS- und Javascript-Dateien zusammenlegen; Antwortzeit des Servers reduzieren.

Weitere Artikel zu:

Artikel vom 13. März 2017