Web-Performance

Schnell ist kein Gefühl.
Es ist ein Messwert.

Wir machen Ladezeit, Reaktionszeit und visuelle Stabilität überprüfbar. Mit Felddaten aus echten Besuchen, mit klar gekennzeichneten Laborbudgets im Release-Gate und mit einer Umsetzung, die beides einhält.

Projekt besprechen Arbeiten ansehen

Drei Werte beschreiben, was Besucher erleben

Google bewertet die Core Web Vitals im Feld, also bei echten Besuchen. Maßgeblich ist das 75. Perzentil der Seitenaufrufe, getrennt nach Mobil und Desktop. Drei von vier Aufrufen müssen den guten Bereich erreichen. Ein Durchschnitt reicht nicht.

Largest Contentful PaintWann erscheint der größte sichtbare Inhalt, meist das Titelbild oder die Überschrift. Als gut gilt ein Wert bis 2,5 Sekunden. Entscheidend ist der Moment, in dem die Seite für den Besucher da ist, nicht der Moment, in dem der Server geantwortet hat.

Interaction to Next PaintWie lange dauert es, bis die Seite auf eine Eingabe sichtbar reagiert. Als gut gilt ein Wert bis 200 Millisekunden. Gemessen wird über den ganzen Besuch, also auch der Filter, der erst nach dem Scrollen geklickt wird.

Cumulative Layout ShiftWie stark verschiebt sich das Layout, während die Seite lädt. Als gut gilt ein Wert bis 0,1. Nachgeladene Schriften, Bilder ohne feste Maße und spät eingefügte Hinweisleisten sind die häufigsten Ursachen.

Labor und Feld messen nicht dasselbe

Ein Lighthouse-Lauf ist ein Labortest. Er lädt eine Seite einmal kalt, auf einem simulierten Mittelklasse-Gerät, mit gedrosselter Verbindung, ohne Verlauf, ohne warmen Cache und ohne angemeldeten Nutzer. Schon deshalb schwanken die Werte zwischen zwei Läufen derselben Seite. Ein Teil der Punkte stammt zudem aus Kennzahlen, die bei echten Besuchern gar nicht entstehen.

Ein Standardlauf bildet den Seitenaufruf ab, nicht den Besuch. Scrollen, Formulare, Einwilligungsdialoge und die erste Berührung auf dem Handy prüfen wir deshalb zusätzlich, mit eigenen Nutzerflüssen im Labor und mit Felddaten. Lighthouse kann solche Abläufe messen, ein Aufrufwert allein zeigt sie nur nicht.

Für die Bewertung zählen die Felddaten. Wo der Chrome UX Report eine ausreichende Datenbasis hat, nutzen wir ihn, ergänzt um eigene Messungen im Browser Ihrer Besucher. Berichtet wird das 75. Perzentil, weil Google danach bewertet. Zusätzlich betrachten wir das 90. Perzentil, um zu sehen, wie schlecht es für die langsamsten Besuche wird. Beide Werte kennzeichnen wir getrennt.

Unser eigenes Release-Gate

Diese Website ist unser Prüfstand. Jede veröffentlichte Seite läuft vor dem Deployment durch ein Qualitätsgate in der Pipeline. Lighthouse misst dreimal kalt je Profil, für Desktop und für Handy. Der Median der Performance muss auf dem Desktop mindestens 98 und auf dem Handy mindestens 95 erreichen. Barrierefreiheit, Best Practices und SEO müssen in jedem einzelnen Lauf bei 100 liegen. Reißt ein Wert, blockiert das Gate die Auslieferung.

Das Gate ist eine Untergrenze, kein Ziel im Reporting. Es hält Regressionen auf, bevor sie live gehen, und es zwingt uns, jede neue Seite unter denselben Bedingungen zu prüfen wie die erste. Was Ihre Besucher tatsächlich erleben, sagt es nicht. Dafür sind die Felddaten da.

Laborbudgets

Was diese Zahlen sind, und was nicht

Desktop-Performance mindestens 98, Handy-Performance mindestens 95, Barrierefreiheit, Best Practices und SEO jeweils 100. Das sind Budgets aus einem Labortest und die Freigabeschwelle unserer Pipeline. Sie sind keine Felddaten, kein aktuelles Messergebnis und keine Aussage darüber, wie schnell ein einzelner Besuch war.

Ein belastbares Messergebnis nennt immer das Datum, das Profil, den geprüften Seitenumfang und den Stand der Software. Wo wir Ergebnisse zeigen, stehen diese Angaben dabei. Wo sie fehlen, handelt es sich um ein Budget.

Woraus die Geschwindigkeit entsteht

Performance ist kein Nachgang. Sie entsteht aus Entscheidungen in der Architektur, die sich später nur noch teuer korrigieren lassen.

Rendern auf dem ServerWir bauen mit React Server Components. Was nicht interaktiv sein muss, wird auf dem Server gerendert und kommt als fertiges HTML an. Im Browser landet nur das JavaScript, das dort eine Aufgabe hat.

Bilder in der richtigen ReihenfolgeDas Bild, das den größten sichtbaren Inhalt ausmacht, wird bevorzugt geladen und in passenden Größen ausgeliefert. Alles unterhalb des Sichtbereichs kommt später. Jedes Bild bringt seine Maße mit, damit nichts nachrutscht.

Schriften ohne SprungWir hosten unsere Schriften selbst, laden den wichtigsten Schnitt vorab und hinterlegen eine Ersatzschrift mit angeglichenen Metriken. Der Text ist sofort lesbar und rutscht beim Wechsel auf die endgültige Schrift nicht um.

Drittsysteme mit BudgetJedes externe Skript kostet Ladezeit und Reaktionsfähigkeit. Wir binden Drittsysteme asynchron ein, geben ihnen ein Performance-Budget und prüfen es im Gate. Was das Budget nicht einhält, wird ersetzt oder fällt raus.

An der Edge ausgeliefertDiese Website läuft als Next.js-Anwendung auf Cloudflare Workers, nah am Besucher, mit Bildoptimierung an derselben Edge. Vorgerenderte Seiten kommen aus dem Cache an derselben Edge, ohne dass dafür ein eigener Server anspringen muss.

Fremdsysteme mit Cache und FallbackSuche, Formulare, Preise oder Bestände kommen oft aus Systemen, die wir nicht kontrollieren. Wir cachen deren Antworten, setzen Zeitgrenzen und halten eine Rückfallebene bereit. Ist das Fremdsystem langsam, bleibt Ihre Seite benutzbar.

Ein Beispiel von dieser Website

Der Hero unserer Startseite trägt eine Animation. Sie startet erst, wenn die Seite gezeichnet ist und der Browser Luft hat, auf dem Handy also spürbar nach dem ersten Bild. Der statische Hero steht vorher, der gemessene Ladewert bleibt davon unberührt.

Genau deshalb beginnt die Arbeit danach. Wir prüfen, ob die Seite mit laufender Animation weiter auf Eingaben reagiert, ob die Bewegung anhaltbar ist und ob sie die Systemeinstellung für reduzierte Bewegung respektiert. Ein guter Wert beim Aufruf beschreibt eben nicht den ganzen Besuch.

Barrierefreiheit gehört zur Umsetzung

Wir setzen WCAG 2.2 AA als Ziel der Umsetzung. Das heißt Landmarks und eine tragfähige Überschriftenstruktur, ausreichende Kontraste, vollständige Bedienbarkeit per Tastatur, sichtbare Fokuszustände, beschriftete Formularfelder und verständliche Fehlermeldungen.

Geprüft wird automatisiert und von Hand. Automatische Prüfungen finden einen Teil der Probleme, den Rest findet nur, wer die Seite mit der Tastatur und mit einem Screenreader bedient. Ein Lighthouse-Wert von 100 in der Kategorie Barrierefreiheit ist deshalb kein Konformitätsnachweis. Und ein Overlay-Widget ersetzt keine barrierefreie Umsetzung.

Diese Website lädt keine Tracker

Auf cuisine.digital binden wir keine Analyse- und keine Werbeskripte ein. Deshalb gibt es hier keinen Einwilligungsdialog. Das ist eine Entscheidung für unsere eigene Website und kein Beleg dafür, dass Marketing-Messung ohne Einwilligung auskommt. Sobald Sie Kampagnen messen wollen, brauchen Sie Einwilligungen und eine Architektur, die sie respektiert. Das ist ein eigenes Thema und gehört nicht in ein Performance-Budget.

Der Performance-Check

Ein abgegrenzter Check mit einem Ergebnis, das Sie weiterverwenden können. Vorher vereinbaren wir, welche Seiten, Vorlagen und Wege wir prüfen und welche Zugänge wir dafür brauchen.

Eine dokumentierte AusgangslageGemessene Werte mit Datum, Profil, Gerät und geprüftem Umfang. Wo Felddaten fehlen, etwa weil der Chrome UX Report für Ihre Seiten keine ausreichende Datenbasis hat, steht das ausdrücklich im Bericht.

Befunde nach Wirkung sortiertWas bremst, wo es entsteht und welche Besucher es trifft. Wir trennen dabei, was in der Vorlage liegt, von dem, was einzelne Inhalte oder Drittsysteme verursachen.

Budgets für Ihre VorlagenGrenzwerte je Seitentyp für Ladezeit, Reaktionszeit, Layoutstabilität und Skriptgewicht, jeweils mit Prüfkriterium. Als Laborbudget im Gate und als Feldziel im Betrieb, klar voneinander getrennt.

Ein Vorschlag für Ihre PipelineWie die Prüfung in Ihren Build läuft, welche Seiten sie abdeckt, wann sie blockiert und wer die Berichte bekommt. Mit Aufwandsschätzung und Kriterien für die Abnahme.