Langsam durch Fehler vs. langsam durch Design: Ein Web-Performance-Framework

Langsam durch Fehler vs. langsam durch Design.

Wenn Sie mich beauftragen, um die Core Web Vitals zu reparieren oder darüber zu sprechen, werden Sie mich irgendwann über langsam durch Fehler vs. langsam durch Design sprechen hören. Ich halte dies für eine entscheidende Unterscheidung und in diesem Artikel werde ich erklären, wie Ihnen das bei der Verbesserung der Core Web Vitals helfen wird.

Zuletzt überprüft von Arjen Karel im März 2026

Wenn mich jemand bittet, zu beraten und die Core Web Vitals zu beheben, läuft immer etwas falsch. Langsamkeit resultiert immer aus Anti-Pattern. Zum Beispiel ein 'Lazy Loaded Largest Contentful Paint Bild', 'Große, unoptimierte Bilder', 'Slider', 'blockierendes JavaScript' und so weiter.

Es bedarf nicht viel, um ein Anti-Pattern einzuführen. Manchmal reicht es schon aus, ein Plugin zu installieren oder Best Practices für einen kurzen Moment zu vergessen, um ein Anti-Pattern zu erzeugen.

Nun kategorisiere ich diese Anti-Pattern gerne in 'langsam durch Fehler' und 'langsam durch Design', da meine Herangehensweise zur Behebung dieser Probleme komplett gegensätzlich ist.

Laut dem 2025 Web Almanac bestehen nur 48 % der mobilen Ursprünge alle drei Core Web Vitals. Meiner Erfahrung nach resultiert die Mehrheit dieser Ausfälle aus 'langsam durch Fehler'-Problemen, die in wenigen Stunden behoben werden können.

Langsam durch Fehler

Ich liebe 'langsam durch Fehler'-Anti-Pattern. Sie haben etwas getan, das die Seite verlangsamt hat. Sie haben einen Fehler gemacht. Sie wussten nicht, dass es einen viel schnelleren Weg gibt, dies zu tun. Keine Sorge, ich kann Fehler beheben.

Daher ist die Kategorisierung dieser 'Fehler' sinnvoll. Sie liefert mir eine Liste von leicht zu behebenden Verbesserungen mit hoher Wirkung, die ich an Ihr Dev-Team senden (oder selbst beheben) kann. Meist bedarf es hier nur sehr wenig Diskussion. Die Verbesserung dieser Anti-Pattern ist schlichtweg logisch und nachvollziehbar. Sobald sie behoben sind, verbessern sich die Core Web Vitals.

Hier sind einige Beispiele für Anti-Pattern, denen ich täglich begegne. Wenn ich erkläre, was sie bewirken und warum, höre ich meistens: 'Ohh, ich wusste nicht, dass das die Seite verlangsamt'.

1. Bilder ohne Lazy Loading

Das häufigste Anti-Pattern sind Bilder ohne Lazy Loading. Bilder, die nicht per Lazy Loading geladen werden, werden bereits in der frühen Phase des Seitenladevorgangs zum Download in die Warteschlange gestellt. Das verbraucht Netzwerk- und CPU-Ressourcen. Es macht keinen Sinn, wertvolle Ressourcen für Bilder zuzuweisen, die noch gar nicht sichtbar sind, oder? Erfahren Sie mehr über das Zurückstellen von Offscreen-Bildern (deferring offscreen images).

Der gegenteilige Fehler ist genauso häufig: Lazy Loading des LCP-Bildes. Etwa 15 % der Websites machen dies, was dazu führt, dass das wichtigste Bild der Seite langsamer statt schneller geladen wird.

2. Drittanbieter-Schriftarten

Web-Schriftarten sind großartig. Sie individualisieren und verbessern das Look-and-Feel der Seite. Leider wird die Nutzung eines Drittanbieters wie Google Fonts die Schriftarten nicht für Ihre spezifische Situation optimieren.

Drittanbieter-Schriftarten erfordern ein zusätzliches Render-blockierendes Stylesheet, eine neue Verbindung zu einem Webserver (während Sie bereits diese sehr schnelle Verbindung zu Ihrem Ursprungsserver haben) und fügen dem Browser wahrscheinlich mehr Schriftarten hinzu, als Sie tatsächlich nutzen.

Es wäre wesentlich sinnvoller, Ihre Schriftarten selbst zu hosten, sie vorzuladen und jeder Schriftart-Datei eine benutzerdefinierte Strategie zum Laden von Schriftarten zuzuweisen. Das ist direkt ein weiterer Quick Win!

3. Drittanbieter-Skripte

Obwohl grundsätzlich nichts gegen Drittanbieter-Skripte spricht, verursachen sie oft massive Probleme durch die Art und Weise, wie sie in Seiten eingebunden werden. Ich stoße regelmäßig auf unwichtige Drittanbieter-Skripte (wie Facebook-Tracking-Pixel, Social-Media-Buttons, Bewertungs-Widgets usw.), die tatsächlich die gesamte Seite blockieren.

Es ist relativ einfach und absolut sinnvoll, diese Skripte zurückzustellen und so zu terminieren, bis der Browser die wichtigere Arbeit erledigt hat. Letztendlich ändere ich nichts Kritisches an der Website; sie sieht unverändert aus und lädt deutlich schneller. Ich ändere lediglich die Reihenfolge, in der die Dinge ausgeführt werden.

4. Hintergrundbilder

Aus Sicht der Core Web Vitals machen Hintergrundbilder wenig Sinn. Hintergrundbilder bieten keine native Unterstützung für Lazy Loading, sie sind nicht responsiv und Sie haben kaum Kontrolle über ihr Timing und ihre Priorität.

Mit ein paar einfachen Fixes können wir diese Hintergrundbilder in normale Bilder transformieren, die wir per Lazy Loading laden, responsiv machen und in ihrer Priorität anpassen können. Das wird den Largest Contentful Paint mit Sicherheit verbessern.

5. Große Stylesheets

Stylesheets sind Render-blockierend. Das bedeutet, dass die Seite leer bleibt, während der Browser die Stylesheets lädt. Es gibt viele Dinge, die Sie tun können, um dies zu beheben. Zum Beispiel: nicht verwendetes CSS entfernen, das Stylesheet aufteilen, das Browser-Caching verbessern oder Critical CSS hinzufügen.

Sobald wir die Stylesheets optimiert haben, werden sich Ihr Largest Contentful Paint und First Contentful Paint dramatisch verbessern!

Langsam durch Design

Langsam durch Design ist der Teil, über den Sie sich Sorgen machen sollten. Sie haben strukturelle Entscheidungen getroffen, die die Seite verlangsamt haben. Diese umfassen in der Regel UX-Design-Entscheidungen oder JavaScript-Code, der den sichtbaren Teil der Seite in einem Ausmaß modifiziert, für das es keine guten Workarounds gibt.

Das Problem bei 'langsam durch Design' ist, dass es nicht sofort durch kleine Änderungen behoben werden kann. Es erfordert mehr Planung und das Umschreiben einiger Kernfunktionen der Website.

Als Erstes muss ich die Intention herausfinden: Warum haben Sie das getan? Was waren die Überlegungen und was genau wollten Sie erreichen? Und dann innerhalb dieser Parameter eine bessere Alternative finden!

Hier sind einige Beispiele für die häufigsten 'langsam durch Design'-Fehler.

1. Slider

Slider funktionieren normalerweise so: Wenn die Seite gerendert wird, injiziert ein JavaScript den Slider in die Seite. Ohne dieses JavaScript würde die Seite völlig anders aussehen. Dies verursacht einen längeren Largest Contentful Paint, wahrscheinlich einen Layout Shift und sehr wahrscheinlich Probleme mit dem Interaction to Next Paint (INP).

Es gibt keinen Quick Fix. Das Zurückstellen des JavaScripts wird die Paint-Metriken verbessern, aber den Slider verzögern und einen Layout Shift verursachen. Das Slider-Skript als 'critical' einzustufen, wird den Layout Shift beheben, aber die Paint-Metriken verlangsamen.

Die Lösung besteht in einem Progressive Enhancement der Seite. Stellen Sie zuerst sicher, dass der Slider ohne JavaScript gerendert wird, und erweitern Sie dann die Seite, indem Sie das bereits vorhandene Slider-Bild in einen vollständigen Slider transformieren.

Das Kuriose dabei ist: Nur etwa 1 % der Besucher klicken tatsächlich auf einen Slider. In 9 von 10 Fällen, wenn ich das erkläre, schlägt der Website-Betreiber sofort vor, den Slider zu entfernen. Deshalb ist es so wichtig, nach den Intentionen und Überlegungen für diese Slider zu fragen. Meistens waren sie 'einfach nur da'.

2. Produkt-Zoom

Ein Produkt-Zoom funktioniert so: In einem durchschnittlichen Onlineshop fahren Sie mit der Maus über ein Produktbild und können in einen Teil des Produkts hineinzoomen. 'Produkt-Zooms' haben meistens das gleiche Problem wie Slider. Ein Stück JavaScript-Code nimmt Ihre Bilder, versteckt sie und schreibt sie dann als zoombare Bilder neu auf die Seite. Dies verursacht einen längeren Largest Contentful Paint, wahrscheinlich einen Layout Shift und höchstwahrscheinlich Probleme mit dem Interaction to Next Paint (INP).

Der Unterschied zum Slider ist, dass kein Product Owner jemals sagen wird: "Oh, entfernen Sie einfach diese Funktion". Sie ist wichtig und steigert die Conversion.

Die Lösung ist dieselbe wie beim Slider-Fix. Das Zoom-Skript sollte nicht die Originalbilder verbergen, sondern die Funktionalität des Produktbildes erweitern. Leider lässt sich die Zoom-Funktion in der Regel nicht einfach reparieren und erfordert etwas Arbeit, um sie genau richtig hinzubekommen.

3. Inline-jQuery / Inline-JavaScript-Abhängigkeiten

Inline-jQuery ist ein Problem, das als 'langsam durch Fehler' begann, sich aber mit der Zeit verschlimmerte. Etwa 50 % der Websites, die ich mir ansehe, leiden unter diesem Problem. Laut W3Techs läuft jQuery noch immer auf rund 70 % aller Websites, das wird also nicht so schnell verschwinden. Weil Inline-Skripte von einem früheren Skript abhängen (meistens jQuery), können Sie jQuery nicht mehr zurückstellen. Dies verzögert sämtliche Paint-Metriken.

Der Fix ist einfach: Verschieben Sie diese Skripte einfach in ein externes Skript. Jetzt können Sie sowohl jQuery als auch das benutzerdefinierte Skript zurückstellen.

Warum habe ich das dann in die Kategorie 'langsam durch Design' eingeordnet? Wenn ich nach Intention und Überlegung frage, höre ich meistens 'Oh, ich weiß nicht'. Und genau das ist das eigentliche Problem. Es fehlt an Wissen darüber, wie JavaScript funktioniert. Ich kann mir ziemlich sicher sein, dass dieser Fehler in Zukunft wiederholt wird. Das bedeutet, dass die Lösung nicht dasselbe ist wie der Fix. Ich muss das Dev-Team über JavaScript-Abhängigkeiten und Timing aufklären.

4. Große (Hero-)Bilder

Ein weiteres 'langsam durch Design'-Problem sind große Bilder. Manche Websites müssen das Publikum einfach mit vielen hochauflösenden Bildern 'beeindrucken'. Stellen Sie sich vor, Sie verkaufen Poster. Sie würden Ihren Besuchern wahrscheinlich hochwertige, große Bilder präsentieren wollen. Diese Bilder werden, egal wie sehr Sie sie optimieren, immer länger zum Herunterladen brauchen als kleinere Bilder.

An diesem Punkt (vorausgesetzt, dass alle Bilder optimiert sind) ist das Einzige, was ich tun kann, zu prüfen, ob es noch Spielraum gibt. Brauchen wir wirklich 4K-Bilder oder würde Full-HD auch ausreichen? Sehen Sie sich an, wie man langsame Hero-Bilder repariert, um praktische Techniken zu erhalten.

5. Interaktive Karten

Ein weiteres Problem, das mir häufig begegnet, sind interaktive Karten. Wenn eine Seite eine interaktive Karte hat, besteht die gesamte Absicht dieser Seite darin, den Besucher zur Interaktion mit der Karte zu bewegen. Offensichtlich wird es einige Zeit dauern, bis diese Karte geladen ist.

Daran führt kein Weg vorbei. Wir müssen eine gewisse Langsamkeit akzeptieren. Aber es gibt Dinge, die wir tun können. Wir können sicherstellen, dass die Karten mit der höchsten Priorität geladen werden. Normalerweise sind diese Seiten nicht für eine frühe JavaScript-Ausführung optimiert. In diesem Fall war das die falsche Wahl. Wir müssen das Skript so früh wie möglich herunterladen und ausführen! Ich habe einen vollständigen Leitfaden darüber geschrieben, wie man Google Maps einbindet, ohne PageSpeed zu verlieren.

6. Langsame APIs

'Langsam durch Design'-Probleme, die aus langsamen APIs resultieren, finden sich meist auf SPA-Websites wie React, Next.js oder Angular. Langsame APIs verursachen in der Regel große Layout Shifts, da Komponenten nach einer Benutzerinteraktion zu spät gerendert werden. Solche Probleme erfordern normalerweise einen teamübergreifenden Ansatz.

Es kann nützlich sein, bei den Core Web Vitals zwischen langsam durch Fehler und langsam durch Design zu unterscheiden. Langsam durch Fehler lässt sich meist leicht beheben, während langsam durch Design einen wesentlich fundierteren, mehrdimensionalen Ansatz erfordert. Sobald Sie die 'langsam durch Fehler'-Probleme kategorisiert und behoben haben, richten Sie Real User Monitoring ein, um die Auswirkungen zu tracken. Felddaten verraten Ihnen, ob Ihre Fixes die Erfahrung für echte Besucher tatsächlich verbessert haben. Die 'langsam durch Design'-Probleme werden dann in Ihren Daten deutlich hervorstechen, denn sie sind das, was übrig bleibt.