Praktische Website Performance Tipps - Clientseitige Optimierung

Veröffentlicht am 06.02.2025 von Thomas Puppe

Bildquelle:

https://almanac.httparchive.org/en/2022/mobile-web#images

Sie können mit dem Einsatz von responsiven Bildern die Hälfte Ihrer Konkurrenz ausstechen!

Es gibt auch dafür verschiedene Online-Tools, denen man eine ganze Website füttert – und sie listen auf, welche Bilder nicht responsiv sind und wie viel man durch eine Optimierung einsparen würde. Ein Beispiel ist das bereits genannte Tool von Cloudinary. Ein anderes ist dieser Responsive Image Checker. Auch Lighthouse aus den Chrome DevTools weist auf unresponsive Bilder hin.

Wie sagt man so schön – ist ganz einfach, muss nur gemacht werden. Die Generierung von responsiven Bildern jedoch ist so individuell wie Ihr Tech-Stack. Sie können die Bilder beim Build-Prozess generieren, oder dynamisch bei der Auslieferung. Für die Einbindung der unterschiedlichen Bildgrößen in Ihr HTML gibt es Standards. 

Die relativ einfache Lösung ist das srcset. Sie geben dem Browser eine Liste von Bildgrößen, die Sie zur Verfügung stellen. Und der Browser sucht sich dann das passende Bild aus.

Etwas komplexer ist die Verwendung von Source-Tags. Das sind, im Gegenteil zum srcset, keine Vorschläge an den Browser, sondern Anweisungen. Hier können Sie auch Art Direction betreiben, oder eine Infografik hochkant/quer darstellen, je nach Device.

Auch die sources in pictures können ein srcset haben. Hier stellen Sie zusätzlich Retina-Versionen Ihrer Bilder zur Verfügung, für Geräte mit Retina-Bildschirmen.

Lazy Loading

Lazy Loading bedeutet, dass Inhalte erst geladen werden, wenn sie gebraucht werden. Die Homepage von News-Websites zum Beispiel listet mehr als 100 Teaser. Leser, die diese Homepage besuchen und einen der ersten Artikel öffnen, sollten nicht alle 100 Teaser-Bilder herunterladen.

Dass Bilder erst beim Scrollen nachgeladen werden, wenn sie in den Viewport kommen, ist ein gängiges Pattern. So gängig, dass sich bei npm eine eigene Industrie darum gebildet hat. Bei der Suche nach "Lazy Loading" in npm finden Sie 1464 Pakete, die zum Teil über 300 kB groß sind und Abhängigkeiten haben. Und ungepflegt sind.

Was Sie eigentlich brauchen, ist das hier:

Bilder werden nicht mit einem src-Attribut in das img-Tag eingebunden, sondern mit einem data-src-Attribut. Mit einem IntersectionObserver beobachten Sie, wann das Bild in den Viewport kommt. Sobald das passiert, schreiben Sie das Attribut um, und das Bild wird somit geladen.

Diese Methode hat ein paar Schwächen, um die Sie sich noch kümmern müssen. So sollte das initiale src-Attribut nicht fehlen, sondern z.B. ein 1x1 Pixel großes Bild enthalten. Und Sie sollten eine Variante bereitstellen, die ohne JavaScript funktioniert (in einem noscript Tag).

Noch einfacher geht das Lazy Loading aber wie folgt:

<img src="kitten.jpg" loading="lazy" />

Seit 2019/2020 verstehen die Browser das native Loading Attribut an Bildern. Mit diesem kleinen Attribut weisen Sie den Browser an, dass er Bilder bitte nur laden soll, wenn sie dem Viewport nahekommen und damit gebraucht werden.

Wann genau der Browser die Bilder lädt, wie weit er vorausschaut, ob ich vorwärts oder rückwärts scrolle… Sie brauchen sich um nichts mehr zu kümmern!

Das funktioniert übrigens auch für iFrames, was ich fast noch den sinnvolleren Einsatzzweck finde!

Einen kleinen Haken hat das native Lazy Loading allerdings. Und zwar orientieren sich die Browser an der User Experience, und nicht am Datensparsamkeitswahn von Performance-Enthusiasten. Nämlich: Der Browser lädt mehr vor, wenn die Internetverbindung langsam ist! Bei einer schlechten mobilen Verbindung werden dann beispielsweise 12 Bilder außerhalb des Viewports heruntergeladen, während im schnellen Glasfasernetz nur die geladen werden, die unmittelbar im Viewport sind. Die Priorität ist, dass Bilder beim Scrollen möglichst schon geladen sind. Zu dem Preis, dass man ggf. ungenutze Bilder vorlädt.

Die Entscheidung zwischen eigener Mikro-Optimierung oder der bequemen nativen Lösung müssen Sie selbst treffen. Im Zweifel, wenn Sie bisher kein Lazy Loading haben (oder eine aufwändige Lösung von npm), sollten Sie einfach das loading="lazy"-Attribut einbauen. Und den Browser seine Arbeit tun lassen.

Fassaden

Eine nahe Verwandte von Lazy Loading ist die sogenannte Fassade.

Die Idee ist die Folgende: Ein normaler Embed eines YouTube- oder TikTok-Videos, oder eines X-Posts, bringt gern mal 1 bis 2 MB auf die Waage. Es werden ganze JavaScript-Bibliotheken heruntergeladen, selbst wenn Ihre Kundinnen und Leser das Video niemals anklicken. Das Laden eines nur potentiell genutzten Inhalts verzögert also den Aufbau der gesamten Seite. Außerdem werden Nutzerdaten an die jeweiligen Anbieter übertragen – eben auch von Nutzern, die die Inhalte gar nicht sehen wollen.

Statt das ganze Embed von YouTube oder Vimeo in Ihre Seite einzubinden, könnten Sie lediglich ein Vorschaubild anzeigen. Und erst beim Klick auf den Play-Button wird das richtige Embed mit all seinen SDKs und Trackingscripten und Nextview-Empfehlungen geladen.

Für populäre Dienste gibt es passende Scripte im Internet, zum Beispiel das lite-youtube-embed von Paul Irish, das lite-vimeo-embed, ein twitter-lite-embed oder eine lite-tiktok Web Component.

Andere Dienste oder Ihre eigenen Widgets können Sie ebenso verpacken. Ein Kundensupport-Chat im Footer der Seite sollte zum Beispiel erst beim Klick auf den entsprechenden Button geladen werden. Dashboards können den initialen Screen bereitstellen, und nicht die ganze App. Spiele zeigen (und laden!) nur den Startscreen, und laden das richtige Spiel erst auf Click. Code für Formularvalidierung muss erst geladen werden, wenn das erste Formularfeld angesteuert wird. Und so weiter.

Am besten ist es, wenn eine leichtgewichtige Fassade gleich bei der Konzeption neuer Features mitgedacht wird. So ist die Umsetzung viel leichter, als im Nachhinein Fassaden in Apps oder Features einzubauen. Aber in jedem Fall lohnt es sich.

Layout Shift

Egal wann und wie ein Inhalt geladen wird – ob gleich, oder später lazy: Layout Shift ist ein verbreitetes Phänomen. Oder besser gesagt, ein weitverbreitetes Problem!

Layout Shift ist der Effekt, wenn eine Seite Bilder lädt und deswegen die Inhalte durch die Gegend geschoben werden. Dadurch wirkt der Seitenaufbau extrem unruhig. Und Ihre User wissen nicht, wann sie eigentlich anfangen können, die Seite zu benutzen.

Im schlimmsten Fall haben Ihre Leser schon angefangen, einen Artikel oder eine Produktbewertung zu lesen. Und dann schiebt der einem den Text aus dem Bild.

Bildquelle: Eigene Screenshots von zeit.de

Super nervig. Das sehen auch Ihre LeserInnen so. Und Google! Layout Shift ist eines der sogenannten Core Web Vitals. Und hat einen Einfluss auf das Google Ranking. Für Layout Shift wird man abgestraft.

Was Sie statt dieser Verschiebung haben wollen, ist ein Freihalten der Fläche, damit beim Laden des Bildes kein Layout Shift entsteht.

Bildquelle: Eigene Screenshots von zeit.de

Das erreichen Sie durch eine min-height, oder durch eine feste Höhe des zu ladenden Elements. Wenn die Höhe sich aber nach der Breite des Bildschirms richtet (vollbreites Bild auf mobilen Geräten), dann wissen Sie die Höhe des Bildes beim Programmieren der Seite nicht. Dann können Sie die (seit 2021 breit unterstützte) CSS-Property aspect-ratio nutzen:

CSS

.teaser__image {
                aspect-ratio: 16/9;
}

Sie nennen dem Browser direkt das Seitenverhältnis des Bildes. Gültig sind Brüche (aspect-ratio: 4/3), Fließkommazahlen (aspect-ratio: 1.5) und ganze Zahlen (aspect-ratio: 1 für quadratische Flächen). So weiß der Browser, wie viel Platz er für das Bild (oder ein zu ladendes Embed) freihalten muss – noch bevor er es geladen hat.

Achten Sie darauf, dass alles, was beim Seitenaufbau einen Layout Shift erzeugt, stattdessen seinen Platz freihält.

Auf den Layout Shift können Sie direkt beim Entwickeln aufpassen. Weil der Layout Shift ins Google-Ranking einfließt, ist er natürlich quantifizierbar. In der Tat gibt es eine Layout Instability API im Browser, die Sie per JavaScript anfragen können. Und es gibt fertige Tools, die darauf aufsetzen.

Den Layout Shift zeigen die DevTools und Extensions in den gängigen Webbrowsern an. In Chrome gibt es beim "Console Drawer" den Tab "Rendering". Und dort können Sie "Layout Shift Regions" und "Core Web Vitals" aktivieren. "Layout Shift Regions" markiert Regionen auf der Seite, die einen Layout Shift haben (ggf. müssen Sie die Netzwerkgeschwindigkeit in den DevTools drosseln, um den Effekt besser zu sehen). Die "Core Web Vitals" zeigen einen Score für den Layout Shift an. Weniger ist besser. 0.00 ist perfekt. Die Anzeige der Web Vital Scores in den DevTools ist offiziell deprecated, Google verweist auf eine Chrome Extension. Aber aktuell funktioniert die Anzeige noch direkt im Browser.

Die Anzeige von Layout Shift sollten Sie beim Entwickeln immer an haben, und den Shift konsequent vermeiden.

Nicht immer kennen Sie die Größe oder Ratio eines zu ladenden Elements. Zum Beispiel, wenn es einen Platz für Werbung gibt und dort verschieden große Werbebanner geladen werden können. In diesem Fall lohnt es sich, wenigstens die Mindesthöhe des kleinsten Werbemittels freizuhalten. Wenig Layout Shift ist besser als viel Layout Shift. Für Ihre User sowie für das Google-Ranking.

Rel = Preload

Ein häufiger Verursacher von Layout Shift ist das Aufmacherbild oder "Hero Image" einer Website. Logisch: Es ist sehr groß und weit oben. Wenn das beim Laden die Inhalte verschiebt, fällt das auf.

Je nachdem, wie das Bild eingebunden ist, wird es schneller oder langsamer geladen. Um den folgenden Performance-Trick gut illustrieren zu können, möchte ich kurz eine suboptimale Website skizzieren. Nehmen wir an, die Website hat ein <div class=”heroimage”>. Dieses ist leer. Und per JavaScript wird dort das große Hero-Image gerendert..

In diesem Fall muss der Browser erst das JavaScript laden und parsen, Stichwort Critical Rendering Path, um dann auf das Bild zu stoßen und es dann herunterzuladen. Währenddessen starrt der Kunde hoffentlich auf den per aspect-ratio freigehaltenen Weißraum.

Selbst wenn das Bild direkt auf der Seite als img- oder picture-Tag eingebunden ist, sehen Sie im Netzwerk-Tab der DevTools vermutlich noch andere Ressourcen, die vor dem Bild geladen werden. Und nicht alle sind tatsächlich wichtiger als das Bild. Zum Beispiel blockierendes JavaScript im Head ohne async/defer.

Sie können aber das Laden Ihres Hero-Images priorisieren, um es vor anderen Ressourcen laden zu lassen. Das passende HTML-Element ist das link-Tag mit rel=preload-Attribut im Head der Seite!

Damit können Sie schon im HTML-Head bekanntgeben, welche Ressource später mal gebraucht wird. Wenn Ihr JavaScript dann das img-Tag in die Seite rendert, ist das zugehörige Bild schon heruntergeladen. Es erscheint also schneller. 

Indem Sie dem Browser den Befehl zum Preload geben, schicken Sie Ressourcen auf die Überholspur. Dieses sprachliche Bild ist ganz passend: Was Sie nämlich nicht machen sollten, ist, alles auf die Überholspur zu setzen. Dann wäre diese verstopft.

Die im ersten Abschnitt dieses Artikels besprochenen Media Queries für responsive Bilder lassen sich auch in rel=preload anwenden:

Nicht nur Hero-Images können Sie auf diese Art vorladen, sondern auch Videos oder Schriften. Das Vorgehen ist auch nicht begrenzt auf "Vanilla"-Web-Technologien. In jeder Angular/React/Svelte/Vue-App können Sie auf diese Art wichtige Ressourcen auf die Überholspur schicken.

Der Browser-Support für rel=preload ist sehr gut. Und wenn ein Browser das nicht kann, dann ignoriert er es. Sie machen also nichts kaputt.

Font Loading (font-display)

Wie soeben erwähnt, ist rel=preload eine Möglichkeit, Schriften zeitig zu laden. Indem sie dem Browser direkt im head des HTML bekannt gemacht werden, muss er sie nicht erst im CSS entdecken und nach dem CSS laden.

Außerdem haben Sie in Teil 1 dieses Artikels gelernt, wie Schriften durch das WOFF2-Format und Subsetting so optimiert werden können, dass sie möglichst klein für den Download sind.

Neben der Reduktion der Größe und der Steuerung des Ladezeitpunkts durch Preload gibt es eine dritte Möglichkeit, die Performance von Webfonts zu optimieren. Und zwar die gefühlte Performance.

Während des Ladens von Webfonts hat ein Browser zwei Möglichkeiten, wie er mit den durchaus schon heruntergeladenen Text-Inhalten auf einer HTML-Seite umgeht. Entweder der Text wird gar nicht angezeigt, solange der Webfont noch nicht geladen ist. Man sieht an der Stelle Weißraum. Und sobald der Webfont geladen wurde, wird der Text eingeblendet. Oder der Browser rendert den Text direkt in einer Systemschrift, und tauscht sie gegen den Webfont aus, sobald dieser geladen ist.

Bildquelle:

https://www.fasterize.com/en/blog/web-performance-optimising-loading/

Der erste Fall nennt sich "Flash of Invisible Text" (FOIT), den zweiten nennt man "Flash of Unstyled Text".

Sie haben als EntwicklerIn Einfluss darauf, wie die Webfonts auf Ihrer Seite geladen werden. Und zwar durch das CSS-Property font-display. Es kann fünf Werte annehmen:  

• font-display: block: Es wird keine Schrift gezeigt. Nachdem der Webfont geladen ist, wird dieser angezeigt. Falls der Webfont nach wenigen Sekunden nicht da ist, wird allerdings doch die Systemschrift gezeigt, bis der Webfont geladen wurde. Verwenden Sie diese Methode, wenn Ihnen die designgetreue Darstellung der Schrift sehr wichtig ist.
• font-display: swap: Die Systemschrift wird sofort gezeigt. Und sobald der Webfont geladen wurde, wird dieser verwendet.
• font-display: fallback: Die Systemschrift wird sofort gezeigt. Wenn der Webfont dann binnen drei Sekunden geladen wurde, wird dieser verwendet. Ansonsten bleibt es bei der Systemschrift.
• font-display: optional: Für 100ms wird keine Schrift gezeigt. Falls der Webfont danach da ist, wird er verwendet. Wenn nicht, wird die Systemschrift verwendet und nicht mehr ausgetauscht.
• font-display: auto: Das Default-Verhalten des jeweiligen Webbrowsers. Edge nutzt swap, die anderen Browser nutzen block.

Weil font-display pro Schriftart definiert wird, können Sie eine gemischte Strategie fahren. Zum Beispiel können Sie Ihre Marken-Schrift in auffälligen Headlines durch font-display: block erzwingen, und den Fließtext mit font-display: swap sehr schnell anzeigen lassen.

Diese Lade-Strategie betrifft normalerweise nur den ersten Besuch Ihrer Leser auf Ihrer Seite. Beim Öffnen der Folgeseiten ist der Webfont im Cache des Browsers und kann sofort gezeigt werden. 

Fazit: Clientseitige Performance-Optimierung

Sie haben gelernt, dass für Websites mit gleichem Inhalt (welcher hoffentlich gecacht und komprimiert ist) eine ganz unterschiedliche User Experience und Performance erreicht werden kann – je nachdem, wie die Inhalte priorisiert und koordiniert werden. 

Responsive Bilder laden nur die notwendige Größe für jedes Device. Lazy Loading und Fassaden beschleunigen den Seitenaufbau, indem später benötigte Inhalte auch erst später geladen werden. Indem Sie Layout Shift vermeiden und Schriften mit font-display steuern, verbessern Sie die gefühlte Performance. Und rel=preload schickt wichtige Inhalte auf die Überholspur.

Testing-Tools und Monitoring

Die in diesem Artikel vorgestellten Performance-Optimierungen können Sie systematisch in Ihren Projekten vornehmen.

Weitere Vorschläge und priorisierte Empfehlungen geben Ihnen Testing-Tools. Diese können Sie gezielt für einmalige Tests nutzen. Oder für kontinuierliches Monitoring.

Website Performance ist kein Projekt mit einem festen Abschluss. Sondern ein Feature, oder ein handwerkliches Selbstverständnis. In meinen Augen ist man niemals fertig damit. 

Dementsprechend sind kontinuierliches Testing und Monitoring der Website Performance sehr wichtig. Sie können damit Regressionen vermeiden. Also feststellen, wenn Ihre Website wieder langsamer wird. 

Sie können sogar die Websites und Shops Ihrer Konkurrenz monitoren. Entweder um sicherzugehen, das Sie die schnellste Seite im Wettbewerb haben – oder zumindest nicht die langsamste. Das Benchmarking mit der Konkurrenz kann Ihnen sogar helfen, Ressourcen innerhalb Ihrer Firma für die Optimierung der Performance freizumachen.

Je nach Zweck und Professionalisierung können Ihnen verschiedene Tools und Web Services helfen, Ihre Website Performance zu testen und zu monitoren.

Stets verfügbar: DevTools und Lighthouse

Das beste Tool für Performance-Optimierung ist Ihr Webbrowser. Schließlich ist es auch das Werkzeug, in dem Ihre LeserInnen Ihr Produkt nutzen. Viele Maßnahmen, die ich Ihnen in diesem Artikel vorgestellt habe, lassen sich direkt im Browser checken (Caching, Komprimierung, Ladereihenfolge) – oder indirekt (Schriftgröße vor und nach dem Subsetting).

Die DevTools bieten Ihnen außerdem die wertvolle Möglichkeit, langsame Internet-Verbindungen und langsame Hardware zu simulieren. So haben Sie nicht nur Ihre alltägliche (verzerrte) Erfahrung des Wealthy Western Web, sondern Sie sehen, wie sich Ihre Website in realen Umgebungen wie z.B. schlechtem Mobilfunk verhält. Dies sollte ein selbstverständlicher Teil Ihrer Qualitätskontrolle sein, ebenso wie das Testen auf kleinen Screens!

Die Chrome DevTools bieten Ihnen aber nicht nur eine Unterstützung für die selbstständige Suche und Behebung von Performance-Problemen. Mit der kostenlosen und in jedem Chrome Browser enthaltenen Erweiterung "Lighthouse" können Sie außerdem Performance-Tests durchführen lassen. Das Ergebnis sind konkrete Empfehlungen, samt Priorisierung und erwartetem Effekt:

Bildquelle: Screenshot einer Performance-Analyse via Lighthouse im Google Chrome Browser

Lighthouse ist nicht nur im Browser verfügbar, sondern auch als Web-Tool unter pagespeed.web.dev. Sie können es sogar als Kommandozeilentool nutzen (npm install -g lighthouse bzw. npx lighthouse). Damit können Sie Tests automatisiert durchführen und die Ergebnisse zum Beispiel in Ihre Build-Prozesse einfließen lassen.

Das Profiwerkzeug: Webpagetest

Wer es etwas professioneller mag, kann Webpagetest.org nutzen. Webpagetest ist ein Online-Service für Website-Performance-Analysen. In Webpagetest können Sie sogar verschiedene Browser, Netzwerkgeschwindigkeiten und Test-Lokalitäten nutzen, um zum Beispiel zu prüfen, wie Ihre Website für Kunden aus Südamerika performt. Wie in Lighthouse erhalten Sie auch in Webpagetest-Empfehlungen zur Performance-Optimierung Ihrer Seite.

Das Besondere: Manche Optimierungen können Sie live simulieren (zum Beispiel das Lazy Loading von Bildern) und erhalten einen vorher-nachher Vergleich. Auf diese Art sehen Sie den Einfluss einer Optimierung schon bevor Sie sich die eigentliche Arbeit machen. Und diese Checks sind die beste Werbung, wenn Sie die Performance-Optimierung vor Ihren Vorgesetzten argumentieren müssen.

Bildquelle: Screenshot eines Experiments auf webpagetest.org

Außerdem können Sie in Webpagetest regelmäßige Checks durchführen lassen. Das Tool könnte also wöchentlich automatische Performance-Tests vornehmen und Sie bei einer Verschlechterung informieren.

Grundfunktionen und eine gewisse Anzahl an Tests pro Monat sind bei Webpagetest kostenlos. Für mehr Funktionalitäten und mehr Tests gibt es bezahlte Pro-Accounts. Ich empfehle, Webpagetest Pro mindestens für gelegentliche Optimierungs-Sprints einzusetzen. Die Pro-Version lässt sich monatlich kündigen. Im Alltag für gelegentliche Checks reicht die kostenlose Version häufig aus.

Einfach schön: SpeedCurve

Ein möglicher Nachteil von Webpagetest: Das Tool ist recht technisch, und es sieht auch so aus. Es gibt sehr viele Daten, und diese sind nicht immer übersichtlich dargestellt.

SpeedCurve reduziert Website Performance Reports auf die wichtigsten Metriken und stellt diese sehr hübsch und übersichtlich dar. Das Tool eignet sich damit auch hervorragend für Präsentationen und Reports. Der Fokus von SpeedCurve liegt auf Langzeit-Monitoring. Sie können also die kontinuierliche Verbesserung Ihrer Website Performance überwachen und protokollieren. Über Ausreißer können Sie sich zum Beispiel per E-Mail oder Slack benachrichtigen lassen.

SpeedCurve ermöglicht nicht nur die Analyse der eigenen Website, sondern auch den Vergleich mit Konkurrenzseiten. Neben der bloßen Darstellung von Performance-Daten liefert SpeedCurve auch konkrete Empfehlungen für mögliche Optimierungen. Diese basieren auf aktuellen Best Practices und neuesten Web Performance-Techniken. SpeedCurve ist kostenpflichtig.

Bildquelle: Screenshot von www.speedcurve.com

Performance Culture

Zum Schluss möchte ich Ihnen noch ein paar Empfehlungen mit auf den Weg geben, wie Sie die Arbeit an Ihrer Website-Performance verstetigen können. Denn Performance-Optimierung sollte kein Projekt sein, sondern ein Feature – vielleicht sogar eine Haltung. Im Arbeitsalltag ist es aber nicht immer leicht, dafür die nötige Priorisierung einzuräumen.

Die wichtigste Regel: Regressionen vermeiden! Permanentes Performance-Monitoring sagt Ihnen, wenn sich die Performance Ihrer Website verschlechtert. Dieses Monitoring können Sie vollautomatisch mit Tools wie SpeedCurve aufsetzen, halbautomatisch mit Lighthouse Tests, oder notfalls regelmäßig manuell im Browser mit pagespeed.web.dev.

Sobald sich die Performance Ihrer Website verschlechtert, ist das als Bug zu betrachten. Um dem einen "offiziellen Anstrich" zu geben, sollte Website Performance als Non-Functional Requirement in Ihre Qualitäts-Checklisten aufgenommen werden – ebenso wie Designtreue, Accessibility oder Suchmaschinen-Optimierung.

Apropos Suchmaschinen – die KollegInnen aus der entsprechenden Abteilung dürften Ihre größten Fürsprecher für Performance-Optimierung sein. Schließlich fließt Ihre Pagespeed als Faktor ins Google Ranking ein. Und ist damit ein echter Wettbewerbsvorteil.

Ihre Wettbewerber können Sie sich übrigens auch als "Cornerstone" für Ihre Performance-Bemühungen heranziehen. Setzen Sie ein Benchmark auf, und versuchen Sie, im Vergleich nicht abzurutschen – oder das schnellste Angebot im Markt zu werden!

Zusammenfassung: Website Performance Optimierung ist wichtig und gar nicht so schwer

Wir haben in diesem Blogpost gesehen, dass die Optimierung von Website Performance wichtig ist. Für das Kundenerlebnis, für das Google Ranking, für das Traffic-Budget und für den Ressourcenverbrauch. Außerdem gehört sie zum sauberen Handwerk von Web Workern dazu.

Maßnahmen der Optimierung lassen sich in zwei große Bereiche einteilen.

Beim Build bzw. bei der Auslieferung auf dem Server kann vor allem die Größe von Ressourcen reduziert werden. Komprimierung von Assets, moderne Bildformate, responsive Images und reduzierte Webfonts sparen viel Traffic und damit Ladezeit. Caching oder die Nutzung Browser-nativer Features sind die beste Reduktion – nämlich um 100%.

Die gefühlte Performance von Websites lässt sich durch geschickte Orchestrierung der geladenen Dateien verbessern. Lazy Loading, Preloading und das Vermeiden von Layout Shift sind hier zu nennen.

Und letztlich ist gute Performance-Optimierung kein einmaliges Projekt, sondern ein Teil der Produktentwicklung und des technischen Qualitätsanspruchs. Durch Performance Monitoring und eine Performance Culture lässt sie sich nachhaltig etablieren.