Blog

Sportler*innen auf einer Laufbahn
Foto: © Steven Lelham/unsplash.com

Blog

Website zu lang­sam? Diese Perfor­mance-Tricks helfen

Wer Besucher*innen warten lĂ€sst, verliert potenzielle Kundschaft. Eine schnelle Website wirkt sich dagegen positiv auf die Absprungrate und die Verweildauer auf der Seite aus — und damit auch positiv auf Ihr GeschĂ€ft. Die Geschwindigkeit ist ein QualitĂ€tsmerkmal einer Website, sie erhöht die Usability und wirkt sich als »PageSpeed« auch auf das Ranking bei Google aus. Diese sechs helfenden Performance-Tricks fĂŒr eine schnelle Website kann man indirekt auch als Maßnahmen zur Suchmaschinenoptimierung bezeichnen. Google macht den PageSpeed mit Tools wie Lighthouse messbar, um die Wirkung dieser Maßnahmen zu ĂŒberprĂŒfen.

Fehler 1: Kein optimales Caching

Der Cache ist ein virtueller Zwischenspeicher. Dort werden Daten abgelegt, die wiederholt genutzt werden. Diesen Vorgang nennt man Caching. FĂŒr eine Website gibt es mehrere Arten des Cachings, die infrage kommen.

Unbedingt ratsam fĂŒr jede Website ist die effiziente Nutzung des Browser-Caches. Grafiken, Schriften und Stylesheets, die fĂŒr das Layout der Seite benötigt werden, können nach einem einmaligen Aufruf im Browser gespeichert werden. Diese Ressourcen mĂŒssen bei weiteren Seitenaufrufen ĂŒber einen frei zu definierenden Zeitraum nicht erneut geladen werden. Der Webserver muss dafĂŒr entsprechend konfiguriert werden, damit die Caching-Regeln im Head des HTTP-Aufrufs mitgesandt werden. Beim Apache-Webserver geht das am einfachsten ĂŒber eine .htaccess-Datei.

Websites, die einen Unterbau in Form eines Content-Management-Systems (CMS) wie WordPress haben, können ihre Performance auf eine weitere Weise ankurbeln. Das CMS fĂŒhrt bei jedem Seitenaufruf Datenbankabfragen und viele weitere Berechnungen durch, die sich durch einen Cache bei wiederholenden Aufrufen minimieren lassen. Bei WordPress lĂ€sst sich das hervorragend ĂŒber Plugins wie »WP Rocket«, »W3 Total Cache« oder »WP Super Cache« lösen. Dabei werden einzelne Seiten zwischengespeichert. Einer anderen Vorgehensweise bedient sich das Plugin »Redis Object Cache«: In Redis, einer In-Memory-Datenbank, speichert es direkt die Datenbankabfragen zwischen. Das erhöht gegenĂŒber den zuvor genannten Plugins auch die Geschwindigkeit im Backend, dem WP-Admin. Andere Content-Management-Systeme wie Kirby unterstĂŒtzen von Haus aus Möglichkeiten, Inhalte zu cachen.

Fehler 2: Falsch dimensionierte Bilder und Grafiken

Es ist kompliziert: Die Website muss auf allen Bildschirmen — vom kleinen Smartphone angefangen bis hin zu sehr großen Desktop-Monitoren — gut aussehen. Hinzukommt, dass dabei nicht nur die Pixelmaße variieren, sondern auch die Pixeldichten. EndgerĂ€te mit Retina- beziehungsweise HiDPI-Bildschirmen können Bilder viel feiner darstellen. Das mit einer einzigen Bilddatei auf einer Website zu lösen, ist nicht performant. Die EndgerĂ€te sollten Bilddateien entsprechend ihres Viewports und ihrer Pixeldichte von der Website angeboten bekommen, um nicht gegebenenfalls mit ĂŒberdimensionierten Bildern zu viele Daten laden und damit die Ladezeit unnötig verlangsamen.

Zudem lassen sich Pixelgrafiken mit Software wie imageOptim stark komprimieren, ohne dass das mit dem menschlichen Auge sichtbar wÀre.

Logos, Icons und andere Symbole lassen sich als SVG-Grafik im Vektorformat einbetten. Dabei werden die Bildinformationen als Kurven beziehungsweise Pfade gespeichert — und nicht als einzelne Pixel. Aber auch diese SVG-Grafiken lassen mit spezieller Software wie SVGO stark komprimieren.

Fehler 3: Unnötige Ressourcen werden geladen

Manche Websites laden bei jedem Seitenaufruf viele Ressourcen wie Schriftschnitte, Stylesheets oder JavaScript-Dateien mit, obwohl sie gar nicht verwendet werden. Das ist beispielsweise sehr oft bei Multi-Purpose-Themes fĂŒr Content-Management-Systeme ein Problem, da sie ihres Namens entsprechend möglichst viele AnwendungsfĂ€lle abdecken wollen und nicht auf den individuellen Use-Case zugeschnitten sind.

Fehler 4: Eine ungünstige Ladereihenfolge

FĂŒr viele AnwendungsfĂ€lle gibt es die Möglichkeit, Ressourcen wie JavaScript-Dateien asynchron zum Seitenaufruf zu laden. Damit wird das Rendering des Browsers nicht verzögert.

Je nach Umfang der Website ist es ratsam, auch Bilder erst zu laden, wenn sie benötigt werden (beispielsweise beim Scrollen). Es gibt mit dem »loading«-HTML-Attribut fĂŒr das img-Element eine native Lösung, den sogenannten Lazyload im Browser zu nutzen. FĂŒr diesen Fall sollten die Bilder aber eine definierte Höhe und Breite haben, damit sich das Layout nicht verĂ€ndert. Noch mĂ€chtiger ist das relativ neue »content-visibility«-CSS-Attribut. Mit dem Wert »auto« kann das rechenintensive Rendern im Browser aufgeschoben werden, bis die Bereiche benötigt werden.

Das Gegenteil vom Aufschieben kann man aber auch sinnvoll sein: FĂŒr die Seitendarstellung unabdingbare Ressourcen wie Stylesheets oder Schriften können mit <link rel="preload"> im Head der HTML-Datei vorab geladen werden. FĂŒr Elemente, die von fremden Servern geladen werden mĂŒssen, bietet sich ein DNS-Prefetch an, mit dem jene Domainnamen aufgelöst werden, bevor die Ressourcen geladen werden.

Fehler 5: Eine ungünstige Konfiguration des Content-Management-Systems

Die bisherigen Fehler wirkten sich vor allem clientseitig aus, also auf dem EndgerĂ€t der Besucher*innen. Oft gibt es aber auch serverseitig Verzögerungen, gerade im Zusammenhang mit Content-Management-Systemen. Vor allem bei WordPress sollte man der Versuchung widerstehen, viele Plugins zu installieren. Es steigt nicht nur oft der Ballast, der von den Besucher*innen mitgeladen wird, sondern auch mit jedem Plugin der Rechenaufwand fĂŒr den Server. Es geht aber auch um die QualitĂ€t der Plugins und Themes selbst. Eine ineffiziente Programmierung verlangsamt jeden Seitenaufruf.

Fehler 6: Alter Übertragungsstandard

HTTP/1.1 ist seit 1999 ein Standard zur DatenĂŒbertragung zwischen Webserver und Webbrowser. Dass dieser Standard zum Nadelöhr wird, hat man damals vermutlich nicht abschĂ€tzen können. Heutzutage ist die Limitierung von HTTP/1.1 aber ein echtes Problem: Pro TCP-Verbindung zum Webserver lĂ€sst sich nur eine Anfrage stellen. Zwar öffnen Browser normalerweise sechs parallele Verbindungen, aber damit lassen sich immer noch nur sechs Ressourcen gleichzeitig laden. FĂŒr Websites, die nicht seltene Dutzende oder gar Hunderte Ressourcen anfragen, ist das ein Hindernis. In HTTP/2 können alle Ressourcen ĂŒber eine TCP-Verbindung geladen werden, der Browser kann beliebig viele Anfragen gleichzeitig stellen (Multiplexing).

Die nĂ€chste Weiterentwicklung, HTTP/3 funktioniert nur noch mit VerschlĂŒsselung und setzt auf UDP statt TCP. TCP hat nĂ€mlich ein Makel: Es ist wickelt den Datenverkehr ĂŒber mehrstufige Handshakes ab und ĂŒbertrĂ€gt die Datenpakete chronologisch. Sobald ein Datenpaket verloren geht, stoppen alle Übertragungen. UDP verzichtet auf diese EmpfĂ€nger-Sender-BestĂ€tigungen, besitzt eine Fehlerkorrektur und hĂ€lt eine konstante Verbindung.

HTTP/3 ist noch sehr neu, zumindest HTTP/2 sollte der Webserver aber unterstĂŒtzen.

Fehler 6: Der Webserver ist den Anforderungen nicht gewachsen

Das ist nicht ohne Grund der letzte Fehler in dieser Auflistung, den man untersuchen sollte: In der Praxis liegen die meisten Probleme woanders. Mitunter kommt es aber auch vor, dass der Webserver nicht genug RechenkapazitĂ€t (RAM/CPU) fĂŒr die Webanwendung beziehungsweise dessen Besucheraufkommen bietet. Auch die Anbindung des Servers kann ein Nadelöhr sein. Dann muss entweder der Tarif aufgestockt oder der Provider gewechselt werden.

Fazit

Die GrĂŒnde, warum Websites schlecht laden, sind oft gleich. Viele Ursachen von Performance-Problemen lassen sich relativ einfach beheben. In Browsern eingebaute Entwickler-Tools helfen bei der individuellen Betrachtung, woran es hakt. HauptsĂ€chlich von technischer Seite kann man noch weiter in die Tiefe gehen, die Thematik fĂŒllt schließlich ganze BĂŒcher. Gerne unterstĂŒtzt Sie ich auch dabei.