Website zu langsam? Diese Performance-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.

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.

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.

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.

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.

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.

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.

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.

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.