--- title: "Web-Performance | Digital Cuisine" description: "Ladezeit, Reaktionszeit und visuelle Stabilität überprüfbar machen. Core Web Vitals im Feld, Laborbudgets im Release-Gate und ein abgegrenzter Performance-Check von digital cuisine." url: "https://cuisine.digital/leistungen/web-performance" lang: de generated: cuisines-markdown-v1 --- 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](https://cuisine.digital/kontakt)[Arbeiten ansehen](https://cuisine.digital/referenzen.md) ## 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 Paint** Wann 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 Paint** Wie 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 Shift** Wie 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 Server** Wir 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 Reihenfolge** Das 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 Sprung** Wir 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 Budget** Jedes 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 ausgeliefert** Diese 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 Fallback** Suche, 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 Ausgangslage** Gemessene 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 sortiert** Was 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 Vorlagen** Grenzwerte 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 Pipeline** Wie 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. ## Wo Performance hingehört Die Seiten, auf denen dieselben Regeln greifen. [Websites & Content-Plattformen](https://cuisine.digital/leistungen/websites.md) Struktur, Design und Content-Management, in denen Performance von Anfang an eine Anforderung ist. [Next.js](https://cuisine.digital/leistungen/nextjs.md) Das Framework hinter dieser Website, mit Server Components und Auslieferung an der Edge. [Zertifizierungen](https://cuisine.digital/zertifizierungen.md) Das Managementsystem, aus dem unsere Review- und Freigabeschritte stammen. [IT-Services](https://cuisine.digital/it-services.md) Betrieb, Monitoring und Updates, damit gute Werte auch nach dem Go-live gute Werte bleiben. ## Webprojekte aus unserer Arbeit ![iF Design: Website Relaunch](https://cuisine.digital/images/projects/master/if-design-website/image.webp) iF Design ## Website Relaunch [Projekt ansehen](https://cuisine.digital/projekte/if-design-award-website-relaunch.md) ![OSMA Aufzüge: Website mit eigener Komponentenbibliothek](https://cuisine.digital/images/projects/master/osma/image.webp) OSMA Aufzüge ## Website mit eigener Komponentenbibliothek [Projekt ansehen](https://cuisine.digital/osma-website) ![RECARO: Website-Relaunch](https://cuisine.digital/images/projects/recaro-website/devices.webp) RECARO ## Website-Relaunch [Projekt ansehen](https://cuisine.digital/recaro-website) ![BAHLSEN: Websites für starke Marken](https://cuisine.digital/images/projects/master/bahlsen/image.webp) BAHLSEN ## Websites für starke Marken [Projekt ansehen](https://cuisine.digital/bahlsen-markenwebsites) ![FriEnt: Publikationen besser finden](https://cuisine.digital/images/projects/master/frient/image.webp) FriEnt ## Publikationen besser finden [Projekt ansehen](https://cuisine.digital/frient-website) ![Gartenheim: Neuer Auftritt für die Genossenschaft](https://cuisine.digital/images/projects/master/gartenheim/image.webp) Gartenheim ## Neuer Auftritt für die Genossenschaft [Projekt ansehen](https://cuisine.digital/gartenheim-website) ![Linde: Globale Internetpräsenz](https://cuisine.digital/images/projects/master/linde-worldwide/image.webp) Linde ## Globale Internetpräsenz [Projekt ansehen](https://cuisine.digital/linde-worldwide-web) 40 internationale Linde-Websites: Sitecore-Implementierung, Content-Migration, Azure-Betrieb und laufende technische Weiterentwicklung seit 2014. ![SAP: Corona-Warn-App Support](https://cuisine.digital/images/projects/master/corona-warn-app/image.png) SAP ## Corona-Warn-App Support [Projekt ansehen](https://cuisine.digital/corona-warn-app-support) ![SCHMIDHUBER: Individuelle Website-Komponenten](https://cuisine.digital/images/projects/master/schmidhuber/image.webp) SCHMIDHUBER ## Individuelle Website-Komponenten [Projekt ansehen](https://cuisine.digital/schmidhuber-website) ![Vimcar: Corporate Website & Checkout](https://cuisine.digital/images/projects/master/vimcar/image.webp) Vimcar ## Corporate Website & Checkout [Projekt ansehen](https://cuisine.digital/vimcar-website) Der nächste Schritt ## Wie schnell ist Ihre Website wirklich? Erzählen Sie uns von Ihrer Idee oder Herausforderung. Wir klären gemeinsam, was sinnvoll ist und wie wir Sie unterstützen können. [Termin buchen (30 Min.)](https://outlook.office.com/book/AIcuisine@cuisine.digital/) --- [Originalseite](https://cuisine.digital/leistungen/web-performance) · [Kontakt und Projektanfrage](https://cuisine.digital/kontakt)