Einstellungen im CMS - Tuning der Webseiten-Geschwindigkeit
Der erste Teil dieses Artikels erklärt, wie eine Webseite aufgebaut wird. Um zu verstehen, warum eine Webseite sich verlangsamt, ist es notwendig, die Reihenfolge zu verstehen, in der Inhalte aufgebaut werden. Ohne dieses Verständnis ist es nicht möglich, die Seitengeschwindigkeit nach vorn zu bringen. Deshalb führt kein Weg daran vorbei, dies zu verstehen. Es gibt kein Allheilmittel und kein Plugin, das die Seitengeschwindigkeit einer komplexen Webseite automatisch verbessert.
Desktop vs. Mobile Bewertung
Wir werden häufig gefragt, ob es denn nicht ausreicht, auf dem Desktop gut bewertet zu sein. Die Antwort ist selbstverständlich "nein". Google möchte es natürlich vermeiden, zwei Indizes zu erstellen, weil die Webseite mobil nicht performt oder die Inhalte anders dargestellt werden. Deshalb gibt's den sogenannten "mobile first index". Es ist absolute essentiell, auf mobilen Geräten genau so gut zu performen wie auf dem Desktop. Auf dem Desktop gute Ergebnisse zu erreichen, ist relativ simpel und wird deshalb gar nicht in die Bewertung einbezogen.
Head-Bereich und Skripte
Das CMS - egal welches - liefert die Inhalte in Form eines HTML-Dokuments aus. Hier muss man verstehen, wie eine Internetseite aufgebaut wird.
Head-Bereich: Der Kopfbereich der Webseite enthält Informationen für die Grundstruktur der Seite, gegebenenfalls Skripte, Style-Informationen und vileles weitere. Dieser Bereich wird immer geladen, bevor weitere Inhalte geladen werden. Fallstricke gibt es hier viele:
- Riesige CSS Dateien
- Javascript-Dateien, die das Dokument verändern
- Synchrone Aufrufe von Daten
- Überflüssiger Code
- Fremder Code von fremden Servern
Insbesondere bei Wordpress-Themes und anderen Fertig-Designs sind hunderte Komponenten mitgeliefert, von denen die tatsächliche Webseite meist nur einen Bruchteil verwendet. Der größte Aufwand ist es dabei, unbenutzten Code aufzuräumen. Insbesondere aber bei verschachtelten CSS-Klassen wird es schwierig, all das zu identifizieren. Dies passiert eigentlich ausschließlich, wenn man mit fertigen Designs oder veralteten responsive Frameworks arbeitet.
Fremdcode - die üblichen Verdächtigen
ReCaptcha: Als Spam-Schutz eine sicherlich zuverslässige Lösung - wenn nicht sogar die einzige - aber eben sehr "teuer", es zu laden. Das Skript ist sehr groß und verzögert die Ladezeit sehr stark. Oftmals wird es ebenfalls geladen, obwohl gar kein Kontaktformular auf der Seite eingebunden ist. Da weiß es das System nicht besser und lädt den Code eben nicht nach Bedarf.
Fonts und CSS: Über fonts.googleapis.com eingebundene Google Fonts (seit 2018 nicht mehr erlaubt, mehr dazu hier) werden von Google Servern in den USA geladen, auch das zieht die Ladezeit in Grund und Boden, wenn kein alternativer Font geladen wird.
jQuery, Bootstrap, etc.: Auch diese Skripte werden häufig in voller Größe von fremden Servern geladen, wo man im Zweifel keinen Zugriff auf die Einstellung des liefernden Webservers hat. Die gelieferten Skripte vom Fremdserver sind selbstverständlich nicht "aufgeräumt", hier wird fast immer viel unnötiger Code geladen, der auf der finalen Webseite gar nicht gebraucht wird.
Bilder, Bildgrößen, Formate
Bilder spielen eine große Rolle bei Webseiten. Es gibt zwei Möglichkeiten, Bilder auf Webseiten einzubinden. Bilder können als HIntergrundbild eines Elements oder direkt über das img-tag eingebunden werden. Hier spielen mehrere Faktoren eine Rolle.
Bildgrößen: Die Größe von Bildern sind etwas schwierig bei Webseiten. Auf einem Handy ist ein Bild physisch wesentlich kleiner als es z.B. auf einem Monitor ist. Ironischerweise aber sind andere Handy-Displays hochauflösend und verlangen bei guter Internet-Verbindung sogar ein Bild in höherer Auflösung.
Bildformate: Moderne Bildformate sind bei Webseiten ebenfalls ein Faktor. WebP ist hier eines der effizientesten Formate mit sehr guter - allerdings verlustreicher Komprimierung. Die häufigsten Systeme allerdings stellen die Bilder als JPEG oder PNG bereit und viele Webseitenbetreiber können mit dem modernen Format nicht arbeiten.
Physikalsche Auflösung vs. dargestellte Größe: Die häufigste Problematik sind Bilder, die in riesiger Print-Auflösung hochgeladen werden, aber im Netz nur klein dargestellt werden - nicht selten bei z.B. Mitarbeiterfotos. Dort sind dann riesige Bilder hinterlegt, die aber lediglich in der Größe eines Geldstücks genutzt werden.
DOM-Größe und Pagebuilder
Hier ist der Verursacher auch wieder schnell gefunden. Fertige Themes sind ein Problem. Vielmals ist es viel zu komplizierter und verschachtelter HTML-Code, der von Systemen wie Elementor, WP Bakery und ähnlichen Baukastensystemen erzeugt wird.
Es sind dann nicht die Bilder oder Videos, die Probleme verursachen, sondern der komplette HTML-Baum, der viel zu viele unnötige Elemente enthält, die sich mit jedem Element multiplizieren und für eine unnötig komplexe Struktur sorgen. Das zu beheben ist extrem schwierig, wenn man ein fertiges Design verwendet. Es ist dann oft weniger Aufwand, die Elemente explizit neu zu konstruieren als das vorhandene zu reparieren.
Ein Beispiel aus der Praxis: Ein Menü-Element. So sind die Menü-Elemente dieser Seite aufgebaut. Ein Listen-Element, das einen Link enthält. Der Rest ist über CSS-Klassen gelöst.
<li class="item classes">
<a href="link-zur-seite.html" class="link classes">Name der Seite</a>
</li>Ein Beispiel einer typischen Wordpress/Elementor-Seite, für ein nahezu identisches Element
<li class="link classes">
<div class="color settings">
<div class="wrapper">
<span class="icon"></span>
<div class="separator"></div>
<a href="link-zur-seite.html">Name der Seite</a>
</div>
</div>
<span class="underline effect"></span>
</li>Stellen Sie sich vor, dass dieses Element hundertfach auf der Seite genutzt wird, für jeden Untermenüpunkt, in sehr hoher Komplexität und sehr verschachtelt - uns dass nicht nur die Menü-Elemente so unnötig kompliziert gebaut sind, sondern eben auch jedes HTML-Element auf Ihrer Seite, dann bläht sich der Quellcode so stark auf, dass tatsächlich Last auf dem System entsteht, um das alles zu dekodieren.
Webserver-Einstellungen und Leistung
Leverage Browser Caching
Dem Browser muss mitgeteilt werden, welche "Haltbarkeit" die Daten haben, die ihm geliefert werden. Hierzu gehört jede Form von Datei. Javascript-Dateien, Bildern, etc. - jegliche Form von Datei erhält sozusagen einen Stempel, wie lange diese Datei auch in Zukunft noch "gültig" sein wird.
Setzt man diese Zahl zum Beispiel auf 10 Sekunden, so würde der Browser ein Headerbild oder Skripte, Styles, etc. einfach komplett von null auf neu vom Server laden, weil der Server mitteilt, dass es sehr wahrscheinlich ist, dass sich dieser Inhalt innerhalb von 10 Sekunden ändert.
Kurzum: ist dieser Wert zu klein eingestellt, so werden oft Inhalte neu geladen, die sich gar nicht verändert haben.
Allgemeine Webservereinstellungen
Komprimierter Texttransfer: Sowohl bei nginx als auch bei Apache muss die Textkomprimierung eingeschaltet sein, damit der Seitentransfer performant funktioniert. Der Grund dafür ist einfach: HTML wiederholt sich eben oft. Werden die Inhalte komprimiert übertragen, sind es tatsächlich lediglich 10% der unkomprimierten Daten, die übertragen werden.
FPM: Bei der Verwendung von PHP bietet es sich an, Fastpage zu verwenden. Bei anderen Sprachen ist so etwas nicht relevant, PHP als Handler derart einzutragen funktioniert wesentlich eleganter.
Aktuelle Software: Eigentlich bedarf das keiner Erklärung, aber allein der Sprung auf PHP 7 brachte bei PHP-basierten CMS (Wordpress, Joomla, Typo3, MODX, Drupal, etc.) einen riesigen Geschwindigkeitsschub. Hier immer aktuell bleiben, sofern das CMS es erlaubt.
Technische Einstellungen im CMS
Datenbank-Einstellungen
Aufrufe der Datenbank sind immer "teuer". Insbesondere solche, die verschachtelt Daten abfragen. Deshalb gibt es mehrere Einstellungen, die man in einem Produktionssystem aktiv haben sollte:
Datenbank Cache
Aktivieren. Wiederkehrende Abfragen, wie zum Beispiel "die aktuellsten 10 News Artikel" abzufragen, sind immer so lange identisch im Ergebnis, bis es einen neuen News-Artikel gibt. Deshalb wird das nicht jedes mal neu abgefragt, sondern nur dann, wenn es ein neues Ergebnis gibt. Cache für die Datenbank sollte also immer aktiviert sein und nur in besonderen Fällen uncached genutzt werden. Systeme wie Wordpress bieten dafür keinerlei Fein-Einstellungen, bei den meisten Seiten mit wenig Bewegung ist das aber auch nicht nötig. Es liefert im schlimmsten Fall für einige Stunden veraltete Daten. Das wäre sicherlich für die meistne Nutzer zu verschmerzen.
Probleme mit Antwortzeiten beheben
Plugins und eigener Code
Fertig-Systeme wie Joomla und Wordpress haben oft Plugins, die eine Summe an Datenbankabfragen oder externe Daten anfragen. Manchmal wurden sogar eigene Datenbank-Abfragen oder eigene Plugins eingebaut, die das System erst einmal zu einigen "Berechnungen" zwingen, bevor eine Seite final ausgeliefert werden kann.
Serverleistung
Manchmal ist auch der Server, der die Seite bereit stellt, sehr langsam, hat nur wenige Prozessorkerne oder zu wenig RAM. Oft nutzen die Anbieter Billig-Tarife von Strato, IONOS und andern Shared-Hositng Systemen. Für viele Seiten ist das ausreichend, aber oft eben am falschen Ende gespart. Der Betrieb der Seite ist essentiell für die meisten Nutzer.
Pagespeed ehöhen - so geht's:
Seite beschleunigen - Kurz und knapp
Wie sie sehen, liegt der Großteil dieser Fehler an vorgefertigten Komponenten oder nicht sachgemäßer Konfiguration von Server und CMS.
Diese Probleme kommen meist daher, dass Ihnen gegebenenfalls ein "Design" verkauft wurde, Sie aber gar kein Design bekommen haben, sondern eine fertige, fremd eingekaufte Lösung. Dazu kommen billige Hosting-Lösungen, die eine nicht optimale Standard-Konfiguration haben oder schlichtweg nicht genügend Leistung haben.
Wenn das System Bilder nicht automatisch skaliert und konvertiert, treten ähnliche Probleme auf. Riesige Bilder und Videos tauchen im System auf, die die Ladezeit der Seite stark beeinträchtigen.
Fehlerhafter Einbau von Bildern und synchrones Laden von nicht sichtbarem Inhalt ist ebenfalls ein gängiges Problem von Webseiten, da die gesamte Seite, inklusive der unteren Bereiche der Webseite, erst geladen wird, bevor die Seite vollständig dargestellt wird.
Bilder und Picture-Tag
Bilder skalieren und auf WebP umstellen. Bilder müssen entsprechend skaliert und gegebenenfalls sogar für die jeweiligen Anwendungsbereiche bereit gestellt werden. HTML bietet hierfür eine Möglichkeit, das sogenannte Picture-Tag.
<picture>
<source media="(max-width: 799px)" srcset="image-cropped-to-middle.webp" />
<source media="(min-width: 800px)" srcset="image-wide.webp" />
<img src="image-wide.webp" alt="Description of the image" />
</picture>Das Picture-Tag lässt den Browser entscheiden, welche Version des Bildes er verwenden soll. Das Img-Tag darunter ist dafür zuständig, ein Failsafe anzubieten, das im Zweifelsfall angezeigt wird. Ansonsten entscheidet der Browser, welches Bild er nutzt. Ein breites Header-Bild ist in dem Fall auf einem schmalen Display nicht gewünscht, sondern ein Hochkant-Foto mit dem relevanten Inhalt in der Darstellung. So ist niemals ein zu großes oder ein zu kleines Bild das Problem.
Keine gekauften Designs verwenden
Man sollte sich Gedanken machen, ob die "schnelle Lösung" oder die Variante einer Wordpress-Agentur wirklich der Weisheit letzter Schluss ist. Am Ende läuft vieles darauf hinaus, dass fertige Themes mehr Probleme mitliefern, die es nachher zu beheben gilt, als sie Vorteile bringen. Man hat zwar schnell eine Webseite, aber diese bringt fast immer Probleme in der Geschwindigkeit mit sich, oft aber auch Probleme, was Datenschutz und deutsche Restriktionen betrifft.
Lieber nach Maß designen als nachher aufräumen
Eines der beliebtesten Wordpress-Themes z.B. ist Avada oder auch Enfold. Diese Themes enthalten hunderte, teils auch sehr schöne Design-Elemente. Aber am Ende lädt man alles an Skripten, Effekten und Style-Elementen für diese Varianten, obwohl man lediglich einen Bruchteil davon verwendet. Ziel dieser Systeme ist ein schnelles Ergebnis zu liefern, allerdings ist es eben fast immer schneckenlangsam und in seiner Flexibilität sehr eingeschränkt, weil durch viel Komplexität auch viel Verwaltungsaufwand folgt - und viele Fehler. Besser ist es, nicht den eigenen Inhalt an die Design-Elemente des Themes anzupassen, sondern Design-Elemente anhand der Anforderung zu entwickeln - und auch nur diese zu verwenden. So vermeidet man Code-Müll und zwängt sich nicht ein System auf, bei dem meine Seite um ein Fertig-Design herum entwickelt wurde, anstatt das Design ein Resultat meiner Inhalte werden zu lassen.
Caching und Datenbank
Google achtet darauf, dass die Seite wiederkehrende Inhalte gecacht ausliefert. Heißt: Wenn ein Bild eine "Lebensdauer" von einem Jahr hat, ist das vollkommen okay. Gleiches gilt für Skripte, Schriftarten und vieles weitere. Diese Daten ändern sich nicht ständig, und das sollte man dem Browser auch mitteilen. Es entstehen sehr viele Probleme mit der Geschwindigkeit einer Seite, wenn Inhalte ständig neu geladen werden, obwohl diese seit Jahren unverändert sind.
Gleiches gilt für die Datenbank: Eine Anfrage aus dem Cache ist wesentlich schneller ausgeliefert, als wenn man in der Datenbank nachschaut. Insbesondere bei Webseiten, auf denen alle paar Wochen etwas angepasst wird. ist es schon rein logisch so, dass man natürlich ein Regelwerk zugrunde legen sollte, ab wann wieder Datenbankabfragen gemacht werden müssen. Die meisten schnellen Systeme lösen das über sogenannte "Timestamps". Das System weiß, ob der zwischengespeicherte Inhat noch aktuell ist, oder ob es eine aktuellere Version gibt, die aus der Datenbank bezogen werden muss.