// p-01erster paint
Critical-CSS inline.
Das CSS, das der sichtbare Bereich braucht, steht direkt im HTML — kein zweiter Request, keine Render-Blockade. Die Seite baut sich beim ersten Byte auf. Das ist der direkteste Hebel auf LCP.
wirkt auf: lcp
// stack · performance
Performance.
Performance ist bei siteway keine Endkontrolle, sondern eine Bauvorgabe. Wir bauen jede Website so, dass sie die Core Web Vitals erreicht: LCP unter 2,5 s, INP unter 200 ms, CLS unter 0,1. Die Mittel dahinter sind Handwerk — Critical-CSS inline, self-hosted Fonts, schlanke Bundles und Frontend ohne Framework-Runtime.
stack
einsatz: core web vitals
ziel: lcp<2,5s · inp<200ms · cls<0,1
seit: 2006
// definition
Was sind Core Web Vitals?
Core Web Vitals sind drei Messwerte, mit denen Google die Nutzererfahrung einer Website bewertet: Ladezeit, Reaktionsfähigkeit und visuelle Stabilität. Sie übersetzen das vage „fühlt sich schnell an“ in harte Zahlen — und sind seit dem Page-Experience-Update ein Ranking-Signal.
LCP (Largest Contentful Paint) misst, wann das größte sichtbare Element steht — Zielwert unter 2,5 Sekunden. INP (Interaction to Next Paint) misst, wie schnell die Seite auf einen Klick oder Tap reagiert — unter 200 Millisekunden. CLS (Cumulative Layout Shift) misst, wie stark das Layout beim Laden noch springt — unter 0,1.
Bewertet wird am 75. Perzentil echter Seitenaufrufe: Nicht der Bestwert im Labor zählt, sondern was 75 Prozent deiner Besucher tatsächlich erleben. Genau deshalb ist Performance eine Frage der Bauweise, nicht der Nachbesserung.
// praxis
Wie wir Performance bauen.
der größte hebel ist verzicht
Die meisten Ratgeber zu Core Web Vitals enden bei „komprimiere Bilder und lade JavaScript später“. Das stimmt, greift aber zu kurz. Der entscheidende Unterschied entsteht früher — bei der Architektur. Wir bauen Websites so, dass die guten Werte das Nebenprodukt sind, nicht das Ergebnis einer Optimierungsrunde am Schluss.
Der Kern ist eine Entscheidung: kein Framework-Ballast im Frontend. Statt eine React- oder Vue-Runtime in den Browser zu schicken, liefern wir serverseitig gerendertes HTML, Tailwind-CSS und gezieltes Vanilla-JavaScript aus. Was der Browser nicht laden, parsen und ausführen muss, kann auch nichts blockieren — das drückt LCP und INP, bevor eine einzige Kilobyte-Diät nötig wird.
// p-02schriften
Self-hosted Fonts.
Schriften liegen lokal als WOFF2, werden vorgeladen und mit font-display ausgeliefert. Kein Umweg über Google Fonts, kein dritter Verbindungsaufbau — und ganz nebenbei DSGVO-sauber.
wirkt auf: lcp · cls
// p-03bundles
Minify & schlanke Bundles.
CSS und JavaScript werden minifiziert und auf das Nötige reduziert. Kein totes CSS, keine ungenutzten Bibliotheken. Weniger Bytes über die Leitung heißt schnellerer Aufbau und niedrigere Blockierzeit.
wirkt auf: lcp · inp
// p-04navigation
instant-page.
Beim Überfahren eines Links lädt die Zielseite vor, noch bevor der Klick kommt. Für den Nutzer fühlt sich der Wechsel sofort an. Das Skript ist self-hosted und wenige Kilobyte klein.
wirkt auf: gefühlte ladezeit
// p-05bilder
AVIF/WebP mit Maßen.
Bilder als AVIF und WebP, responsive ausgeliefert und immer mit width/height. Das spart Bytes fürs LCP und reserviert den Platz, damit beim Nachladen nichts springt. Details im Bild-&-Videoformate-Stack.
wirkt auf: lcp · cls
// p-06runtime
Keine Framework-Runtime.
Der stärkste Hebel auf INP: Wir schicken keine schwere JavaScript-Runtime in den Browser. Der Hauptthread bleibt frei, Eingaben werden sofort beantwortet — auch auf schwachen Geräten und in langsamen Netzen.
wirkt auf: inp
// metriken · 3 werte
Die drei Werte im Detail.
jeder wert ein eigener hebel
LCP, INP und CLS messen drei verschiedene Dinge und verlangen drei verschiedene Antworten. Wer nur an einer Schraube dreht, verschiebt das Problem. Wir behandeln jede Metrik mit den Mitteln, die auf sie wirken.
// m-01 · lcp< 2,5 s
LCP — Ladezeit.
Der Zeitpunkt, an dem das größte sichtbare Element steht — meist Hero-Bild oder Überschrift. Wir senken ihn mit Critical-CSS inline, vorgeladenem LCP-Bild, schneller Server-Antwort und ohne Render-blockierende Skripte.
mittel: critical-css · preload · avif
// m-02 · inp< 200 ms
INP — Reaktion.
Die Zeit zwischen Eingabe und sichtbarer Antwort. INP straft schweres JavaScript ab, das den Hauptthread blockiert. Unser Mittel ist strukturell: keine Framework-Runtime, wenig Vanilla-JS, kurze Total Blocking Time im Labor.
mittel: no-runtime · vanilla-js
// m-03 · cls< 0,1
CLS — Stabilität.
Wie stark das Layout beim Laden noch springt. Ursache sind Bilder ohne Maße, spät geladene Schriften und nachrutschende Einbindungen. Wir setzen feste Dimensionen, laden Schriften vor und reservieren Platz für alles, was nachkommt.
mittel: width/height · font-preload
// beleg
Der Beweis: die eigene Startseite.
gemessen, nicht behauptet
Wer Performance verkauft, sollte sie zuerst am eigenen Haus zeigen. Die Startseite von siteway erreicht in Google PageSpeed Insights 100/100/100/100 auf Mobilgeräten — Performance, Barrierefreiheit, Best Practices und SEO jeweils voll.
Der Weg dahin war lehrreich: Der teuerste Posten waren nicht CSS oder Fonts, sondern die Frame-Kosten paralleler WebGL-Shader im Hintergrund. Erst als wir die im Griff hatten, kippte der Score auf 100. Diese Erfahrung — messen, die echte Ursache finden, gezielt beheben — bringen wir in jedes Projekt mit.
Für bestehende Seiten fangen wir mit einem Page-Speed-Audit an: erst messen, wo LCP, INP und CLS klemmen, dann die Mittel von oben gezielt einsetzen.
// messung
Labor oder Feld — was zählt.
fürs ranking zählt das feld
Ein Detail, an dem viele Optimierungen scheitern: Nicht jeder gemessene Wert zählt gleich. Labordaten aus Lighthouse sind reproduzierbar und gut zum Entwickeln, bilden aber keine echten Nutzer ab. Felddaten aus dem Chrome User Experience Report (CrUX) zeigen, was Besucher mit ihren Geräten und Netzen wirklich erleben — und nur die fließen ins Ranking ein, am 75. Perzentil. INP lässt sich im Labor überhaupt nicht direkt messen; dort dient die Total Blocking Time als Näherung. Wir entwickeln gegen das Labor und prüfen gegen das Feld.
so messen wir
labor: lighthouse · devtools
feld: crux · psi · search console
basis: 75. perzentil
// faq
Häufige Fragen.
Was sind Core Web Vitals?
Core Web Vitals sind drei von Google definierte Messwerte für die Nutzererfahrung einer Website: Largest Contentful Paint (LCP) misst die Ladezeit des größten sichtbaren Elements, Interaction to Next Paint (INP) die Reaktionszeit auf Eingaben, Cumulative Layout Shift (CLS) die visuelle Stabilität. Als „gut“ gelten LCP unter 2,5 Sekunden, INP unter 200 Millisekunden und CLS unter 0,1 — gemessen am 75. Perzentil echter Seitenaufrufe.
Welche Werte gelten als gut?
LCP unter 2,5 Sekunden, INP unter 200 Millisekunden, CLS unter 0,1. Entscheidend ist nicht ein Bestwert im Labor, sondern das 75. Perzentil aller echten Seitenaufrufe: 75 Prozent deiner Besucher müssen diese Schwellen erreichen, damit die Seite als schnell gilt. siteway baut die Ziele als feste Vorgabe in jedes Projekt ein, nicht als Kür am Ende.
Mit welchen technischen Mitteln erreicht ihr diese Werte?
Wir liefern das kritische CSS inline im ersten HTML aus, minifizieren CSS und JavaScript, hosten Schriften lokal statt über Google Fonts, laden Folgeseiten per instant-page vor und halten die Bundles schlank. Der größte Hebel ist Verzicht: Wir bauen ohne Framework-Runtime im Frontend, damit kein Megabyte JavaScript den Hauptthread blockiert. Das drückt LCP und INP, bevor überhaupt gemessen wird.
Was ist der Unterschied zwischen Lab- und Felddaten?
Labordaten stammen aus einem simulierten Testlauf, etwa aus Lighthouse — reproduzierbar, aber ohne echte Nutzer. Felddaten stammen aus dem Chrome User Experience Report (CrUX) und bilden ab, was echte Besucher erleben. Für das Google-Ranking zählen die Felddaten am 75. Perzentil. Wir optimieren im Labor, prüfen aber gegen die Felddaten, weil nur die über Sichtbarkeit entscheiden.
Warum baut ihr ohne Framework-Runtime im Frontend?
Weil eine Framework-Runtime im Browser Kosten verursacht, die niemand sieht: JavaScript wird geladen, geparst und ausgeführt, bevor die Seite reagiert. Genau das treibt INP nach oben und verzögert den Aufbau. Für inhaltsgetriebene Websites reichen serverseitig gerendertes HTML, Tailwind-CSS und gezieltes Vanilla-JavaScript. So bleibt der Hauptthread frei und die Seite schnell — auf schwachen Geräten und langsamen Netzen genauso wie im Testlabor.
Sind Core Web Vitals ein Ranking-Faktor?
Ja, seit dem Page-Experience-Update ist die Ladeerfahrung ein Google-Ranking-Signal. Es ist aber kein Turbo, der schwachen Inhalt nach oben trägt: Relevanz und Qualität wiegen schwerer. Bei zwei inhaltlich gleich starken Seiten gibt die bessere Performance den Ausschlag. Deshalb behandeln wir Core Web Vitals als Pflicht-Basis, nicht als Wachstumshebel.
Könnt ihr eine bestehende Website messbar schneller machen?
Ja. Wir prüfen zuerst mit einem Page-Speed-Audit, wo LCP, INP und CLS klemmen, und leiten daraus konkrete Maßnahmen ab. Die Umsetzung — Critical-CSS, Bildformate, Bundle-Diät, Font-Hosting — läuft als buchbare Leistung Performance & Core Web Vitals. Als Beleg, dass die Mittel tragen: Die eigene Startseite von siteway erreicht in PageSpeed Insights 100/100/100/100 auf Mobilgeräten.
// womit das zusammenhängt
Womit das zusammenhängt.
leistung & stack
// leistung · buchbar
Performance & Core Web Vitals.
Die Technik von hier als beauftragbare Leistung: LCP, INP und CLS auf grün — für deine Website.
weiterlesen →
// stack · media
Bild- & Videoformate.
AVIF und WebP mit festen Maßen — der größte Einzelposten für LCP und CLS, im Detail erklärt.
zum stack →
// stack · build
Deployment & Betrieb.
Minify, Cache-Busting und Auslieferung laufen in der Pipeline — wie wir bauen und deployen.
zum stack →
// Website, die die Core Web Vitals erreicht?
Projekt anfragen