(den folgenden Text habe ich für das Blog der Webmontag Frankfurt Website geschrieben und dort zuerst veröffentlicht)


"Performance plays a major role in the success of any online venture."
- developers.google.com

Aufmerksamen Besuchern der WMFRA-Site ist es vielleicht aufgefallen: Die Website lädt schneller als voher und an einigen Details hat sich etwas verändert.

Mitte April twitterte ich aus einer Laune heraus (naja ok, ich wollte etwas angeben ;-) ) die recht guten Performance-Scores, die meine Webheimat auf Sites wie WebpageTest.org und Googles Pagespeed Insights erreichte - obwohl sie mit WordPress läuft und entgegen dem Trend bei den HeisserNeueScheissDevelopern keine vorab statisch generierte Site ist.

Daraufhin antwortete Jürgen mit einem Screenshot der Ergebnisse der wmfra.de Site - 19/100 auf Mobile und 40/100 auf Desktop bei Google's Pagespeed - mit der Anmerkung, dass er da wohl mal was machen müsste. Ich musste nicht zweimal nachdenken - hier ist meine Chance, mal "der Community" was zurückzugeben, in einem Gebiet, in dem ich mich auskenne [Disclaimer: Ich mache wasmitweb beruflich und als Co-Founder des OpenDeviceLabs Frankfurt habe ich mich jahrelang mit der Auswirkung von dicken Sites auf kleine Geräte beschäftigt], und wenn ich Jürgen da eins seiner hundertausend Päckchen mal abnehmen kann - Count me in!

So kam es also, dass ich in den letzten beiden Wochen immer mal wieder an der in die Jahre gekommenen Codebasis des eingesetzten Themes geschraubt habe und viele Kleinigkeiten auf den Stand brachte, mit dem WordPress in den aktuellsten Themes arbeitet. Überflüssiges wurde in Absprache rausgeschmissen oder deaktiviert, und in vielen kleinen Iterationen habe ich die Performance der Site verbessert, ohne dass wir an den Elefanten im Raum rangegangen wären - das Video, das gleich auf der Startseite lädt und im Hintergrund abspielt, und dessentwegen die Startseite alleine schon einige MB "schwer" ist. Allerdings war die Einbindung des Videos auch schon vorher so, dass es auf kleineren Screens nicht geladen wird - es ist bei aller Schönheit doch "nur" ein rein dekoratives Element - Besuchern mit wahrscheinlich mobilen Geräten und Tarifen bleibt so der Download erspart und schont das Datenvolumen.

Die üblichen Verdächtigen, wenn es um nicht so wirklich performante Websites geht sind:

- Bilder
- Bilder
- Bilder
- Bilder (und selbst gehostete Video- oder Audiodateien)
und dann
- Schriften (Webfonts)
- Scripte und Script/Framework-Libraries
- externe Resourcen (Scripte oder Medien)
:-))

Im Fall von WordPress kommt sehr oft (aber nicht hier beim WMFRA) dazu: So genannte "Multi Purpose Themes", die überfrachtet sind mit Features und die den Anwender*innen eine Myriade von Layoutmöglichkeiten an die Hand geben, dafür aber eine Unmenge von Markup und Scripten ins Frontend der Website schmeissen, wenn man nicht aufpasst. :-)

Auf der WMFRA Site gab es in der Hinsicht erstmal nur zwei offensichtliche Ansatzpunkte: Das Video (was aber wegen der transportierten Stimmung für den ersten Eindruck der Website wichtig ist und daher erstmal nicht entfallen sollte) und Bilder, die nicht optimal eingesetzt wurden - was gerne passiert, wenn man mit Content-Managment-Systemen arbeitet. Aus meiner Erfahrung heraus sind Bilder *die* Stelle, an der man den größten Effekt erzielen kann. Das richtige Dateiformat, die optimale Komprimierung - das sind Faktoren, die sich in Summe enorm auf die "Schwere" der Daten auswirken können. Wenn man dann noch auf moderne Möglichkeiten der Einbindung zurückgreift, wie z. B. das img-Tag mit dem srcset und sizes Attribut (siehe Responsive Images), oder das neue loading="lazy" Attribut, was gerade relativ frisch in den modernen Browsern ankommt, dann hat man schon eine Menge für eine schnellere Site getan.

Zum Glück nimmt WordPress in den neueren Versionen einem da schon einen Teil der Arbeit ab und erzeugt das "responsive Images" Markup - da aber die tatsächlich optimalen Bildgrößen stark von dem verwendetem Theme und dem jeweiligen Platz für Bilder abhängen, muss man Hand anlegen, wenn man das Optimale rausholen will. Für das frische native loading="lazy" Attribut, was dafür sorgt, dass Bilder erst in dem Moment geladen werden, wenn sie auch im Viewport des Browsers sichtbar sind, gibt es ein WordPress-Plugin der Core-Entwickler, da dieses Feature in einer der nächsten WordPress Versionen in den Core aufgenommen wird.

Die WMFRA Site nutzt zwei Google-Webfonts in unterschiedlichen Schnitten, und auch wenn aus Datenschutzgründen eine lokale Einbindung der Schriften optimaler wäre, ist aus Performance-Sicht eine Einbindung über die Google-Server besser, da diese über ihre weltweiten CDNs "näher" an dem jeweiligen Besucher sitzen und auch optimierte Fonts, die nur die tatsächlich benötigten Zeichen enthalten, ausliefern können. Auf der WMFRA Site war nur das Problem, dass ein Font doppelt angefordert wurde - und das war eine Sache, die ich bis zum Schluss nicht auflösen konnte, da es hartcodiert relativ tief in einer der Themefunktionen steckt.

Auf der Startseite war auch ein externes JavaScript eingebunden, um den Livestream darzustellen. Aufgrund der Einbindung inline im Code hat es das Laden der Site verzögert, bis die externen Server antworten und die Inhalte zurückgeben - und das machte sich bemerkbar. Da es sich dabei aber, abgesehen am Tag des aktuellen Webmontags, "nur" um einen Teaser mit der Anmerkung, dass derzeit keine Sendung läuft, handelte, habe ich dem Livestream einen eigenen Hauptmenupunkt gegeben und die Einbindung so modifiziert, dass nur am Tag des Webmontags die Scripte und der Embed-Code geladen wird und ansonsten der Hinweis und ein Link auf Livestream.Watch, die sich dankenswerterweise darum kümmern, dass man sich die Webmontage auch remote ankucken kann. Kleiner Nebeneffekt der Aktion ist, dass auf der nun neuen Inhaltsseite für den Livestream am Tag der Übertragung mehr Platz ist, als zuvor auf der Startseite. Das Video kann nun also größer dargestellt werden.

Viele Plugins, die auf der WMFRA Site zum Einsatz kommen, bringen ihre eigenen großen und kleinen Scripte mit und auch wenn es theoretisch möglich wäre, sich anhand der benötigten Funktionen eine eigene superschlanke Version zusammenzustellen, so ist doch der praktische Nutzen, gerade bei einer Site, die sich auch inhaltlich und funktional verändert, nicht wirklich gegeben. Daher bin ich nach vielen manuellen Tests und Tweaks zum Schluss dann doch auf einige WordPress-Plugins zur Optimierung von Bildern, Scripts- und Styles umgestiegen - vor allem, weil diese das Komprimieren und Zusammenfassen der Einzelscripte übernehmen und auf Wunsch auch die Dinger in den Footer der Site räumen oder mit defer Attributen versehen, um dem Browser mitzuteilen, dass er doch mit dem Laden der Inhalte fortfahren möge, solange die Scripte noch nicht geladen sind. Zusammen mit einem Caching-Plugin haben diese dann dafür gesorgt, dass die WMFRA Site aktuell mit einem PageSpeed-Score von 65/100 für mobile und 96/100 für Desktop bewertet wird und auch webpagetest.org ein grünes AAAAA ausspuckt. Ha. Geht doch!

WMFRA Site mit 96/100 google pagespeed

AAAAA Ergebnis - webpagetest.org

Wenn man dann schon bis zu den Ellbogen unter der Motorhaube der Site steckt und schraubt, kann man auch gleich noch ein paar Dinge mitmachen, die nicht direkt mit der Performance zu tun haben, aber die Pflege einerseits und die Nutzung andererseits verbessern. Für die Pflege des Archivs gibt es nun einen Shortcode, sodass man nicht mehr die Liste mit den Vorträgen und Terminen in den Jahren von Hand anlegen muss. Die Navigation haben wir zusammengefasst und umgestellt. Das Video auf der Startseite lässt sich nun auch pausieren (und ich teste gerade, ob es auf die Nutzer-Einstellung mancher Geräte "Bewegung reduzieren" hören kann und nur von selbst losläuft, wenn diese nicht gesetzt ist). Die Liste mit den Sponsorenlogos ist nun auf CSS-Grid aufgebaut und passt sich auch auf kleine Screens an. Inhalte haben nun generell mehr Platz als zuvor.

Aber bei aller Freude über eine flinke Website darf man aber nicht vergessen, dass ultimativ zählt, ob die Nutzer*innen der Site ihre Ziele erreichen können - eine "blinde" Optimierung nur nach technischen Gesichtspunkten mag einem zwar gute Scores bringen - aber manchmal sind vermeindlich "schlechte" Dinge eben doch besser, wenn sie den Besuchern helfen.

Das kann kein Test, der nur auf Zeit und Ladeverhalten schaut, erkennen.