Erstellt von Nico Martin
Slides: http://slides.com/nicomartin/webperformance-wpbern/
Wenn wir in diesem Kontext von «Performance» sprechen, geht es um die Ladezeit der Seite vom Absenden der URL bis zur kompletten Ansicht der Webseite. Ein weiterer Aspekt der Performance wäre die Verarbeitung von Animationen im Browser. Dieser war jedoch nicht Teil dieses Treffens.
Grundsätzlich folgt ein Ladeprozess einer dynamischen HTML-Webseite immer demselben Schema:
- Der Browser (Client) startet eine Anfrage / schickt Daten an einen Server
- Der Server verarbeitet diese Daten und stellt eine Antwort zusammen
- Der Server schickt die Antwort als HTML DOM zurück
- Der Client liest das Dokument und startet je nach Inhalt weitere Anfragen für zusätzliche Dateien (Assets).
Im oben beschriebenen Ablauf gibt es zwei «Nadelöhre», die wir nun genauer anschauen.
Verarbeitung auf dem Server
Je nach Komplexität der Anwendung und Leistung des Servers kann diese Verarbeitung sehr lange dauern. Da werden z. B. Inhalte aus einer Datenbank z. T. sogar von anderen URLs geladen. Der einfachste Schritt wäre dabei, bereits gemachte Prozesse zu speichern (Server-Caching). Hier hilft zum Beispiel WP Super Cache, W3 Total Cache oder Cachify.
Viel wichtiger wäre jedoch ein schneller Server, der z. B. auch php7 unterstützt.
Assets
Assets sind in dem Sinne zusätzliche Dateien, die der Browser lädt, um die Seite darzustellen. Das sind in der Regel Bilder, JavaScript- und CSS-Dateien:
JavaScript / CSS
Die erste Frage, die sich ein Entwickler immer stellen sollte, ist: «Brauche ich das?»
Wenn man die Features, die diese Datei bietet, nicht nutzt, dann muss sie auch nicht eingebunden werden. Das ist i. d. R. schon der erste Punkt, an dem viele WP-Themes scheitern. Sie beinhalten zu viele ungenutzte Features.
Wenn man die Datei doch benötigt, dann empfiehlt sich ein minify (z. B. https://jscompress.com/ oder noch besser automatisch beim Entwickeln). Bei einer grossen Bibliothek wie jQuery 3.1.1 spare ich dadurch über 65% an Daten!
Ein weiterer wichtiger Punkt ist der Ladeprozess. Dateien, die in den <head> der Seite eingebunden werden, blockieren das Rendern der Seite. Deshalb macht es Sinn, JavaScript Dateien immer ganz am Ende der Seite einzubinden.
Autoptimize bringt viele Features mit, sollte jedoch nur eingesetzt werden, wenn man sich der Sache sicher ist.
Bilder
Der wichtigste Punkt im ganzen Performance-Prozess ist jedoch die Bildoptimierung.
- Bildgrösse an die effektive Grösse auf der Webseite anpassen (responsive Images)
- So weit wie möglich verlustlos komprimieren
- jpeg anstelle von png verwenden
- progressive JPEG anstelle von Standard (baseline) JPEG verwenden
Hierbei kann ich z. B. den EWWW Image Optimizer empfehlen.
progressive JPEG
Während ein baseline JPEG von oben nach unten geladen wird, lädt progressive JPEG Layer für Layer. Das heisst, als Erstes wird eine sehr schlechte Version des Bildes geladen und erst nach und nach kommen neue Layer hinzu. Das hat den Vorteil, dass der User nach wenigen Millisekunden bereits ein Bild sieht und erst später die Qualität nachgeladen wird. Ich habe das hier kurz demonstriert:
baseline JPEG: https://performancedemo.vir2al.ch/
progressive JPEG: https://performancedemo.vir2al.ch/?type=progressive
PageSpeed Insights
Zuguter Letzt gibt es einen einfachen Weg, die Performance einer Seite zu messen (oder zumindest eine Vorstellung zu bekommen). Da die Performance nicht zuletzt auch SEO-relevant ist, stellt Google ein Tool zur Verfügung:
https://developers.google.com/speed/pagespeed/insights/
Dieses kann eine Hilfe sein, sollte aber nicht als einziger Massstab angesehen werden. Denn wie es Paul Bakaus selber sagt: «Nobody cares about how fast your site is, only how fast it feels». (https://fronteers.nl/congres/2016-spring/sessions/the-illusion-of-speed-by-paul-bakaus)
Und der arbeitet immerhin für Google an deren Chrome Browser.
Das interessante an PageSpeed Insights ist, dass es nicht eine einzige relevante Kennzahl für tatsächliche Performance liefert. Ladezeiten bleiben komplett außen vor. Das x/100-Punktesystem trifft lediglich Aussagen darüber, welche Empfehlungen aus einem bestimmten Katalog wie gut umgesetzt wurden. Ob die Seite deswegen schneller läuft, misst das Tool nicht.
Demzufolge spielt das PageSpeed-Ergebnis auch keine Rolle fürs Google-Ranking. Der Algorithmus schert sich nicht um Punkte, sondern lediglich um Millisekunden – und für das „Gefühl“ des menschlichen Publikums sind Ladezeiten ebenfalls ein (wenn nicht das) Hauptkriterium.
Daher sollten Ergebnisse von PageSpeed Insights, GT Metrix u.a. unter Vorbehalt betrachtet werden. Ist die Website schnell, kann einem der „Performance Grade“ getrost gestohlen bleiben.
Hallo Caspar,
welche hoher Besuch, herzlich willkommen 😉
Danke für den ergänzenden Kommentar, den ich voll unterschreibe. Deshalb nutze ich zur Messung der Ladezeiten immer die Pingdom Tools, was laut Heiko die genaueste Messung sei.
Gruß
Gerd