Performance ist einer der wenigen Bereiche im Webdesign, in denen sich Fortschritt messen lässt. Es gibt Kennzahlen, es gibt Werkzeuge, und die Ursachen sind in aller Regel dieselben vier: zu große Bilder, zu viele Skripte, langsam antwortender Server, blockierende Schriften.
Wer diese vier abarbeitet, hat den größten Teil erledigt. Alles darüber hinaus ist Feinarbeit mit abnehmendem Ertrag.
Die drei Kennzahlen, die zählen
LCP (Largest Contentful Paint) misst, wann das größte sichtbare Element im ersten Bildschirm dargestellt ist, meist ein Bild oder eine Überschrift. Als gut gilt unter 2,5 Sekunden. Häufigste Ursache für schlechte Werte: ein unkomprimiertes Hero-Bild.
INP (Interaction to Next Paint) misst, wie schnell die Seite auf eine Eingabe reagiert. Als gut gilt unter 200 Millisekunden. Häufigste Ursache für schlechte Werte: zu viel JavaScript, das den Hauptprozess belegt, oft aus Tracking- und Consent-Werkzeugen.
CLS (Cumulative Layout Shift) misst, wie stark der Inhalt beim Laden verrutscht. Als gut gilt unter 0,1. Häufigste Ursache: Bilder ohne Größenangabe, nachgeladene Werbeflächen und Schriften, die eine andere Größe haben als die Ersatzschrift.
Alle drei werden mobil gemessen, weil dort die Mehrheit der Besucher unterwegs ist. Details und Messwege in Core Web Vitals und Ladezeit messen.
Die Reihenfolge mit dem größten Effekt
- Bilder. Richtige Größe, moderne Formate, Kompression, verzögertes Laden für alles unterhalb des ersten Bildschirms. Das ist bei fast jeder Seite die größte Einzelverbesserung. Siehe Bilder optimieren.
- Skripte reduzieren. Jedes eingebundene fremde Skript kostet. Zwei Tracking-Werkzeuge, ein Chat-Widget, eine Kartenansicht und ein Consent-Banner ergeben zusammen mehr Ladezeit als der komplette Inhalt der Seite.
- Schriften. Maximal zwei Familien mit den tatsächlich benutzten Schnitten, lokal ausgeliefert, mit
font-display: swap. Siehe Webfonts optimieren. - Serverseite. Aktuelle Software-Version, Kompression aktiv, Caching eingeschaltet. Bei einem CMS ist ein Seiten-Cache die wirksamste Einzelmaßnahme. Siehe Caching und CDN.
- Layoutstabilität. Breite und Höhe an jedem Bild, reservierter Platz für nachgeladene Elemente.
Diese Reihenfolge ist nach Wirkung sortiert, nicht nach Aufwand. Punkt 1 und 3 sind an einem Nachmittag zu erledigen und bringen bei einer typischen Seite mehr als jede Servermaßnahme.
Was nichts oder kaum etwas bringt
Der Wechsel auf ein “schnelles” Theme, während der Rest bleibt. Wenn die Bilder zu groß sind, ist das Theme nicht das Problem.
Ein CDN für eine rein lokale Zielgruppe. Wer Kundschaft im Umkreis von fünfzig Kilometern hat, gewinnt durch weltweite Verteilung fast nichts. Die Ausnahme ist die Auslieferung statischer Dateien, die ohnehin mitkommt.
Minifizierung als Einzelmaßnahme. Bringt Kilobytes, während Bilder Megabytes kosten.
Punktejagd in Testwerkzeugen. Ein Testergebnis von 100 auf dem Desktop ist bedeutungslos, wenn die mobilen Felddaten schlecht sind. Gemessen wird, was Besucher erleben, nicht was ein Labortest ausgibt.
Der Zusammenhang mit den anderen Bereichen
Performance ist keine eigenständige Disziplin, sondern eine Folge von Entscheidungen, die anderswo getroffen wurden. Ein Pagebuilder, der auf jeder Seite dreißig Kilobyte CSS und vier Skripte lädt, ist eine Performance-Entscheidung, getroffen bei der Systemwahl. Ein Hoster mit alter PHP-Version ebenso. Ein Bildkonzept mit fünf großformatigen Fotos pro Seite auch.
Deshalb ist der beste Zeitpunkt für Performance-Arbeit nicht nach dem Livegang, sondern bei der Systemwahl in Baukasten und CMS und bei der Hosting-Entscheidung in Hosting.