Zum Inhalt springen
Core Web Vitals Spezialisten

Frontend-Optimierung

Im Browser entscheidet sich, wie schnell eine Seite wirklich wirkt. Diese Kategorie sammelt Beiträge zur Frontend-Seite der Optimierung: Bildformate und responsive Bildgrößen, Schriftarten und deren Ladeverhalten, CSS-Auslieferung und kritische Stile, JavaScript-Bündel und deren Aufteilung, verzögertes Nachladen, Drittanbieter-Skripte und ihre Nebenwirkungen. Wir erklären, wie Layoutsprünge entstehen und wie man sie mit reservierten Flächen vermeidet, warum Interaktivität unter langen Aufgaben leidet und welche Techniken die Hauptarbeit im Browser reduzieren. Jeder Beitrag beschreibt Messung vor und nach der Änderung, damit sich der Effekt einer Maßnahme beziffern lässt statt vermuten. Ergänzend geht es um Zusammenarbeit: welche Anforderungen an Gestaltung und Redaktion verhindern, dass jede neue Seite die Ladezeit wieder verschlechtert.

content-visibility: Rendering-Arbeit auf den Viewport begrenzenLange Listenseite (Scroll-Achse)Hero-Bereich (LCP)gerendertIntro und FiltergerendertProduktliste AübersprungenProduktliste BübersprungenFAQ-SektionübersprungenFooter-BereichübersprungenViewport-Kante - darunter überspringt der Browsercontent-visibility: auto + contain-intrinsic-size: auto 480pxRendering-Zeit beim ersten Laden (web.dev-Demo)Standard232 mscontent-visibility30 msweb.dev erwartet mindestens 50 Prozent weniger Rendering-KostenVier Containment-Zusagen an den BrowserlayoutInnenlayout wirktnicht nach außenpaintInhalt bleibt inden Box-GrenzensizeGröße ohne Blickauf die KinderstyleZähler und Quotesbleiben im TeilbaumWo content-visibility am stärksten wirkt30 msRendering-Zeit statt 232 ms beimersten Laden (web.dev)50 %erwartete Mindest-Reduktion derRendering-Kosten (web.dev)77 / 97 %guter INP mobil gegenüber Desktop(HTTP Archive Web Almanac 2025)
Frontend-Optimierung 27. Juli 2026

content-visibility: Rendering-Arbeit gezielt sparen

content-visibility und CSS-Containment begrenzen die Rendering-Arbeit langer Seiten auf den sichtbaren Bereich - mit Platzhalterhöhen ohne neue Layout-Sprünge.

13 Min. Lesezeit
Shared Dictionaries: Bundles als Delta ausliefernAblauf einer Delta-Antwort1 - Browser hat app.v1.js im Cacheaus dem letzten Deploy, als Wörterbuch markiert2 - Request meldet das WörterbuchAvailable-Dictionary: :sha-256-Hash:3 - Server komprimiert das DeltaContent-Encoding: dcb oder dcz4 - Browser rekonstruiert app.v2.jsvolles Bundle, nur das Delta ging über die LeitungOhne Treffer: normale Brotli-AntwortWas die neue Bundle-Version kostet (WICG-Beispiele)Brotli allein344 KBdcb gegen v1128 KB-63 %Frontend-Bundle eines Nachrichtenportals, unkomprimiert 1,5 MBWörterbuch = die Vorgängerversion derselben DateiQuelle: WICG compression-dictionary-transportGoogle Search mit statischem Wörterbuch (Chrome for Developers)23 %kleinere HTML-Antwortals mit Brotli allein1,7 %besserer LCPüber alle Chrome-Nutzerbis 9 %besserer LCPauf langsamen NetzenStatisches Wörterbuch aus einer Stichprobe echter ErgebnisseitenAushandlung, Unterstützung und RückfallebeneAccept-Encoding: dcb, dcz, br, gzip -> Server prüft Available-Dictionary -> Delta oder normale AntwortChrome 130+Edge 130+Firefox / Safari: Fallback69 % global (Can I use)
Frontend-Optimierung 24. Juli 2026

Shared Dictionaries: Bundles als Delta ausliefern

Compression Dictionary Transport nach RFC 9842: Wie Browser und Server Bundles als Delta gegen die Vorgängerversion ausliefern - Muster, Konfiguration, Fallback.

12 Min. Lesezeit
Back-Forward-Cache: der sofortige Zurück-SprungDer Browser friert die ganze Seite ein und holt sie beim Zurück-Klick fast verzögerungsfrei zurückOhne bfcachevoller ReloadVerbindungHTMLCSS + JSRender~1200 msMit bfcacheaus dem Speicherwenige Millisekunden - Seite ist sofort daTypische Blocker der WiederherstellungDiese Faktoren verhindern, dass Chrome die Seite aus dem Speicher zurückholtunload-Handlerveraltetes EntladenWebSocket / WebRTCoffene VerbindungCookie-Änderungräumt no-store-SeiteCache-Controlno-store (teilweise)54%bfcache-Trefferquote statt zuvor0,04 % im Yahoo-Japan-News-Test(web.dev)6,77%aller Seitenaufrufe wurdenaus dem bfcache bedient(Chrome UX Report)100%der Chrome-Nutzer: bfcache auchbei Cache-Control: no-store(Chrome for Developers)
Frontend-Optimierung 13. Juli 2026

Back-Forward-Cache: der sofortige Zurück-Sprung

Wie der Back-Forward-Cache ganze Seiten im Speicher haelt und Zurück-Navigationen sofort macht: Blocker, Cache-Control: no-store und Tests in den DevTools.

13 Min. Lesezeit
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-Optimierung 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
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-Optimierung 1. Juli 2026

fetchpriority: LCP mit Priority Hints beschleunigen

Wie fetchpriority='high' das LCP-Bild früher lädt: korrekte Anwendung, Zusammenspiel mit preload und srcset, die häufigsten Fehler und der LCP-Quick-Win.

13 Min. Lesezeit
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-Optimierung 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
Ladeverlauf: Monolithisches Bundle vs. On-Demand-ChunksOhne SplittingMit Lazy Loading und Code-Splittingapp.bundle.js -- 880 KB (blockiert Main Thread)Parsen und KompilierenAusführenFirst Paintspät interaktivAlles lädt sofort -- auch Code für Seiten,die der Nutzer nie aufruft.core.js -- 140 KBParsenAusf.Paintfrüh interaktivroute: produkt.js 28 KBroute: checkout.js 34 KBchat-widget.js (Klick)bild (Viewport)On-DemandNur der kritische Pfad startet sofort.Chunks folgen bei Navigation oder Interaktion.Initiales JavaScript (komprimiert)vorher880 KBnachher140 KB44%JS ungenutzt im Median34%Sites mit Lazy Loadingplus 8,4%Conversion je 0,1 s2,5 sLCP-ZielwertIm Median sind 44 Prozent des ausgelieferten JavaScripts beim Laden ungenutzt (Web Almanac 2024) --0,1 s schnellere Mobile-Ladezeit steigerten Retail-Conversions um 8,4 Prozent (Google/Deloitte).
Frontend-Optimierung 8. Juni 2026

Lazy Loading und Code-Splitting richtig umsetzen 2026

Lazy Loading für Bilder, routenbasiertes Code-Splitting und dynamische Importe senken das initiale JavaScript spürbar und verbessern die Core Web Vitals.

14 Min. Lesezeit
Web-Font-Ladekette: FOIT, FOUT und die optimierte StrategieUnoptimiert: FOIT + Layout-ShiftHTML geladen - Text unsichtbar (FOIT)fonts.googleapis.com - DNS + Connect (3rd party)Download Schrift (TTF 280 KB, kein Subset)blockiert 2.1sCLS: 0.18 (Font-Swap)Text springt beim Schriftwechsel - schlechter CLSOptimiert: font-display + PreloadPreload WOFF2 (self-hosted, 22 KB Subset)rel=preload as=font crossorigin im HTML-Headfont-display: swap + size-adjust FallbackFallback-Metriken angeglichen: kaum sichtbarer SwapCLS: 0.01Sofort lesbarer Text, stabiles LayoutErgebnis: kein FOIT, CLS unter 0.1, Schriftdaten um ~75% kleiner1. Self-HostingSchriften lokal ausliefernstatt 3rd-party-AnfrageDSGVO + 1 Roundtrip weniger2. WOFF2 + SubsetKomprimierung + nurbenötigte Glyphenbis zu 70% kleiner3. font-displayswap oder optionalFOIT vermeidenText sofort sichtbar4. Fallback-Matchsize-adjust, ascent,line-gap angleichenCLS gegen 0font-display StrategienswapFallback sofort, dann Tauschoptionalkein Swap nach 100ms - CLS 0fallbackkurzer Block, dann Swap-Fensterauto / blockFOIT-Risiko - meidenFormat-Vergleich (gleiche Schrift)TTF / OTF~100%WOFF~60%WOFF2~30%
Frontend-Optimierung 5. Juni 2026

Web-Font-Performance: Ladezeit durch Schriften senken

Web-Fonts kosten Ladezeit und verursachen Layout-Shifts. So optimieren Sie Schriften mit font-display, Preload, Subsetting und WOFF2 für schnelle Seiten.

13 Min. Lesezeit
Video-Performance: den Ladepfad im GriffPoster als LCP-Kandidat, preload sparsam, moderner Codec - das Video bremst die Seite nicht ausPoster als LCP-KandidatPoster (WebP) sofort, Video streamt danachLCP 1,2 s statt 1,55 s (DebugBear)preload sparsam wählenpreload=none0 Byte vorabpreload=metadatanur Metadatenautoplaylädt sofort · 23%autoplay hat Vorrang vor preload (MDN)Codec + Container: kleinere Datei3,7 MBGIF551 KBMP4341 KBWebMWebM ~91% kleiner als das GIF (web.dev)Video als Ladezeit-Treiber - in Zahlen23 %starten per Autoplay und laden sofort(HTTP Archive Web Almanac)91 %kleiner als GIF: WebM statt Animation(web.dev)3 %der Video-Elemente nutzen ein Poster(HTTP Archive Web Almanac)Beispielhafte Werte zur Veranschaulichung; reale Ladezeiten hängen von Setup, Netz und Video ab.
Frontend-Optimierung 27. Mai 2026

Video-Performance: Ladezeit durch Videos im Griff

Video als unterschätzter Ladezeit-Treiber: Poster als LCP-Kandidat, sparsames preload, moderne Codecs und Fassaden für eingebettete Player.

13 Min. Lesezeit
Ruckelfrei bei 60 fps - das 16,7-ms-Frame-BudgetEin Frame: von JavaScript bis zum fertigen PixelJavaScriptStyleLayoutPaintCompositeBrowser-Reserve ~6 ms10 ms sicheres Budget16,7 ms = 1 FrameWelche CSS-Eigenschaft welche Arbeit auslöstGünstig: nur Compositingtransform, opacityStyleLayoutPaintCompositekein Layout, kein Paint - stabil bei 60 fpsArbeit nur auf dem Compositor-ThreadTeuer: voller Durchlauftop, left, width, height, box-shadowStyleLayoutPaintCompositejede Änderung: Layout + Paint + Compositeverpasst leicht das 16,7-ms-BudgetGleichmäßige Frames (60 fps) gegen Ruckeln (verpasste Frames)60 fpsRuckelnVier Hebel gegen Jankwill-change gezielt | Lesen dann Schreiben | requestAnimationFrame | DevTools Performance-Panel
Frontend-Optimierung 25. Mai 2026

Flüssige Animationen: Ruckeln im Frontend stoppen

Flüssige Animationen ohne Ruckeln: das 16,7-ms-Frame-Budget, warum nur transform und opacity günstig sind und wie Sie Frontend-Jank in den DevTools aufspüren.

12 Min. Lesezeit