In einem vorherigen Artikel haben wir erläutert, warum die Geschwindigkeit einer Webseite ein wichtiger Faktor ist.
Mit dem jetzigen Artikel gehen wir nun in die Fortsetzung: Wie lassen sich die verschiedenen Elemente einer Webseite hinsichtlich der Geschwindigkeit optimieren?
Hinweis: jeder Punkt für sich bietet genug Stoff, um damit ganze Bücher zu füllen – deshalb wollen wir hier auch nur jeweils einen groben Überblick geben.
Der Webserver
Rufe ich mit einem Browser eine Webseite auf, schickt der Browser eine Anfrage (request) an den Server (“gib mir die Seite https://www.neusta-ds.de/blog/”). Der Server schickt dann eine Antwort (response), die dann das HTML-Dokument der Webseite beinhaltet.
Die Zeit, die der Server benötigt, um die Anfrage des Browser zu verarbeiten und mit der Auslieferung der Daten (das HTML) zu beginnen, nennt man Time to first byte (TTFB). Dies ist dann sozusagen ein Maß dafür, wie schnell der Server auf Anfragen reagiert.
Die Time to first byte wird dabei von verschiedenen Faktoren beeinflusst. Dies sind vor allem:
Hardware-Ausstattung des Servers:
Hier gilt natürlich: viel hilft viel – je mehr Rechenleistung und Arbeitsspeicher ein Server zur Verfügung hat, desto schneller kann er arbeiten. Auch SSD-Festplatten statt klassischer Festplatten erhöhen die Geschwindigkeit deutlich. Aber: dies ist natürlich immer auch mit Mehrkosten verbunden.
Server-seitige HTML-Generierung:
Muss der Server das HTML für die Webseite erst generieren? Die meisten Content-Management-Systeme (CMS) wie WordPress, TYPO3 oder Drupal nutzen Server-seitig eine Skriptsprache (in den genannten Beispielen PHP), um dynamisch die Seiten zu generieren. Dabei werden Daten aus einer Datenbank (z.B. MySQL) geholt und dann in die Templates (Vorlagen, Muster) des CMS eingefügt. Diese Generierung kann dabei je nach Komplexität viel Zeit kosten.
Im Idealfall liefert der Server ohne Umwege das HTML für die Webseite aus. Dafür gibt es – vorausgesetzt, die Webseite hat keine dynamischen Inhalte, die eine solche statische Auslieferung unmöglich machen – verschiedene Ansätze, üblicherweise mit Hilfe eines Caches (siehe Infobox). Bei CMS-basierten Systemen sieht das in der Regel so aus, dass die (z. B. aus PHP und MySQL) fertig generierte Seite einfach als HTML-Datei auf dem Server abgelegt wird. Wird diese Webseite nun aufgerufen, liefert der Server einfach die fertige HTML-Datei aus. (Bei TYPO3 kann hierfür z. B. die Erweiterung Static Filecache genutzt werden).
Auch andere Server-seitige Caching-Tools wie Varnish oder OPCache zielen ebenfalls darauf ab, das Ausliefern der Seite zu beschleunigen, indem aufwändige Operationen des Servers zwischengespeichert werden.
Ein ebenso wichtiger Faktor bei der Server-Geschwindigkeit ist, wie viele Anfragen ein Server zur selben Zeit verarbeiten muss. (Server-Last)
Wird eine Webseite nur von wenigen Besuchern aufgerufen, wird der Server damit keine Probleme haben – bei sehr vielen Anfragen gleichzeitig hingegen wird irgendwann auch der leistungsfähigste Server in die Knie gehen. Abhilfe schaffen dann Load Balancer – dies ist sozusagen ein vorgeschalteter Server, der die Anfragen dann gleichmäßig auf mehrere Server (oder ein ganzes Netzwerk an Servern) weiterverteilt.
http/2
HTTP ist das Basis-Protokoll des Web, das die Übertragung der Daten regelt. Seit ein paar Jahren ist das Protokoll in der neuen, überarbeiteten Version http/2 verfügbar, das mittlerweile auch von den meisten Browsern unterstützt wird. Dieses bietet für die Geschwindigkeit einige Verbesserungen. So können nun mehrere Ressourcen gleichzeitig heruntergeladen werden. Außerdem können wichtige Ressourcen (z. B. Schriftarten) gleich bei der initialen Anfrage mitgesendet werden, so dass keine separate Anfrage dafür nötig ist.
Falls möglich, sollte also darauf geachtet werden, dass http/2 verwendet wird.
Komprimierung
Die meisten Computernutzer haben schon einmal mit ZIP-Dateien gearbeitet. Der Vorteil: große Dateien lassen sich komprimieren und damit schneller über das Netz versenden und empfangen.
Das gleiche Prinzip kann bei Webseiten genutzt werden, das Standard-Tool zur Komprimierung ist hier gzip. Der Server komprimiert die Ressourcen (HTML, CSS, Javascript, …) und muss daher dann eine deutlich geringere Menge an Daten über das Netzwerk ausliefern. Der Browser des Benutzers entpackt dann wieder die Ressourcen in ihren Originalzustand (wobei der zeitliche Aufwand für das komprimieren und entpacken dabei deutlich geringer ist als die Zeitersparnis durch die verringerte Datenmenge!).
CSS
CSS (Cascading Style Sheets) definiert, wie eine Webseite aussieht – von Farben, Schriftarten und -größen über Positionierung von Elementen hin zu Animationen. Diese Styles werden normalerweise in einer eigenen Datei bereitgestellt, die im HTML-Dokument der Webseite verknüpft ist.
Um eine Webseite anzeigen zu können, muss der Browser wissen, wie sie aussehen soll. Dazu liest er die CSS-Datei ein, um die Style-Regeln dann auf die HTML-Elemente anwenden zu können. Diese Style-Regeln können dabei aber recht umfangreich werden, so dass dieses Auslesen und Anwenden der Regeln die ganze Seitendarstellung deutlich verzögern kann.
Aus diesem Grund wird seit einigen Jahren bereits eine spezielle Methode angewendet, um diesen Prozess zu beschleunigen, meist unter dem Stichwort “Critical CSS” genannt.
Dabei wird das CSS gesplittet: in einen Teil, der für die Elemente benötigt wird, die beim Laden der Seite direkt zu sehen ist (man spricht hierbei auch vom “critical rendering path”, daher der Name der Methode); dieser Teil wird dann statt in einer separaten Datei direkt im HTML abgelegt und ist damit schneller für den Browser verfügbar. Zudem muss der Browser zunächst nur einen kleineren Teil der Style-Regeln interpretieren – die Webseite kann also schneller dargestellt werden. Der andere Teil der Styles, der für die zunächst nicht sichtbaren Elemente zuständig ist, wird dann per Javascript nachgeladen.
Bilder
Bilder machen oft einen Großteil der bei einer Webseite anfallenden Datenmenge aus. Daher ist es auch umso wichtiger, Bilder mit Blick auf die Geschwindigkeit zu optimieren. Zunächst ist eine gute Caching-Strategie wichtig – wird ein Bild mehrmals verwendet, sollte es vom Browser nur einmal heruntergeladen und dann aus dem Cache verwendet werden.
Dann sollten Bilder immer für die Darstellung im Web optimiert werden. Durch Optimierungs-Tools lässt sich die Datenmenge der Bilder (ohne Qualitätsverlust) deutlich reduzieren. [siehe. z. B. https://tinyjpg.com als Beispiel für ein Online-Tool]
Da auch nicht immer gleich alle Bilder einer Webseite sichtbar sind, empfiehlt sich der Einsatz eines Lazy-Loading-Mechanismus: damit ist gemeint, dass ein Bild erst dann tatsächlich geladen wird, wenn der Nutzer zu der entsprechenden Stelle auf der Webseite scrollt. So lässt sich die gesamte Datenmenge beim initialen Aufruf der Webseite massiv reduzieren.
Fazit
Wie baue ich nun eine schnelle Webseite? Wichtig ist, alle Elemente im Blick zu behalten. Natürlich gilt: Less is more (Speed). Je weniger Features, Bilder, Videos, Tracking-Skripte etc. ich in eine Webseite integriere, desto schneller wird sie.
Eine Webseite, die nur aus einfachem HTML besteht, ist in Sachen Geschwindigkeit kaum zu schlagen, siehe am Beispiel: www.goshdarnwebsite.com
Ist dann aber natürlich auch sehr langweilig.
