Niemand, wirklich niemand wartet gerne, bis eine Website lädt. Viele Studien zeigen ganz direkte Auswirkungen. Aus Testergebnissen bei Amazon leitet sich die Aussage ab, wonach eine um 100 Millisekunden längere Seitenladezeit in einem Prozent weniger Bestellungen resultieren. Wir haben vor einiger Zeit schon darüber geschrieben:
Niemand wartet gerne auf eine Maschine
Bis 0,1 Sekunden Verzögerung nach einer Interaktion hat ein Mensch, der eine maschine bedient, das Gefühl, die Maschine reagiere sofort. Als affektive Bewertung bleibt zurück: Das war die Maschine (allgemein: das System) tut, ist direkte Folge der Interaktion mit der Maschine.
Bis zu einer Sekunde Verzögerung ist ein Mensch im Schnitt bereit, die Verzögerung zu tolerieren. Man spürt die Latenz und weiß, dass der Computer das Ergebnis produziert, wähnt sich aber noch in Kontrolle des Systems. Man hat noch nicht das Gefühl, auf die Maschine warten zu müssen.
Bis zehn Sekunden ist der Mensch in einer Mensch-Maschine-Interaktion typischerweise bereit, die Aufmerksamkeit in dieser Situation zu halten. Allerdings drängt sich schon das Gefühl auf, der Maschine ausgeliefert zu sein. Man wünscht sich, das ginge alles schneller. Dennoch bleibt man bereit, die Interaktion fortzusetzen.
Nach zehn Sekunden ist es mit dem guten Willen vorbei. Ab dieser Verzögerung fangen Menschen an, an etwas anderes zu denken. Sie verlieren das Interesse an der Mensch-Maschine-Interaktion. Konkret: Man wartet nicht, sondern verlässt die Website.
Hier steht mehr dazu:
https://www.nngroup.com/articles/website-response-times/
Schnelle Websites ohne CMS
Websites kann man mit oder ohne WordPress erstellen, indem man die HTML/CSS-Dateien selbst schreibt und fertig auf den Server lädt. In diesem Fall muss kein Content Management System (CMS) die Browseranforderung entgegennehmen und dann erst mit Hilfe komplexer Skripte HTML-Code erzeugen (man sagt: rendern), der an den Browser zurückgeschickt wird (der diese HTML-Suppe dann auch erst interpretiert und darstellt). Diese Seiten sind dann besonders schnell.
Diesen Effekt machen sich Cache-Module und Content Delivery Systeme (CDN) zu nutze: Die in HTML vom CMS schon einmal gerenderten Seiten werden in einem Zwischenspeicher (Cache) für einen neuen Abruf vorgehalten. Der neue Abruf geht dann viel schneller. Dies hat natürlich nur Sinn, wenn die zu zeigenden Webseiten nicht hochgradig individuell sind, so dass gar nichts ürbig bleibt als die Seiten dynamisch zu erzeugen.
Skripte und andere Prozesse benötigen einfach Zeit, um zu laufen, was gerade bei WordPress ein ziemliches Manko ist. WordPress ist alles andere als schnell. Man kann die Performance optimieren :
- Mit mehr Silizium, d.h. mehr Hardware wie schnellere Prozessoren in den Server, bessere SSDs mit mehr I/O-Werten, breitbandigere Anbindung etc
oder durch - Mit Eiweiß/Fett/Kohlenhydraten, d.h. mit mehr Expertise oder Überlegung beim gestalten der Website unter verstärkter Nutzung des Gehirns: Kleinere, gut komprimierte oder weniger Mediendateien wie Bilder, weniger unnötige Aufrufe auf externe Ressourcen wie Skriptbibliotheken, von denen man nur einen kleinen Teil benötigt. Selbst mittels einer Änderung der Ladereihenfolge lassen sich manchmal positive Effekte erzielen.
Um Software auf einem Server, der mit dem Internet verbunden ist, schneller ablaufen zu lassen, könnte man die Anzahl der Prozessorkerne erhöhen, mehr RAM-Speicher reservieren und die in-/out-Prozesse zum RAM und zur HD/SSD beschleunigen. Man könnte die Bandbreite erhöhen, mit der die physikalische Maschine mit dem Internet verbunden ist. Dies bewirkt mehr Hardware- und Konnektivitätskosten.
Viele Server sind nicht physikalisch vorhanden, sondern stehen virtuell zur Verfügung. Hier ist die Anzahl der virtuellen reservierten Prozessorkerne wesentlich, genauso wie der verfügbare Arbeitsspeicher.
Wer einen eigenen virtuellen Server betreibt, kann hier Einfluss nehmen, indem er mehr Ressourcen bucht – was natürlich mit Mehrkosten verbunden ist.
Wer ein günstiges Webhosting-Produkt nutzt, sollte nicht das billigste buchen, denn je niedriger der Preis, desto höher die Kundendichte pro Server.
Mehr Kundendichte bedeutet, mehr Risiko durch die Servernachbarschaft: Websites auf dem Server könnte per DDoS angegriffen werden und ziehen die anderen Kunden auf diesem Server in Mitleidenschaft. Alle Seiten werden langsamer. Wenn weniger Kunden auf einem Server untergebracht sind, sinkt das Risiko (nicht so viele “Angriffspunkte”).
Zudem könnte man die “Mittelschicht” verbessern. Es ist durchaus entscheidend, welche Software auf dem Server für welchen Zweck verwendet wird. Große Unterschiede macht es, womit der Server sich beschäftigen soll.
Die Webserversoftware lässt sich mit Modulen erweitern, man kann sich vorstellen, dass je mehr Module eingebunden sind, desto mehr Arbeit muss der Server bewältigen, auf Unterbrechungen und Anforderungen achten. Dies gilt auch für Module, die Module ergänzen, z.B. PHP-Erweiterungen.
Wichtig ist zudem die Anzahl der Threads, die parallel abgearbeitet werden dürfen. Dies ist eine Festlegung in der Konfiguration des Webservers. Als Webseitenbetreiber, der keinen Zugriff auf die Serverkonfiguration nehmen kann, hat man darauf nur mittelbar Einfluss, im Regelfall.
Hilfreich ist es meist, serverseitig ein Kompressionsverfahren zu nutzen, damit Webinhalte gleich komprimiert übertragen werden (z.B. gzip).
Als Webseitenbetreiber hat man den größten Einfluss beim Inhalt selbst, also bei den Skripten sowie den Texten, Bildern und anderen Dokumenten, die angezeigt werden. All diese Dokumente müssen über das Internet transportiert werden.
Je “fetter” eine Datei ist, desto länger dauert dies. Es spielt sich zwar alles im Bereich von Millisekunden ab, aber die Zeiten summieren sich, vor allem dann, wenn der Browser nicht weiter an der Darstellung der Seite arbeiten kann, weil erst eine Datei geholt werden muss.
Unterschiedliche Webanwendungen stellen dem Webserver unterschiedliche Aufgaben. Manche können direkt den Inhalt liefern, andere greifen auf Datenbankinhalte zu, fügen sie in ein Template, erzeugen daraus HTML und senden es zum Server.
Die schnellste Variante ist, wenn der Inhalt, der zum Browser geschickt werden soll, z.B. ein HTML Dokument, fertig vorliegt und nicht erst auf Anforderung erzeugt (“gerendert”) werden muss. Diesen Umstand machen sich Beschleunigerfeatures wie Caches oder Content Delivery Networks (CDN) zunutze.
Ansonsten sollte man dafür sorgen, dass der Server nicht mit Skriptanforderungen zugeschüttet wird. Eine PHP-Datei, die eine PHP-Datei inkludiert, die noch eine PHP-Datei inkludiert: So arbeitet WordPress. Deswegen ist es auch recht langsam. Wer also fertige Anwendungen nutzt (z.b. WordPress) kann hier allerdings nicht so viel tun, mit der Ausnahme, dass man genau überlegen sollte, welche Erweiterungen (Plugins) oder Themes man noch dazu einsetzt, die die Inkludiererei nochmals verstärken.
Vorsicht mit externen Scriptfragmenten wie Social Media Plugins oder Analyse-Tools: Sie rufen externe Server an und eventuell muss der Browser warten. Diese möglichst asynchron laden.
Asynchrones Laden empfiehlt sich auch für andere Elemente, die benötigt werden. Außerdem kann man in den Code der Seite Informationen hinterlegen, wie lange der Browser die schon mal geladenen Datei aufheben und wiederverwenden soll (Caching des Browsers).
Übrigens können auch Tempates (Themes) die Zeit bis zur Anzeige der Website verlängern, indem erst externe JS-Bibliotheken (Frameworks wie Bootstrap) geladen werden müssen oder vom Browser viele Javascriptbefehle auszuführen sind. Wenn möglich, sollte man die “minimized”-Variante für Produktivzwecke nutzen.
Eine alte Regel ist es, Bilder, Videos oder Audio für das Web zu komprimieren. Dafür gibt es entsprechende Filter für gängige Bearbeitungsprogramme (z.B. Adobe Photoshop).
Den goneo Webhosting- und Webmacher Podcast gibt es bei Apple Podcasts, Stitcher und Spotify, hier im goneo-Blog sowie als RSS/XML-Feed für den Podcatcher deiner Wahl.
