Praktische Website Performance Tipps - Serverseitige Optimierung
Veröffentlicht am 08.01.2025 von Thomas Puppe
Stellen Sie sich vor, Sie betreten ein Restaurant und es dauert ewig, bis Sie bedient werden. Unabhängig davon, wie gut das Essen ist, würden Sie wahrscheinlich nicht zurückkehren. Jetzt stellen Sie sich dasselbe Szenario online vor. Ihre Website ist Ihr digitales Restaurant und Ihre Performance ist Ihr Kundenservice.
Website-Performance-Optimierung ist das Rückgrat einer effektiven Webpräsenz. Sie ist von entscheidender Bedeutung, weil sie direkt die Benutzererfahrung, die Suchmaschinen-Rankings und letztlich Ihre Conversions und Umsätze beeinflusst.
Dennoch wird die Optimierung oft vernachlässigt, da sie technisches Know-how erfordert und die Auswirkungen von Performance-Problemen nicht immer sofort sichtbar sind. Zudem haben viele Unternehmen nicht die Ressourcen oder das Budget, um kontinuierlich in Performance-Verbesserungen zu investieren. Aber die Auswirkungen einer schlechten Performance summieren sich im Laufe der Zeit und können erhebliche Implikationen auf den Online-Erfolg eines Unternehmens haben.
Warum Website Performance Optimierung?
Aber warum eigentlich? Vermutlich lesen Sie als tech-affines Publikum diesen Blogpost an einem schnellen DSL-Anschluss im WLAN, oder über ein modernes Handy mit 5G-Fähigkeit. Ich selbst habe ihn auf einem MacBook Pro geschrieben, das mein Arbeitgeber mir alle paar Jahre neu kauft. Hochgeladen habe ich ihn per Glasfaser. Das Internet ist schnell, das Leben ist schön.
Mal abgesehen davon, dass "www" nicht "wealthy western web" bedeutet… auch unsere Kunden und LeserInnen sind häufig nicht so gut ausgestattet wie wir. Denken Sie zum Beispiel an Ihre Eltern oder Großeltern. Oder an sich selbst in bestimmten Situationen: in der Provinz oder im Zug.
Aber auch unter guten Bedingungen, wenn sich Webseiten in Sekundenschnelle aufbauen, sind Sekundenbruchteile relevant. Die sogenannte Page Speed fließt seit 2010 ins Google-Ranking für Desktop-Seiten ein. Seit 2018 auch für mobile Seiten. Weil Google sagt: Performance ist ein Usability-Faktor, und der wird im Ranking belohnt. Und zahlreiche Studien zeigen: Bessere Performance wirkt sich positiv auf die Seitenaufrufen, Verweildauer, Conversion Rate und gar auf die Anzahl und den Wert von Artikeln im Warenkorb von Onlineshops aus. Website-Performance ist ein Wettbewerbsvorteil!
Außerdem immer wichtiger: Jedes Byte, das durch die Gegend geschickt wird, kostet nicht nur Geld, sondern verbraucht auch Ressourcen. Wenn man das Internet als Ganzes mit einzelnen Ländern vergleicht, ist es mittlerweile der drittgrößte CO2-Emittent der Welt – nach den USA und China. Und wenn wir mit einfachen Maßnahmen Performance optimieren und damit Energie sparen können, und das auch als Multiplikatoren für Tausende oder Millionen von Nutzern, dann sollten wir alle Möglichkeiten dafür nutzen.
Dieser Artikel besteht aus zwei Teilen. Der erste Teil dreht sich um den Server bzw. Ihre Build Chain. Wie werden die Bestandteile einer Website optimal vorbereitet, um möglichst schnell übertragen zu werden? Es geht also um das, was sich im Internet abspielt. Im zweiten Teil behandeln wir dann, was im Browser Ihrer KundInnen passiert. Wie werden die Ressourcen effektiv geladen und so koordiniert, dass Ihre Website möglichst schnell auf dem Bildschirm erscheint?
Alte und neue Metriken
Zunächst einmal: Was ist Website Performance? Und wie bemisst man die?
Als ich ca. 2011 anfing, mich mit dem Thema Website-Performance-Optimierung zu beschäftigen, haben wir auf simple und harte Zahlen geschaut, um die Performance einer Website zu messen. Wie viele Requests werden gemacht? Wie groß sind diese Requests? Wie schnell werden sie beantwortet? Die Daten dafür kamen aus den DevTools der Browser, bzw. aus externen Plugins wie Firebug.
In den Jahren darauf wurden die Metriken in den Browsern besser, und sie waren näher an der User Experience unserer Kunden: Wie lange dauert es, bis das DOM geladen ist? Und alle Inhalte der Seite? Es ging schon mehr um die wahrgenommene Performance.
Und dann kam Google und hat noch mehr nutzerzentrierte Daten im Browser ermittelt: Wie lange dauert es, bis der wichtigste Inhalt auf der Seite sichtbar ist? Ab wann kann ich mit der Seite interagieren? Wie schnell reagiert sie auf Input? Die Idee dahinter: Wenn der erste Screen da ist und ich die Seite bedienen kann, dann ist es weniger wichtig, ob im Hintergrund noch weitere Daten geladen werden. Der Begriff für diese neuen Metriken ist "Core Web Vitals".
Aber es ist nicht so, dass die neuen Metriken die alten obsolet gemacht hätten. Sondern sie sind die Grundlage.
Am Ende wollen wir die Kunden und Google zufriedenstellen (in welcher Reihenfolge ist nochmal eine eigene Diskussion). Dazu schauen wir heutzutage eben auf die Core Web Vitals. Letztendlich läuft es aber natürlich auch wieder auf die geladenen Daten hinaus. Je weniger und schneller, desto besser. Damit beschäftigt sich Teil 1 dieses Artikels. Aber die geschickte Orchestrierung dieser Daten beeinflusst die Web Vitals maßgeblich. Das ist Gegenstand des zweiten Teils.
Also: Legen wir los.
Caching
Der schnellste Request ist der, den der Browser nicht machen muss! Deshalb gibt es Caching im Browser.
Dieser platte Spruch klingt einfach. Aber Caching wird immer noch zu häufig vergessen. Bitte nutzen Sie Cache-Header, möglichst hoch. Ich schreibe das nicht, weil Sie das nicht wissen. Sondern weil Sie es nicht machen. Um die 40 Prozent aller Requests im Netz haben keinen Cache-Header!
Hinweis: Der Web Almanac des HTTP Archive erschien zuletzt 2022. Manche der hier zitierten Kapitel sind von 2021. Damit sind die Daten leicht veraltet. Die Tendenz und Grundaussage ist aber auch in 2025 noch gültig.
Caching ist kein Wissensproblem. Aber ein Problem des Bewusstseins oder der Disziplin.
Für Seiten mit viel Traffic ist fehlendes oder zu kurzes Caching sogar ein ernster Kostenfaktor. Aber in jedem Fall danken es Ihre Kunden – und das Google Ranking auch
Hier winkt ein großer Wettbewerbsvorteil, wenn Sie Ihre Hausaufgaben richtig machen.
Und wie macht man seine Hausaufgaben? Das hängt individuell vom Webserver ab. Für Apache, NGINX und Caddy gibt es entsprechende Konfigurationen. Auch WordPress, Next.js und praktisch jedes Web-Framework haben entsprechende Plugins.
Die Herausforderung ist eher, fehlendes Caching zu erkennen – zum Beispiel, weil man keinen Cache-Header für WOFF2 oder SVG-Dateien gesetzt hat. Zum Erkennen reicht Ihnen ein Blick in die DevTools der Webbrowser.
In der Liste der Netzwerk-Requests können Sie den Filter has-response-header:Cache-Control setzen und invertieren (in Firefox mit vorangestelltem Minus (-has-response-header:Cache-Control), in Chrome via Checkbox). So sehen Sie auf einen Blick alle Requests, die nicht im Browser gecacht werden. Auch Performance-Testing-Tools wie Lighthouse weisen auf fehlendes Caching hin.
Komprimierung
Auch das Thema Komprimierung ist – ähnlich wie das Caching – Common Sense. Aber nicht “Common Doing”.
Noch einmal Zahlen vom Web-Zensus, der jährlichen Bestandsaufnahme des Einsatzes von Internet-Technologie:
Bildquelle: almanac.httparchive.org/en/2021/compression
JavaScript und CSS werden ganz gut komprimiert. Aber 56 Prozent der Websites komprimieren ihr HTML nicht! Und 32 Prozent vernachlässigen JSON. Gerade in der heutigen API-lastigen Welt ist das ein großes Versäumnis. Insbesondere JSON-Daten haben über ihren Inhalt (häufig wiederholter Keys) nochmal ein besonderes Komprimierungs-Potential.
Auch hier gilt: Performance-Testing-Tools, von denen Sie im Verlauf dieses Artikels einige kennenlernen werden, weisen auf fehlende Komprimierung hin. Aber auch Sie selbst können diese erkennen. Und zwar im Netzwerk-Tab der Browser-DevTools. In diesem lassen sich die Spalten “Größe” und “Übertragen” aufklappen. Sie zeigen die eigentliche Größe und die Größe bei der Übertragung (hoffentlich komprimiert) an. Das Verhältnis der beiden Werte zeigt den Kompressionsgrad. Ist eine Datei bei der Übertragung so groß wie im Original, wurde sie nicht komprimiert.
Bildquelle: Eigener Screenshot der Firefox DevTools
Der zweite spannende Aspekt an der bunten Grafik des Web Almanac ist die Art der Komprimierung. Gzip war sehr lange Zeit der Standard. Brotli ist der bessere Nachfolger.
Gzip vs. Brotli
Gzip ist die Default-Lösung, die man überall anknipsen kann. Brotli komprimiert besser – zum Teil viel besser – ist aber komplizierter in der Anwendung. Wie es sich im Detail verhält, ist eine Frage Ihres Tech-Stacks und Ihres Webservers. An dieser Stelle möchte ich auf die Stack-agnostischen Aspekte eingehen.
Erstens: Der Browser-Support für Brotli ist geringer: Sie brauchen heutzutage noch Gzip als Fallback!
Zweitens: Die dynamische Komprimierung in Brotli ist aufwändig und langsam. Es ist optimiert für die Dekomprimierung. Brotli lohnt sich also nur für statisch komprimierte und danach gespeicherte oder gecachte Inhalte.
Ich habe die Erfahrung gemacht, dass das schlichte Einschalten von Brotli unsere Server überlastet hat. Das kriegt man natürlich in den Griff. Durch Recherche des Themas und durch Feinjustierung der Kompressionsstufen. Oder aber man nimmt Gzip und hat den meisten Nutzen durch den geringsten Aufwand.
Bilder
Die soeben besprochene Komprimierung betrifft Textformate wie HTML, JavaScript, JSON, und CSS. Bilder hingegen muss man nicht beim Transport komprimieren. Bilder haben anhand ihrer Formate eine eigene Komprimierung. Deshalb sind diese auch beim Transport so groß wie “in echt”. Fast jeder kennt JPG, PNG und GIF. Und viele wissen, dass sich bestimmte Formate für bestimmte Inhalte besser eignen. JPG ist z.B. besser für Fotos und PGN für Grafiken.
Weniger wissen, dass es mit WebP und AVIF moderne Formate gibt, die nochmal deutlich kleiner sind.
Bildquelle: Eigene Zusammenstellung
Und quasi niemand benutzt diese modernen Formate!
Bildquelle: almanac.httparchive.org/en/2022/media
WebP hat laut HTTP Archive nur eine Verbreitung von 9 Prozent – AVIF ist gar nicht verbreitet, trotz gutem Browsersupport. Und trotz der immensen Vorteile.
Die Verwendung ist einfach: Sie geben dem Browser ein picture mit sources. So sagen Sie dem Browser, welche Bildformate Sie zur Verfügung stellen – und der Browser nimmt das beste Format, das er kann. Das img ohne type-Attribut dient als Fallback, wenn der Browser die anderen Formate nicht versteht.
Die Erzeugung dieser JPG/PNG, WebP und AVIF Bilder ist abhängig von Ihrem individuellen Build-Prozess oder Auslieferungs-Stack.
Es gibt Plugins für WordPress und andere CMS. Es gibt GUI-Tools wie ImageOptim (für Mac) oder Squoosh (im Browser). Es gibt zig npm-Pakete (oder Python, PHP, Ruby, Whatever), mit denen Sie sich die neuen Bildformate in Ihre Build Chain holen können. Und es gibt Cloud-Lösungen, bei denen Sie einfach Geld auf das Problem werfen. Diese werden als Proxy eingesetzt, der die Bilder von der Quelle holt, sie für den jeweiligen Client aufbereitet, und dann cacht. Und solche Proxies gibt es sogar zum Selbst-Hosten.
Ob Ihre Bilder schon gut komprimiert sind und was Sie noch rausholen können, können Sie online gratis testen. Entweder direkt im Browser mit DevTools wie Lighthouse:
Bildquelle: Eigener Screenshot einer Lighthouse-Analyse von www.rostock.de im Chrome Browser
Oder Sie nutzen ein Online-Tool wie Cloudinary. Dort geben Sie die URL Ihrer Website ein und bekommen direkt angezeigt, wie viel Einsparpotential Sie mit modernen Bildformaten haben.
Bildquelle: Analyse der Bildkomprimierung auf www.luebeck.de mittels https://webspeedtest.cloudinary.com
Machen Sie das doch direkt mal! Der Artikel wartet solange.
Audio und Video
Was für Bilder gilt, gilt auch für Audio und Video. Neben den altbekannten Formaten MP3 und AVI gibt es zum Beispiel FLAC und OBB für Audio, sowie MPEG-4 und WebM für Videos. Auch hier können Sie NutzerInnen mit verschiedenen Browser-Generationen verschiedene Formate zur Verfügung stellen. Moderne Devices profitieren dann von modernen, kleineren Dateiformaten.
Webfonts: WOFF2
Sie oder Ihr Designer haben sich also entschieden, dass Sie Webfonts nutzen. Die Schrift wird von der Agentur gestellt oder aus einem Fontshop im Internet geladen. Achten Sie darauf, dass die Schrift im Format WOFF2 vorliegt! Alle anderen Formate sind obsolet. EOT, SVG und Truetype sowieso. Aber auch WOFFf1 ist nicht mehr nötig – und damit auch keine Fallback-Syntax für mehrere Schriftformate. Seit rund 10 Jahren unterstützen alle Browser das WOFF2-Format. Und Besucher mit älteren Browsern wie dem Internet Explorer 11 von Microsoft haben ganz andere Sorgen, als dass Ihnen ein exakter Webfont angezeigt wird.
Bildquelle: Eigenes Diagramm, erstellt mit der Software “Pitch”
Viele Schriftenanbieter lassen Sie direkt WOFF2 herunterladen. Wenn Ihr Webfont in einem anderen Format vorliegt, können Sie sie mit kostenlosen Tools wie dem Transfonter konvertieren. Achten Sie aber darauf, ob die Lizenz Ihnen das erlaubt.
Webfonts: Subsetting
Mit WOFF2 haben Sie schon ein performantes Format für Ihren Webfont. Die Schriftdatei ist klein und kann schnell geladen werden. Aber Sie haben das Potential für Performance-Optimierung noch nicht ausgeschöpft. Mit "Subsetting" erreichen Sie in der Regel noch viel kleinere Font-Files:
Bildquelle: Eigenes Diagramm, erstellt mit der Software “Pitch”
Subsetting ist die Königsdisziplin der Performance-Optimierung von Webfonts, aber was ist das genau?
Schriften können heutzutage echt viel. Zum einen haben sie tolle Effekte wie Ligaturen, hoch- oder tiefgestellte Zeichen und die Darstellung von Bruchzahlen. Zum anderen enthalten Sie natürlich nicht nur lateinische Schriftzeichen, sondern auch viele andere Sprachen und Schriftsysteme von Afrikaans über galizisch, hebräisch und kyrillisch bis hin zu Zulu.
Was Ihr Webfont alles kann, können Sie sich über das kostenlose Tool Wakamai Fondue anzeigen lassen. Für die beliebte Schriftart Montserrat von Google Fonts sieht man zum Beispiel, dass sie 1909 Zeichen in 50 Sprachen unterstützt. Für den Webfont ist das ein wichtiges Feature. Aber für Sie ist es unnötig, wenn Sie zum Beispiel Ihren Lebenslauf online stellen.
Deshalb können Sie aus Ihrem Webfont nicht benötigte Zeichen entfernen. Das nennt man Subsetting. Die Dateigröße der Schrift Montserrat aus dem obigen Beispiel kann man durch die Begrenzung auf lateinische Schriftzeichen auf 13 KB reduzieren.
Es gibt wenige Optimierungen, mit denen Sie einen solchen Faktor von Verbesserung erreichen. Nutzen Sie das!
Auch für das Subsetting gibt es kostenlose Werkzeuge, wie zum Beispiel den Font Subsetter von Everything Fonts. Hier können Sie die benötigten Zeichensätze (zum Beispiel das lateinische Alphabet) aus einem Webfont herauslösen.
Eine vollautomatisierte Hyperoptimierung macht der "Glyphhanger" von Zach Leatherman. Das Tool (kostenlos verfügbar bei npm) liest den genutzten Zeichensatz einer Website aus und generiert ein Subset für genau die benötigten Zeichen. Das funktioniert nur für statisch vorgenerierte Seiten, also zum Beispiel eine Landingpage, und nicht für dynamische Inhalte.
Nicht laden, was ungenutzt ist
Nach den recht technischen Themen Caching und Komprimierung gehe ich hier kurz auf ein “organisatorisches” Thema ein. Binden Sie keine Sachen in Ihre Seite ein, die ungenutzt sind!
Das klingt logisch. Und ich möchte hier nicht Ihre Intelligenz in Frage stellen. Jedoch: Sehr häufig verbleiben ”Altlasten” im Quellcode einer Website, die nicht mehr genutzt werden. Beispiele? Die Software für A/B-Tests ist eingebunden, obwohl aktuell kein Test läuft. Ein Feature wurde von der Seite entfernt, aber die CSS-Files werden noch immer eingebunden. Oder der JavaScript-Code für den Support-Chat, der nur auf der Kontaktseite verfügbar ist, wird auf jeder einzelnen Seite eingebunden.
Ich selbst habe noch in jedem Job und Projekt solche Situationen erlebt (bzw. selbst erzeugt), obwohl ich hier ja der Performance-Guy bin. Also: Es lohnt sich immer wieder, genau hinzuschauen. Was findet auf der Seite statt? Was wird geladen? Warum? Und wann?
Das einfachste Tool dafür sind die DevTools Ihres Webbrowsers. Schauen Sie sich damit Ihre Projekte an und scrollen durch den Netzwerk-Tab.
Eine schöne grafische Übersicht über die Inhalte auf Ihrer Seite, die von externen Quellen kommen, sind sogenannte Request Maps. Diese zeigen in einem Graphen mit Knoten und Kanten, von welchen Domains Inhalte in eine Website eingebunden sind.
Bildquelle: Eigener Screenshot von https://requestmap.webperf.tools/
Mit Request Maps sehen Sie vor allem, welche externen Ressourcen geladen werden – und was diese wiederum nachladen. Die Beurteilung, ob diese Ressourcen genutzt werden, müssen Sie selbst vornehmen.
Eine zweite Möglichkeit, ungenutzten Code auf Ihrer Website zu finden, ist auch wieder in die DevTools vom Chrome-Webbrowser eingebaut. In der sogenannten “Konsolenleiste” (englisch: “Console drawer”) gibt es den Punkt “Abdeckung” (englisch: “Coverage”). Hier wird für jede CSS- und JavaScript-Datei angegeben, zu welchem Teil diese tatsächlich genutzt wird. Hier sehen Sie zum einen komplett ungenutzte Dateien. Und zum anderen, ob bestimmte Ressourcen nur teilweise gebraucht werden.
Bildquelle: Eigener Screenshot der Chrome DevTools auf zeit.de
Was Sie damit machen, ist dann die nächste Frage. “Code Splitting” ist eine gängige Methode. Zum Beispiel könnten Sie eine eigene CSS-Datei bauen, die nur Elemente abdeckt, welche auf Ihrer Homepage oder einer Marketing-Landingpage gebraucht werden. Damit diese Seiten schnell laden. Der Code für den Bezahlvorgang Ihres Onlineshops hingegen kann genau dort eingebunden werden – und nicht auf einer Artikelseite, die damit schlank bleibt.
Andere Methoden sind das Lazy Loading oder eine sogenannte Fassade. Auf diese werde ich in Teil 2 dieses Artikels zu sprechen kommen.
Aber am Anfang steht erst einmal das Bewusstsein darüber, was man überhaupt tut. Und dabei helfen die DevTools, Request Maps und das Coverage Tool immens.
Keinen Code schreiben, den der Browser schon hat
Sie haben also ungenutzten Code entdeckt und entfernt. Je nach Größe und Alter Ihrer Projekte kommt da manchmal schon einiges zusammen. Als nächstes möchten wir uns ein verwandtes Phänomen ansehen: “doppelten Code”, bzw. Code für Dinge, die der Browser selbst schon hat. Manche Features werden aus Gewohnheit oder Unwissenheit neu gebaut, obwohl sie mittlerweile standardmäßig in den Browsern verfügbar sind. Das Rad wird also neu erfunden. Beispiele hierfür sind System Fonts, Akkordeons, Modalfenster und Formularvalidierung.
System Fonts
Im ersten Teil dieses Blogposts haben wir uns damit befasst, wie Sie Ihre Webfonts komprimieren können. Durch das WOFF2-Format und Subsetting lassen sich diese häufig auf einen Bruchteil ihrer ursprünglichen Größe reduzieren. An dieser Stelle möchte ich einen Schritt zurückgehen und die Sinnfrage stellen: Brauchen Sie überhaupt Webfonts?
Grundsätzlich sind Webfonts eine tolle Errungenschaft. Es ist toll, dass Websites damit deutlich individueller gestaltbar sind, als zu den Zeiten, wo wir die Wahl zwischen Times New Roman und Verdana hatten. Wenn sich das aber heutzutage auf die Wahl zwischen Roboto und Noto Sans – zwei der beliebtesten Webfonts mit sehr hoher Verbreitung – beschränkt, kann man auch nicht von Vielfalt sprechen.
Sogenannte Systemschriften hingegen sind vielfältiger, als man gemeinhin annimmt. Als Systemschriften bezeichnet man diejenigen, die auf den Betriebssystemen vorinstalliert sind, und damit schon auf der großen Mehrzahl der Geräte Ihrer KundInnen und LeserInnen. Diese Fonts müssen also nicht heruntergeladen werden, was Traffic und Ladezeit spart. Außerdem sind Effekte wie Font-Flashes (keine oder falsche Schrift wird angezeigt, bis der Webfont geladen wird) oder fehlende Glyphen ausgeschlossen.
Die Auswahl an Systemschriften ist mitnichten auf Serif und Sans-Serif beschränkt. Sondern es gibt moderne und antike Schriftstile, runde und schmale, Monospace und Handschrift. Wenn Sie also "nur" einen besonderen Akzent auf Ihre Headlines setzen wollen, oder eine handgeschriebene "Unterschrift" auf der Kontaktseite, dann schauen Sie sich mal bei Modern Font Stacks um.
Bildquelle: Screenshot von modernfontstacks.com
Mit den System Fonts erreichen Sie schöne Schrifteffekte, ohne extra Webfonts einbetten und optimieren zu müssen.
Übrigens: Der Begriff "Stack" ergibt sich daraus, dass dort für jede Schrift die Äquivalente auf verschiedenen Betriebssystemen aufgelistet sind. Somit sieht die Schrift auf Windows, Mac und Ubuntu gleichfalls gut aus.
Nach dem einfachen Beispiel der Webfonts komme ich zu “echten Features”, die häufig nachgebaut werden, obwohl moderne Browser diese schon nativ mitbringen.
Akkordeons
Ein sehr verbreitetes Feature auf Websites – insbesondere mobilen Websites auf kleinen Screens – sind sogenannte Akkordeons oder Content Toggles, oder bestimmte Formen von Tooltips. Man sieht eine Überschrift oder eine Liste von Überschriften. Und per Klick lassen sich jeweils Inhalte ausklappen.
Bildquelle: Eigene Screenshots
So etwas wird gern per JavaScript gebaut. Wenn Sie es richtig machen wollen, müssen Sie dabei auch die Bedienung per Tastatur beachten (Accessibility) und ohne JavaScript (Robustheit).
Oder aber Sie nutzen das native HTML-Element
/, das jeder Browser unterstützt (samt Tastaturbedienung, NoJS-Unterstützung und allem).Je nachdem, wie funktionsreich oder elegant Sie Ihre Akkordeons bisher gebaut haben, sparen Sie mehr oder weniger Code ein. Vielleicht sogar eine npm-Dependency. Vor allem aber sparen Sie sich Implementierung und Wartung, wenn Sie die native Browser-Funktion nutzen. Hier liegt der Nutzen vor allem im ersparten Aufwand und weniger in den eingesparten Kilobytes.
Das nächste Beispiel lohnt sich schon mehr, aus reiner Performance-Perspektive:
Dialog, Modal, Popover
Auch sehr beliebt im Netz sind Popover-Modal-Fenster. Informationen oder Eingabefelder werden auf einer eigenen Ebene gezeigt und die Website im Hintergrund wird verdeckt.
Bildquelle: Aishwarya Vijay Kumar auf Dribbble
Dieses Pattern ist so verbreitet, dass es dafür ganze Libraries gibt. Eine schnelle Suche bei npm ergibt dutzende Pakete. Zum Teil mit 1.3 MB Größe und 15 Dependencies.
Was für die native Funktion im Browser ausreicht, ist das hier:
HTML:
Das native Element lässt sich mit JavaScript-Einzeilern triggern und schließen:
JavaScript:
Das Styling erfolgt per CSS wie bei anderen Elementen auch – mit dem Pseudo-Selektor :backdrop für den halbtransparenten Sperr-Hintergrund, der sich vor die Seite und hinter das Dialogfenster legt.
CSS:
Die Browser-native Implementierung dieses Features bringt von Hause aus natürlich Tastaturbedienung mit. Der Fokus wird verwaltet (für Screenreader und Tastaturbedienung). Das Dialogfenster ist immer auf oberster Ebene, ohne dass Sie den z-index verwalten müssen. Außerdem ist sichergestellt, dass nur eines zur gleichen Zeit geöffnet sein kann. Alles Details, um die Sie sich bisher selbst kümmern – oder ein ganzes npm-Paket importieren mussten.
Formularvalidierung
Als letztes Thema zum Komplex “das kann Ihr Browser längst selbst” möchte ich auf Formularvalidierung eingehen. Auch hier gibt es viele Software-Bibliotheken zum Einbinden. Und noch mehr selbst geschriebenen Code. Und auch hier haben die Browser mittlerweile sehr gute und mächtige eigene Validierungslogik.
Dass Pflichtfelder markiert werden können, ist den meisten Leuten bekannt:
<input id="email" required />
Mit einem einfachen Type-Attribut aktivieren Sie außerdem die Validierung auf eine korrekte E-Mail-Adresse:
<input id="email" type="email" required />
Das Styling der Formularfelder je nach Status können Sie auch nativ machen: ohne eigene CSS-Klassen, sondern mit Pseudo-Selektoren.
Und die native Formularvalidierung erlaubt auch komplexere Patterns via Regex. Zum Beispiel, um eine Passwort-Policy durchzusetzen.
Und wenn ein sehr alter Browser das noch nicht kann, bekommt der sein Feedback halt erst nach dem Absenden. Sie müssen Formulareingaben sowieso auf jeden Fall nochmal serverseitig prüfen.
Das Laden von Bibliotheken im Client (vielleicht sogar mit Übersetzungslisten, wenn Ihre Formulare mehrsprachig sind) können Sie sich zukünftig sparen. Und – siehe das Kapitel zu unused JavaScript-Code – es ist nicht unwahrscheinlich, dass der Code zur Validierung des Kontaktformulars auch schon auf Ihrer Homepage eingebunden war und dort das Laden blockierte.
Weitere Beispiele
Weitere Beispiele für native Browser-Features, die noch viel zu häufig selbst gebaut werden, sind: Pop-Ups mit dem neuen popover-Attribut, Teilen in beliebigen Apps mit der nativen Web-Sharing-API, Zugriff auf die Zwischenablage, usw, usf. Die Liste ließe sich fortsetzen. Meine Botschaft: Bleiben Sie auf dem Laufenden, um das Rad nicht neu zu erfinden.
Fazit: Serverseitige Performance-Optimierung
In Teil 1 dieses Artikels haben wir Performance-Optimierungen auf der Server-Seite, im Netzwerk und in der Build-Chain betrachtet. Nutzen Sie Caching! Komprimieren Sie Ihre Inhalte! Nutzen Sie moderne Formate für Webfonts, Bilder und andere Medien! Und nutzen Sie die Features, die moderne Browser mitbringen!
In Teil 2 des Artikels lernen Sie dann, wie Sie Ihre Inhalte optimal im Browser laden, um bei gleicher Datenmenge eine bessere Performance zu erreichen.
