Zum Inhalt springen
Core Web Vitals Spezialisten

Grundlagen & Strategie

Ladezeit ist kein Selbstzweck, sondern eine Kette aus Netzwerk, Server, Übertragung und Darstellung im Browser. Diese Kategorie legt die Grundlagen: Wie entsteht eine Seitenanzeige technisch, welche Schritte blockieren sich gegenseitig, warum sind Messwerte im Labor und im Feld unterschiedlich, und welche Reihenfolge bringt bei begrenztem Budget den größten Effekt? Wir ordnen typische Empfehlungen ein, trennen wirksame Maßnahmen von Kosmetik und zeigen, wie sich Optimierung dauerhaft im Betrieb verankern lässt — mit Budgets für Seitengewicht, Prüfungen vor jeder Veröffentlichung und klaren Zuständigkeiten. Dazu kommen Beiträge zu Nachhaltigkeit: Weniger übertragene Daten bedeuten weniger Energie pro Seitenaufruf. Ergänzend ordnen wir ein, welche Kennzahlen sich für Berichte an die Geschäftsführung eignen und welche nur im technischen Team weiterhelfen.

Nachhaltige Websites: vom Byte zum Gramm CO2Weniger BytesBilder, JavaScript, Fonts schlank haltenWeniger EnergiekWh im Rechenzentrum und EndgerätWeniger CO2kleinerer Fußabdruck je AufrufWoraus die Seiten-Emissionen entstehenBilder69,6 %JavaScript20,8 %Schriften4,8 %CSS3,1 %HTML1,7 %SWD-Modell, 90. Perzentil (HTTP Archive Web Almanac)Seitengewicht senken-75 %weniger Bytesvon 2,0 MB Median auf rund 0,5 MB ZielwertWeniger Bytes bedeuten weniger Energie, weniger CO2 und schnellere Core Web Vitals0,33 gCO2 pro Seitenaufruf im Median(HTTP Archive Web Almanac)363 gCO2 je kWh im deutschenStrommix 2024 (Umweltbundesamt)20 MrdkWh Rechenzentrums-Stromin Deutschland 2024 (Bitkom)
Grundlagen & Strategie 10. Juli 2026

Nachhaltige Websites: Wie Performance CO2 einspart

Nachhaltige Websites: Wie weniger Bytes, schlankes JavaScript und effizientes Caching den CO2-Fußabdruck senken und zugleich die Core Web Vitals verbessern.

12 Min. Lesezeit
Drei Sichten auf Tempo-DatenLab (Lighthouse)eine simulierte Messungfestes Gerät, festes Netzkein Ranking-EinflussCrUX (Felddaten)echte Chrome-Nutzer28-Tage-Fenster, p75Googles RankingquelleEigenes RUMalle Browser, liveElement- und Skript-Detailzeigt das WarumPerformance-Budget am 75. Perzentilgutverbesserungswürdigschlecht75. PerzentilLCP Lab: 1,9 sLCP Feld p75: 3,1 sLaborwert sauber, Felddaten reissen das Budget

RUM vs. CrUX: Felddaten richtig für Tempo nutzen

Lighthouse-Laborwerte beeinflussen kein Ranking. Google bewertet Core Web Vitals über CrUX-Felddaten am 75. Perzentil. So nutzen Sie RUM, CrUX und Budgets.

15 Min. Lesezeit
CLS vs. Visual Stability Index - was gemessen wirdCLS - nur der LadevorgangSeitenaufbau0 bis ~5 sScroll, Interaktion und Nachladen bleiben unberücksichtigtblinder Fleck nach dem LadenVisual Stability Index - der gesamte BesuchLadenBilder, FontsScrollenLazy-InhaltInteraktionKlick, FilterVerweildauerBanner, Adsabsichtliche Bewegungen werden erkannt - unerwartete Sprünge zählen über den ganzen Besuchintent-aware Bewertung statt reiner LadephaseFeldwerte Mai 2026 (CrUX)81,3%guter CLSder Origins55,9%bestehen alle dreiCore Web VitalsWas VSI zusätzlich erfasstSprünge beim Scrollen und Lazy-Loadingspät injizierte Banner und Sticky-ElementeVerschiebungen während der Interaktion
Grundlagen & Strategie 29. Juni 2026

Visual Stability Index 2026: der nächste CLS-Schritt

Visual Stability Index (VSI): Google misst 2026 Layout-Stabilität über den ganzen Besuch statt nur den Ladevorgang. So machen Sie Websites zukunftssicher.

14 Min. Lesezeit
Progressive Bildanzeige: Wahrnehmung vs. BytesVom winzigen Platzhalter zum scharfen Bild auf der Zeitachse0 msHTML geparst~50 msLQIP sichtbarlädtBlur-up Fadefertigscharfes BildLeer / CLS-RisikoLQIP ~400 ByteAufbau / FadeVoll aufgelöst83,3%LCP ist ein Bild (Desktop)~400 Btypische LQIP-Größe11-15%schneller gefühlt mit FeedbackReservierter Platz per width/height + aspect-ratio = kein Layout ShiftDer Platzhalter füllt die Box ab der ersten Millisekunde, das echte Bild blendet darüber ein
Grundlagen & Strategie 26. Juni 2026

Progressive Bildanzeige: LQIP und Blur-up für Tempo

LQIP, Blur-up und responsive Bilder für schnelleren Bildaufbau: bessere gefühlte und gemessene Performance, weniger Layout Shifts, starke Core Web Vitals.

13 Min. Lesezeit
Hydration-Kosten: Voll-Hydration vs. Islands-ArchitekturServer-Side Rendering (HTML auf dem Server erzeugt)0s1s2s3sVoll-HydrationJS-Download (komplettes Bundle)Hydration der gesamten SeiteMain Thread blockiertinteraktivIslands / partielle Hydrationnur Insel-JSselektivinteraktivschnell interaktivfrüher interaktivTime to Interactive80%weniger JS möglich200msTBT-Zielwert mobil8,4%mehr Conversions je 0,1sServer-RenderHTML zuerstCritical Islandspriorisiert hydrierenLazy/On-Demandbei InteraktionResumabilitykein Re-Run
Grundlagen & Strategie 24. Juni 2026

Server-Side Rendering und Hydration richtig nutzen

SSR liefert HTML schnell, doch Hydration kostet Performance. Islands, partielle Hydration und Resumability für schnelle Shops und gute Core Web Vitals.

15 Min. Lesezeit
Cumulative Layout Shift - instabiles vs. stabiles Shop-LayoutInstabil - CLS 0.28HeaderBild ohne width/heightlädt spaet nachProdukttitel und PreisCookie-Banner injiziert spaetButton verschiebt sich nach untenWeb-Font-Swap verschiebt TextAnzeige ohne reservierten PlatzStabil - CLS 0.02HeaderBild mit aspect-ratio reserviertPlatz vorab belegtProdukttitel und PreisButton bleibt an PositionFont-Fallback metrisch kompatibelAnzeige-Slot mit fester HoeheOverlay als position fixedSchwellenwerte CLSGutMittelSchlecht0.10.250.25+Top-UrsachenBilder ohne Masse, FontsAds, spaete InjektionenBanner ohne PlatzhalterSession-Windowgrößter Shift-Burstmax 5s Fenster1s Lücke pro Fenster
Grundlagen & Strategie 22. Juni 2026

Cumulative Layout Shift vermeiden: stabile Shops

CLS vermeiden: Layout-Shifts durch Bilder, Fonts, Ads und Injektionen gezielt beheben. So entstehen messbar stabilere Shop-Layouts mit gutem CLS-Wert.

13 Min. Lesezeit
Third-Party-Skripte im Main-Thread - blockierend vs. entlastetVorher: alles synchron beim SeitenaufrufNachher: defer, lazy und FacadeMain-Thread-BelegungApp-JSTag-ManagerAnalyticsChat-WidgetSession-Rec.A/B-TestLong Task > 50 ms - Eingaben wartenMain-Thread-BelegungApp-JSTag-ManagerWeb WorkerAnalyticsdeferChat-WidgetFacade, lazy bei KlickSession-Rec.entfernt / geprüftA/B-Testnach erster InteraktionThread frei - INP reagiertAudit-Pfad pro Tag1. Inventarisieren - welcher Tag, welcher Zweck2. Bewerten - Blockierzeit pro Skript messen3. Entscheiden - entfernen, defer, lazy, WorkerWirkung auf die VitalsINPMain-Thread freiLCPweniger Render-BlockCLSreservierter PlatzDrittanbieter-Last ist real und messbar10Drittanbieter-JS-Requests im Median (HTTP Archive)92 %der Seiten binden Drittanbieter ein (HTTP Archive)-92 %TBT durch Worker-Auslagerung des Tag-Managers (Chrome)
Grundlagen & Strategie 12. Juni 2026

Third-Party-Skripte entschlacken: Tempo zurückgewinnen

Third-Party-Skripte entschlacken: Tags systematisch auditieren, mit defer und Lazy-Loading entschärfen, Facades nutzen und so INP und LCP messbar verbessern.

13 Min. Lesezeit
HTTP/3 mit QUIC: Verbindungsaufbau im VergleichHTTP/2 über TCP + TLS 1.3TCP HandshakeTLS HandshakeRequest1 RTT1 RTTDaten2 RTT bis erstes BytePaketverlust blockiert alle Streams(Head-of-Line-Blocking auf TCP-Ebene)HTTP/3 über QUIC (UDP)QUIC + TLS kombiniertRequest1 RTTDaten1 RTT (0-RTT bei Wiederbesuch)Paketverlust betrifft nur einen Stream(unabhängige Streams auf QUIC-Ebene)QUIC verlegt Transport und Verschlüsselung in den User Space über UDP Port 443Roundtrips1statt 2 bis 3 bei TCP+TLSConnection MigrationWLAN -> 5Gohne neuen HandshakeStream-Isolationkein HoLpro Stream isolierter VerlustPortUDP 443Alt-Svc-Header nötigAktivierung serverseitigNginx 1.25+ | LiteSpeed | Caddy | Cloud-EdgeUDP 443 freigeben + Alt-Svc sendenFallback automatischBrowser ohne HTTP/3 nutzen HTTP/2 weiterabwärtskompatibel und risikoarmQUIC | 0-RTT | Connection ID | Alt-Svc | UDP 443 | TLS 1.3 | Multiplexing ohne HoL-Blocking

HTTP/3 und QUIC für schnellere Online-Shops

HTTP/3 mit QUIC reduziert Latenz und Verbindungsaufbau im Online-Shop. Wie das Protokoll funktioniert, wann sich der Umstieg lohnt und wie Sie es aktivieren.

13 Min. Lesezeit
Core Web Vitals 2026 - Metriken-DashboardLCP1.8sLargest Contentful PaintINP180msInteraction to Next PaintCLS0.04Cumulative Layout Shift2024: FID entfernt | 2025: INP Pflicht | 2026: Verschärfte SchwellenwerteSchwellenwerte 2026MetrikGutMittelSchlechtLCP2.5s4.0s4.0s+INP200ms500ms500ms+CLS0.10.250.25+Optimierungs-Pipeline1. Messen (Feld)2. Analysieren3. Optimieren (Code)4. Validieren (Field)Server-OptimierungTTFB, CDN, CachingHTTP/3, KompressionRendering-PerformanceCritical CSS, Lazy LoadJS-Budgets, Tree ShakingInteraktivität (INP)Event Handler, Main ThreadWeb Workers, DebouncingLayout-StabilitätDimensionen, FontsReservierte BereicheFelddaten | Lab- und Feldmessung | Browser-Entwicklertools

Core Web Vitals 2026: Neue Metriken und Strategien

Core Web Vitals 2026: INP ersetzt FID, neue Schwellenwerte und Optimierungsstrategien. So messen und verbessern Sie Ihre Werte systematisch.

14 Min. Lesezeit
TTFB-Analyse: Server-Antwortzeit im DetailTTFB WaterfallDNS (45ms)TCP (30ms)TLS (55ms)Server Processing (420ms)TTFB: 550msTTFB-KomponentenDNS-AuflösungNameserver, TTL, AnycastTLS-HandshakeTLS 1.3, OCSP StaplingBackend-LogikPHP, DB-Queries, APIDatenbankQueries, Indizes, BufferOptimierungs-HebelOpcode CacheOPcache, JIT CompilerHTTP-CachingVarnish, Redis, CDNDB-TuningQuery-Optimierung, IndizesCDN + EdgeGeo-Distribution, PoPsZiel: TTFB unter 800ms (Google) | Ideal: unter 200msShared Hosting800-2000msGeteilte RessourcenVPS / Managed300-600msDedizierte CPU/RAMOptimierter Server100-300msOPcache, DB-TuningCDN + Edge Cache50-150msGlobale DistributionDNS Prefetch | TLS 1.3 | HTTP/2+3 | Brotli | OPcache | Redis | Query Cache | CDN PoPs

TTFB: Warum die Server-Antwortzeit alles bestimmt

Time to First Byte optimieren: Ursachen langsamer Server-Antwortzeiten erkennen und mit DNS, TLS, Backend und Caching systematisch beheben.

14 Min. Lesezeit
Critical CSS: Above-the-Fold Rendering PipelineOhne Critical CSSHTML geladen - warte auf CSS...Render-Blocking: styles.css (180 KB)Render-Blocking: vendor.css (95 KB)Blockiert 1.8sLCP: 3.2sFCP: 2.4sWeisser Bildschirm bis CSS vollständig geladenMit Critical CSSInline Critical CSS (8 KB im HTML-Head)Header, Hero, Navigation, Typografie, LayoutSofortiges Rendering des sichtbaren BereichsRest-CSS async nachladen: media=print, onload=this.media=allLCP: 1.4sFCP: 0.6sSofort sichtbarer Inhalt, Rest lädt im HintergrundErgebnis: 56% schnellerer LCP | 75% schnellerer FCP1. ExtrahierenCritical-Path-CSS für denViewport identifizierenPenthouse, Critical, Critters2. InlinenCritical CSS als style-Tagim HTML-Head einbettenMax. 14 KB (TCP Window)3. Defer RestVollständiges CSS asyncnachladen nach Renderingmedia=print + onload TrickHäufige Fehler vermeidenZu viel CSS inlinedWeb-Fonts vergessenFOUC nicht getestetKein Fallback-Styling

Critical CSS: Sichtbarer Bereich in Millisekunden

Critical CSS extrahieren, inline einbinden und automatisieren. So laden Sie den sichtbaren Bereich in Millisekunden und verbessern LCP nachhaltig.

13 Min. Lesezeit
Bildoptimierung: Format-PipelineQuellbildPNG/JPEG (2400x1600)3.2 MB OriginalBuild-Pipeline1. Resize (srcset-Breakpoints)2. Format-KonvertierungAusgabeformateAVIFWebPJPEGFallback-Kette im picture-ElementResponsive Auslieferung mit srcset und sizesMobile400w AVIF: 18 KB400w WebP: 24 KBErsparnis: 99%Tablet800w AVIF: 42 KB800w WebP: 58 KBErsparnis: 98%Desktop1200w AVIF: 78 KB1200w WebP: 105 KBErsparnis: 97%Retina2400w AVIF: 145 KB2400w WebP: 195 KBErsparnis: 94%50%kleiner als WebP96%Browser-Support WebP92%Browser-Support AVIF-40%LCP-VerbesserungLazy Loading StrategieAbove the Fold: eagerViewport + 200px: loading=lazyfetchpriority=high für LCPdecoding=async

Bildoptimierung 2026: WebP, AVIF und responsive Auslieferung

WebP, AVIF, responsive Images und Lazy Loading: So optimieren Sie Bilder für schnellere Ladezeiten, bessere Core Web Vitals und bis zu 95% weniger Bilddaten.

13 Min. Lesezeit
JavaScript Performance Budget PipelineSource Bundle1.8 MB JavaScript (unkomprimiert)145 npm-PaketeTBT: 3200ms | INP: 450msOptimierungTree ShakingCode SplittingDead Code EliminationOptimiertes Bundle380 KB JavaScript (komprimiert)42 npm-PaketeTBT: 280ms | INP: 85msPerformance Budget: max. 150 KB JS (initial, komprimiert)Critical PathFramework Core: 45 KBRouter: 8 KBCritical CSS-in-JS: 12 KBGesamt: 65 KBLazy ChunksProduktseite: 28 KBCheckout: 35 KBSuche: 18 KBOn-Demand geladenThird-PartyAnalytics: 22 KBConsent: 15 KBChat-Widget: 45 KBBudget-Risiko!Bundle-AnalyseTreemap-VisualisierungDuplikat-ErkennungImport-Cost-TrackingCI/CD-Integration-79%JS-Bundle reduziert200msINP-Zielwert150KBInitial-JS-Budget3xschnellere InteraktionOptimierungspfad1. Audit und Messen2. Budget definieren3. Split und Shake4. Third-Party prüfen5. CI/CD-Checks

JavaScript und Performance Budgets: Weniger Code

JavaScript-Einfluss auf INP und Ladezeit minimieren: Performance Budgets, Code Splitting, Tree Shaking und Third-Party-Management für Core Web Vitals.

14 Min. Lesezeit
Multi-Tier Caching ArchitekturBrowser / ClientCache-Control, ETag, SWCDN Edge (PoP weltweit)Statische Assets, HTML-Cache, BrotliVarnish HTTP AcceleratorVCL-Regeln | Grace Mode | Cache Tags | ESIHit Rate: 95%+ | Antwortzeit: 1-5msCache MISSRedisSession-Cache: 0.2msObject-Cache: 0.5msFragment-Cache: 0.3msApplication ServerPHP/Node.js RuntimeOPcache / JITTemplate-RenderingDatenbankQuery-Cache: deaktiviertInnoDB Buffer Pool: 80%Slow Query Log: aktiv1-5msVarnish Cache Hit95%+Cache Hit Rate0.2msRedis-Latenz-90%TTFB-ReduktionCache-Control: max-age | ETag | stale-while-revalidate | Purge API | Tag-basierte Invalidierung

Caching-Strategien: Varnish, Redis und Browser-Cache

Mehrstufige Caching-Architektur mit Varnish, Redis und Browser-Cache: Strategien für TTFB unter 100ms, 95% Cache Hit Rate und optimale Invalidierung.

14 Min. Lesezeit