Zum Inhalt springen

Engineering

Auf Unternehmenswebsites ist Performance eine Design-Entscheidung

Die Core Web Vitals zu bestehen ist kein Optimierungsdurchgang am Ende. Es ist die Folge von Architektur- und Design-Entscheidungen, die am ersten Tag getroffen wurden.

Veröffentlicht: Zuletzt aktualisiert: 6 Min. LesezeitNeuros Web Team · Web Engineering

Kurz gesagt

Wie schnell muss eine Website sein und wie misst man das?

Core Web Vitals werden an drei Schwellen gemessen: Largest Contentful Paint unter 2,5 Sekunden, Interaction to Next Paint unter 200 Millisekunden und Cumulative Layout Shift unter 0,1. Eine Unternehmenswebsite besteht sie nur, wenn Performance als Budget festgeschrieben und von der Deployment-Pipeline durchgesetzt wird; ohne Budget macht jede neue Komponente die Seite ein wenig schwerer.

Geschwindigkeit ist kein Feature, das man später hinzufügt. Ohne Ressourcenbudget von Anfang an wird jede Entscheidung der Designphase still und leise zu Performance-Schulden.

Wie legt man ein Performance-Budget fest?

Legen Sie pro Seite eine Obergrenze für gesamtes JavaScript, Bildgewicht und Drittanbieter-Skripte fest. Erzwingen Sie diese Grenze in der CI, damit eine Änderung, die sie überschreitet, nicht gemergt werden kann.

  • Machen Sie Server-Komponenten zum Standard und Client-Komponenten zur Ausnahme.
  • Hosten Sie Schriften selbst und liefern Sie sie im Variable-Format aus.
  • Verlangen Sie moderne Formate und korrekte Abmessungen für Bilder.
  • Verzögern Sie Analytics- und Marketing-Skripte.

Was kostet Animation an Performance?

Scroll-gesteuerte Animation ist nur so lange günstig, wie sie bei Transform und Opacity bleibt. Alles, was Layout auslöst, kommt auf einem Mittelklasse-Smartphone als verlorene Frames zurück.

Wie misst man Core Web Vitals richtig?

Labortests reichen nicht. Ohne Real User Monitoring können Sie nicht wissen, ob die Performance tatsächlich besser geworden ist.

Core-Web-Vitals-Schwellen (Google, web.dev)
MetrikGutVerbesserungswürdigSchlecht
LCP — Largest Contentful Paint≤ 2,5 s2,5 – 4,0 s> 4,0 s
INP — Interaction to Next Paint≤ 200 ms200 – 500 ms> 500 ms
CLS — Cumulative Layout Shift≤ 0,10,1 – 0,25> 0,25

Quellen

  1. 01Core Web Vitals — LCP, INP, CLS eşikleriGoogle · web.dev · 2024
  2. 02Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2023
  3. 03DORA — DevOps Research and Assessment metrikleriGoogle Cloud · 2024

Häufige Fragen

Was oft gefragt wird

Ihre Wirkung auf das Ranking ist für sich genommen nicht entscheidend; Inhaltsqualität wiegt weiterhin schwerer. Doch eine Seite, die die Schwellen verfehlt, verliert auch die Nutzenden: Auf einer langsamen Seite geht man, bevor man den Inhalt sieht. Performance als Voraussetzung dafür zu betrachten, dass Inhalt gelesen wird, ist der treffendere Rahmen — nicht als Ranking-Taktik.

JavaScript, das den Hauptthread lange belegt. Drückt jemand einen Button, muss der Browser zuerst die anstehende Aufgabe beenden, bevor er reagieren kann — ist sie lang, verzögert sich die Interaktion. Übliche Ursachen sind große Bundles, schwere Berechnungen beim Seitenaufbau und Listener, die bei jedem Scroll feuern. Die Lösung: Code aufteilen und Arbeit hinter die Interaktion verschieben.

Nein. Ein Labortest setzt ein festes Gerät und eine feste Verbindung voraus, während echte Nutzende auf einem älteren Telefon und in einem schwankenden Netz unterwegs sind. Beides ersetzt einander nicht: Labortests fangen Regressionen ab, Real User Monitoring zeigt, welche Nutzergruppe leidet. Entscheidungen sollten beides zusammen lesen.

Sprechen wir darüber mit Ihrem Team

Wir können eine technische Session durchführen, die all das auf Ihren Kontext überträgt.