Zum Inhalt springen
Core Web Vitals Spezialisten

Blog

Speculation Rules: vom Hover zur sofortigen SeiteDer Browser prefetcht oder prerendert die Folgeseite -- beim Klick ist sie schon daAnnäherungNutzer nähert sichdem LinkPrerenderFolgeseite lädtim HintergrundAktivierungKlick zeigt diefertige SeiteSofort sichtbarLCP nahe nullMillisekundenEagerness: wann der Browser spekuliertVon vorsichtig bis sofort -- mehr Tempo bedeutet auch mehr Risiko verschwendeter Prerendersconservativeerst beim KlickVerschwendung: keinemoderateab 200 ms HoverVerschwendung: geringeagerab ca. 10 ms HoverVerschwendung: mittelimmediatesofort bei der RegelVerschwendung: höher25%der mobilen Top-10-Mio-Seiten nutzen Speculation Rules(Web Almanac 2025)200 msHover, ab dem die Stufemoderate spekuliert(Chrome for Developers)Chrome 144prerender-until-script alsneue Stufe (Januar 2026)(Chrome for Developers)
Frontend-Performance 6. Juli 2026

Speculation Rules: Instant-Navigation per Prerendering

Wie die Speculation Rules API Folgeseiten prefetcht oder prerendert, Eagerness richtig tunt, verschwendete Prerenders und Analytics-Nebenwirkungen vermeidet.

13 Min. Lesezeit Lesen →
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
Performance 3. Juli 2026

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 Lesen →
fetchpriority="high": das LCP-Bild früher ladenLadereihenfolge des Browsers ohne und mit Priority Hint auf dem Hero-BildOHNE fetchpriorityHTML + CSSSkripte (hohe Priorität)LCP-Bild wartet (low)LCP-Bild lädt spätLCP 4,2 sMIT fetchpriority="high"HTML + CSSLCP-Bild lädt sofortLCP 1,9 s-2,3SekundenLCP im Test(DebugBear)4,2 s auf 1,9 sDrei Regeln für den Priority Hint1Genau ein ElementNur das LCP-Bild bekommthigh - nichts darunter.Mehr high = nichts priorisiert2Nie lazy-loadenloading="lazy" auf dem LCP-Bild bremst es aus.Hero-Bild eager laden3Mit preload paarenVorladen findet das Bild,high hebt die Priorität.srcset bleibt am img-TagBilder starten im Browser mit niedriger Priorität (web.dev) - das LCP-Bild wird so wie ein Nebenbild behandelt.Die Nutzung von fetchpriority für das LCP-Bild stieg auf 15 Prozent der Mobilseiten (Web Almanac 2024).Ein deklaratives Attribut, keine neue Infrastruktur - ein Quick-Win der Frontend-Optimierung.
Frontend-Performance 1. Juli 2026

fetchpriority: LCP mit Priority Hints beschleunigen

Wie fetchpriority='high' das LCP-Bild frueher laedt: korrekte Anwendung, Zusammenspiel mit preload und srcset, die häufigsten Fehler und der LCP-Quick-Win.

13 Min. Lesezeit Lesen →
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
Performance 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 Lesen →
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
Performance 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 Lesen →
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
Performance 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 Lesen →
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
Performance 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 Lesen →
Request-Timeline: mit und ohne Resource HintsVerbindungsaufbau und Ladebeginn für das LCP-Bild und eine SchriftOHNE HintsDNSTCPTLSLCP-Bild lädtspäter StartSchrift lädtMIT HintsDNSTCPTLSpreconnect: warme VerbindungLCP-Bild lädt frühSchrift lädt früh100-500ms gespartVerbreitung der Resource Hints (Web Almanac 2024)33%dns-prefetchder Seiten28%preconnectder Seiten19%preloadder Seiten6%prefetchder Seiten15%fetchpriorityfür LCP-Bildmobilpreconnect verkürzt den Verbindungsaufbau um rund 100 bis 500 ms (web.dev) --die Nutzung von fetchpriority für das LCP-Bild stieg von 0,03 auf 15 Prozent der Mobilseiten (Web Almanac 2024).
Frontend-Performance 19. Juni 2026

Resource Hints: preload, prefetch und preconnect nutzen

Wie preload, prefetch, preconnect, dns-prefetch und Priority Hints den Verbindungsaufbau verkürzen, das LCP-Bild und Schriften beschleunigen -- und wo Überladung schadet.

14 Min. Lesezeit Lesen →
Core Web Vitals: dasselbe Gerät, zwei WeltenBestehensquote der Origins für alle drei Vitals (CrUX)MobilLCP62%größter Inhalt langsamINP77%Touch-ReaktionCLS81%Layout-StabilitätDesktopLCPOKINP97%CLSOKAlle drei Vitals bestanden48%mobil56%desktopvsMobil-Prüfung simuliertCPU 4x langsamerNetz Slow 4G57%E-Commerce-Umsatz mobil53%Abbruch ab 3 s Ladezeit48 Prozent der Origins bestehen mobil alle Core Web Vitals, am Desktop 56 Prozent (Web Almanac 2025) --rund 57 Prozent des weltweiten E-Commerce-Umsatzes entstehen mobil (Statista 2024).
Mobile-Performance 17. Juni 2026

Mobile Performance: Shops auf Smartphones beschleunigen

Wie gedrosselte CPU, langsames Netz, Viewport und Touch die mobilen Core Web Vitals verschieben und Ihren Shop auf dem Smartphone messbar beschleunigen.

13 Min. Lesezeit Lesen →