Google PageSpeed Insights Optimierungen
Vor ein paar Wochen kam das Coopers Winsen auf mich zu und bat mich, ihre Website einmal hinsichtlich Seitenladegeschwindigkeit kritisch zu prüfen und zu optimieren. Insbesondere die mobile Variante sollte von (im Mittel) 55 Punkten auf "grün" steigen. Da die Web Vitals in den gängigen Suchmaschinen eine immer größer werdende Rolle hinsichtlich des Rankings spielen, ist es heutzutage umso wichtiger, dass eine Website nicht nur semantisch korrekt ist, sondern dem Besucher der Seite die angeforderten Inhalte schnell und einfach präsentiert.
TYPO3 (das Content-Management-System hinter der Coopers Winsen Website) hat zwar diverse Boardmittel, mit denen sich ein paar Anforderungen bereits gut lösen lassen, doch gerade für die letzten, entscheidenden Punkte muss man sich die Hände ganz schön schmutzig machen.
Nach einer ersten, oberflächlichen Analyse kam ich unter anderem zu folgenden Bereichen, die man optimieren konnte:
- Nicht sofort benötigtes CSS später laden
- Scripte komprimieren & aufräumen
- Font/Text-Ladevorgang verbessern
- Scripte asynchron laden
Nicht sofort benötigtes CSS später laden
Der Begriff "above the fold" beschreibt alle Inhalte, die man auf den ersten Blick sieht, d. h. mit denen der Benutzer interagieren kann, ohne scrollen zu müssen. Google empfiehlt, für diese Inhalte eine gesonderte CSS-Datei (oder besser noch inline-Styles) zu verwenden. Da sich eine eigene CSS-Datei jedoch besser cachen (und somit die Seitenladegeschwindigkeit bei zukünftigen Aufrufen verbessern) lässt, habe ich mich dafür entschieden.
Alle anderen Styles werden mit einer onload-Methode über JavaScript gesteuert nachgeladen. Grundsätzlich habe ich anfänglich von der Idee, Styles per JavaScript nachzuladen, nicht viel gehalten. Es scheint jedoch die empfohlene Praxis zu sein.
Mein erster Gedanke, die Styles erst am Ende vor dem schließenden </body>-Tag zu laden, sind nämlich nicht w3c-kompatibel, da das <style>-Element ausschließlich im <head> vorkommen darf.
Scripte komprimieren & aufräumen
Um die Scripte zu komprimieren und aufzuräumen, habe ich mir eine kleine Build-Pipeline mit gulp.js aufgebaut. Ein netter Nebeneffekt dabei ist, dass ich modernes JavaScript verwenden und mir so diverse Codezeilen vereinfachen kann. Die Vorteile überwiegen, auch wenn ich jetzt für jedes Release erst einmal ein "npm run build" abfeuern und die generierten Dateien mit ins git Repository pushen muss, da ich beim Coopers (noch) keine Continuous Delivery Pipeline angelegt habe. Die CSS-Dateien werden übrigens auch gleich mit optimiert.
Font/Text-Ladevorgang verbessern
Es gibt seit einiger Zeit die Möglichkeit, Anfragen an andere Server "vorab" zu senden, damit die spätere Kommunikation schneller erfolgt und Ressourcen zügiger abgefragt werden können. Das gilt praktischerweise auch für Daten, die vom eigenen Server abgerufen werden. So "prefetche" ich jetzt die Schriftarten und umgehe das Zucken des Inhalts, wenn eine Schriftart erst später dynamisch nachgeladen wird.
Scripte asynchron laden
Das war der Punkt, bei dem ich am meisten geschwitzt habe. Mit Hilfe von RequireJS war geplant, dass ich JavaScript, welches ich nicht global auf jeder Seite benötige, dynamisch nachlade. Gerade bei den verwendeten GridElements ist das eine super Sache, vorausgesetzt, man hat die config von RequireJS richtig eingebunden. Im Endeffekt habe ich dann so ziemlich alles an JavaScript ausgelagert und ziehe es "auf Anforderung" nach. Das hat super funktioniert und die Darstellung der Inhalte enorm beschleunigt, da die Scripte nun kein "render blocking" mehr verursacht haben.
Largest Contentful Paint
Noch so ein dicker Brummer. Bei jedem Element, welches auf der Seite gerendert wird, wird geprüft, ob es "größer" (Breite/Höhe) ist, als das vorige bisher größte Element. Ist dies der Fall, wird der Zeiger auf das größte Element auf das aktuelle Element gesetzt. So kann es sich ganz schön hinziehen und das Ergebnis steht erst fest, wenn das große Headerbild auf der Startseite angezeigt wird.
Naturgemäß sind dies oft (verhältnismäßig) große Bilder mit 100-300 KB, manchmal auch noch größer, abhängig von ihrer Auflösung/Kompression. Was hat geholfen? Ein Bild, welches ich als Platzhalter (ebenfalls mit "prefetch") lade, bei welchem die Kompression auf "hoch" gestellt ist und die Qualität zwar etwas gelitten hat, dies jedoch nicht weiter auffällt, da ich einen Gaussian-Blur-Filter draufgesetzt habe. Dieses Bild wird "ganz schnell" oben sofort angezeigt und somit steht der Zeiger des "Largest Contentful Paint" bereits frühzeitig fest. Alle Bilder, die danach noch geladen werden, sind zwar speicherplatztechnisch größer, doch zählt hier nur die Breite/Höhe, mit welcher das Element auf der Website im Endeffekt angezeigt wird. Toll!
Das Ergebnis
Mittlerweile sind wir (im Mittel) bei 93 Punkten angelangt. Das ist eine super Steigerung.
Ich habe bei dieser Aufgabe viel über die Web Vitals gelernt und freue mich auf zukünftige Projekte, bei denen die Optimierungen für Google PageSpeed Insights eine Rolle spielen. Dazulernen kann man immer etwas, auch wenn man schon über 30 Jahre Informatiker ist. Grüße gehen raus 🙃
