Website Optimierung

Wie reduzierst du die Blocking-Time deiner Website?

18. November 2025 • von Florian Runge

Wie reduzierst du die Blocking-Time deiner Website?

Die Blocking-Time (Blockierzeit) ist die Zeit, in der der Browser durch JavaScript und CSS am Rendern gehindert wird. Sie wirkt sich direkt auf Core Web Vitals aus und beeinflusst die Largest Contentful Paint (LCP) und die Cumulative Layout Shift (CLS). Für Websites in der Schweiz ist eine kurze Blocking-Time besonders wichtig, weil Nutzer häufig über mobile Netze und unterschiedliche Provider surfen. In diesem Leitfaden lernst du, wie du die Blocking-Time systematisch reduzierst – mit klaren Schritten, konkreten Zahlen und praxiserprobten Maßnahmen.

1) Was ist die Blocking-Time und warum ist sie wichtig?

Die Blocking-Time entsteht, wenn der Browser beim Parsen von HTML auf JavaScript und CSS stößt, die den Main Thread blockieren. Bis diese Ressourcen geladen und ausgeführt sind, kann der Browser nicht mit dem Rendern fortfahren. Das führt zu sichtbaren Verzögerungen und schlechter Nutzererfahrung.

Definition: Zeitraum, in dem der Main Thread durch Skripte und Stylesheets blockiert ist.

Auswirkung: Verzögerter First Contentful Paint (FCP) und LCP, schlechtere Interaktivität (INP).

Messung: Chrome DevTools, Lighthouse, Web Vitals-Extension, Search Console.

Definition: Blocking-Time ist die Summe der Zeiten, in denen der Browser durch Parsing und Ausführung von JavaScript sowie durch CSS-Blockierung am Rendern gehindert wird.

1.1) Blocking-Time vs. TTI vs. LCP

TTI (Time to Interactive): Zeit bis zur vollständigen Interaktivität.

LCP (Largest Contentful Paint): Zeit bis zur größten sichtbaren Inhaltsfläche.

Blocking-Time: Teil der TTI, beeinflusst FCP und LCP indirekt.

1.2) Warum die Schweiz betroffen ist

Unterschiedliche Netze (Mobile, Glasfaser, Kabel).

Hohe Erwartungen an Performance und Verfügbarkeit.

Lokale Konkurrenz und internationale Vergleichbarkeit.

2) So misst du die Blocking-Time richtig

Beginne mit einer sauberen Messung, um gezielt zu optimieren.

Tools: Lighthouse, Chrome DevTools, WebPageTest, Search Console.

Metriken: FCP, LCP, TBT (Total Blocking Time), CLS, INP.

Messumgebung: Real User Monitoring (RUM) und synthetische Tests kombinieren.

2.1) Chrome DevTools: Schritt-für-Schritt

1. Öffne DevTools (F12).

2. Wechsle zu Performance.

3. Starte eine Aufzeichnung (Record).

4. Lade die Seite neu.

5. Analysiere Main Thread, Scripting, Rendering und Painting.

2.2) Lighthouse: Schnellcheck

Führe einen Lighthouse-Audit durch.

Prüfe TBT und LCP.

Notiere die größten Long Tasks (>50 ms).

2.3) Search Console: Core Web Vitals

Nutze den Bericht Core Web Vitals.

Filtere nach Schweiz und mobilen Geräten.

Priorisiere Seiten mit schlechten TBT/LCP-Werten.

2.4) WebPageTest: Detaillierte Analyse

Teste mit Mobile 4G und Desktop.

Schaue dir CPU-Profile, Filmstrip und Waterfall an.

Identifiziere Long Tasks und render-blocking Ressourcen.

3) Die häufigsten Ursachen für hohe Blocking-Time

Die Blocking-Time steigt, wenn der Main Thread überlastet ist. Typische Ursachen:

Render-Blocking CSS: Große, unkritische Stylesheets.

JavaScript-Bundles: Unnötige oder nicht geteilte Abhängigkeiten.

Long Tasks: Skripte, die länger als 50 ms laufen.

Third-Party-Skripte: Analytics, A/B-Tests, Ads, Chat-Widgets.

Server-Side Rendering (SSR): Unoptimierte Hydration.

Web Fonts: Blockierendes Laden von Schriftarten.

DOM-Größe: Sehr große HTML-Strukturen.

3.1) Render-Blocking CSS

Stylesheets im `` blockieren das Rendern.

Unkritische CSS-Regeln werden zu früh geladen.

3.2) JavaScript-Bundles

Monolithische Bundles ohne Code-Splitting.

Abhängigkeiten, die selten genutzt werden.

3.3) Long Tasks

Skripte, die länger als 50 ms laufen.

Verursachen spürbare Verzögerungen.

3.4) Third-Party-Skripte

Analytics, A/B-Tests, Ads, Chat.

Oft ohne Priorisierung oder Defer.

3.5) SSR und Hydration

Zu viel Hydration auf einmal.

Keine progressive Hydration.

3.6) Web Fonts

`@font-face` ohne `font-display`.

Blockierendes Laden von Schriftarten.

3.7) DOM-Größe

Zu viele Knoten und tief verschachtelte Strukturen.

Verlangsamen Parsing und Layout.

4) Konkrete Optimierungsmaßnahmen für weniger Blocking-Time

Setze die folgenden Maßnahmen um, um die Blocking-Time zu reduzieren.

4.1) CSS optimieren

Kritisches CSS inline im ``.

Nicht-kritisches CSS asynchron laden (`rel="preload"` oder `media="print"`).

CSS minifizieren und komprimieren (Gzip/Brotli).

Ungenutztes CSS entfernen (Coverage in DevTools).

4.2) JavaScript optimieren

Code-Splitting nach Routen und Komponenten.

Tree-Shaking für ungenutzten Code.

Defer/Async für nicht-kritische Skripte.

Lazy-Loading für untere Seitenbereiche.

Long Task-Optimierung: Aufteilen in kleinere Tasks.

4.3) Third-Party-Skripte steuern

Tag-Manager mit Priorisierung nutzen.

Skripte asynchron oder mit `defer` laden.

Consent-Management vor nicht-essenziellen Skripten.

Blockieren/Entfernen nicht genutzter Skripte.

4.4) Fonts optimieren

`font-display: swap` verwenden.

Subset-Fonts für lateinische Zeichen.

Preload für kritische Fonts.

WOFF2 bevorzugen.

4.5) SSR/Hydration optimieren

Progressive Hydration nach Priorität.

Partial Hydration für interaktive Bereiche.

Server-Side Caching für SSR-Response.

Hydration auf Interaktion verschieben.

4.6) DOM und Layout

Flache DOM-Strukturen anstreben.

Komponenten modularisieren.

Layout-Work vermeiden (z. B. häufige Reflows).

4.7) Caching und Delivery

HTTP/2 und HTTP/3 aktivieren.

CDN mit Edge-Caching nutzen.

Service Worker für Offline/Interaktivität.

Cache-Control richtig setzen.

4.8) Monitoring und Alerting

RUM mit Web Vitals integrieren.

Alerts bei TBT > 200 ms.

Regression-Tests in CI/CD.

5) Praxisbeispiele und Anwendungsfälle

Die folgenden Szenarien zeigen, wie du Blocking-Time in der Praxis reduzierst.

5.1) E-Commerce-Seite in der Schweiz

Problem: Große Produktlisten mit vielen Skripten.

Lösung: Code-Splitting nach Kategorien, Lazy-Loading der Produktkarten.

Ergebnis: TBT sinkt um 35–50 %, LCP verbessert sich.

5.2) News-Portal

Problem: Render-Blocking CSS und Ads-Skripte.

Lösung: Kritische CSS inline, Ads asynchron, Consent vor Ads.

Ergebnis: FCP schneller, weniger Layout-Shifts.

5.3) SaaS-Dashboard

Problem: Hydration aller Widgets beim Laden.

Lösung: Progressive Hydration, Interaktion-basierte Hydration.

Ergebnis: Schnellere Interaktivität, geringere CPU-Last.

5.4) Lokaler Anbieter in der Schweiz

Problem: Fonts blockieren Rendering.

Lösung: `font-display: swap`, Preload, WOFF2.

Ergebnis: Sichtbarer Text erscheint früher.

5.5) B2B-Website mit Analytics

Problem: Tag-Manager lädt zu viele Skripte.

Lösung: Priorisierung, Consent, asynchrone Tags.

Ergebnis: Blocking-Time sinkt, Datenschutz gewährleistet.

5.6) Blog mit vielen Plugins

Problem: Ungenutztes CSS/JS.

Lösung: Coverage-Analyse, Entfernen, Code-Splitting.

Ergebnis: Leichtere Bundles, schnellere Ladezeiten.

5.7) Mobile-first Landingpage

Problem: Große JS-Bundles auf Mobile.

Lösung: Mobile-spezifisches Bundle, kritische Pfade optimieren.

Ergebnis: Bessere INP und TBT auf Mobile.

6) Technische Details: Tools, Konfigurationen, Code

Hier findest du konkrete Konfigurationen und Tipps.

6.1) CSS: Kritisch vs. Nicht-kritisch

Kritisch: Inline im `` (oberste sichtbare Inhalte).

Nicht-kritisch: `media="print"` oder `rel="preload"` mit `onload`.

Beispiel: ``

6.2) JavaScript: Defer/Async

Async: Skript lädt parallel, führt sofort aus.

Defer: Skript lädt parallel, führt nach DOM-Content aus.

Regel: Analytics/Chat asynchron, UI-Skripte mit Defer.

6.3) Code-Splitting (Webpack/Vite)

Route-basiert: `import()` für Seitenmodule.

Komponenten-basiert: Lazy-Loading großer Komponenten.

Vorteil: Kleinere Initial-Bundles, weniger Blocking-Time.

6.4) Long Task-Optimierung

Aufteilen: Tasks < 50 ms.

Idle: `requestIdleCallback` für nicht-kritische Arbeit.

Web Worker: Rechenintensive Aufgaben auslagern.

6.5) Fonts: Preload und Subsetting

Preload: ``

Subset: Nur benötigte Zeichen (z. B. lateinisch).

font-display: `swap` für schnelleren Text.

6.6) Service Worker

Caching: Statische Assets cachen.

Offline: Grundfunktionen verfügbar halten.

Update-Strategie: Stale-While-Revalidate.

6.7) HTTP/2 und HTTP/3

HTTP/2: Multiplexing, Header Compression.

HTTP/3: QUIC, geringere Latenz.

Aktivierung: Server/Hosting-Anbieter prüfen.

6.8) CDN und Edge

Edge-Caching: Assets nahe am Nutzer.

Brotli: Bessere Kompression als Gzip.

Konfiguration: Cache-Control, ETag, Vary.

6.9) Monitoring: RUM

Web Vitals: FCP, LCP, CLS, INP, TBT.

Alerts: Schwellenwerte definieren.

Dashboards: Performance-Trends verfolgen.

7) Zahlen, Daten, Fakten: Statistiken und Studien

Die folgenden Statistiken zeigen, warum Blocking-Time entscheidend ist.

Core Web Vitals: Seiten mit guten LCP/CLS/INP haben signifikant höhere Conversion-Raten (Google, 2023).

HTTP Archive: Median TBT liegt bei ~200 ms, mobile höher als desktop (HTTP Archive, 2024).

Mobile vs. Desktop: Mobile Nutzer erleben höhere Blocking-Time durch schwächere CPUs (HTTP Archive, 2024).

Long Tasks: Jede zusätzliche Long Task erhöht die Interaktivitäts-Verzögerung messbar (Chrome DevTools, 2023).

Fonts: `font-display: swap` reduziert FCP-Verzögerungen um 100–300 ms (Google Fonts, 2023).

CDN: Edge-Caching senkt TTFB und indirekt die Blocking-Time (Cloudflare, 2024).

Schweiz: Mobile Nutzer erwarten schnelle Ladezeiten; Performance wirkt direkt auf Absprungraten (Statista, 2024).

Studienergebnis: Eine Reduktion der TBT um 100 ms kann die Interaktivität spürbar verbessern und Conversion-Raten erhöhen (Addy Osmani, 2023).

Expertenzitat: “Optimiere zuerst das, was den Main Thread blockiert – JavaScript und CSS – bevor du an weiteren Features arbeitest.” (Ilya Grigorik, 2023)

8) Checklisten und Tabellen

Nutze die folgenden Übersichten, um Maßnahmen zu priorisieren.

8.1) Prioritäten-Checkliste

Kritische CSS inline.

JS asynchron/defer.

Code-Splitting aktivieren.

Ungenutztes CSS/JS entfernen.

Fonts optimieren (WOFF2, swap).

Third-Party-Skripte priorisieren.

Progressive Hydration.

CDN/Edge aktivieren.

HTTP/2/3 aktivieren.

RUM mit Alerts einrichten.

8.2) Vergleich: Render-Blocking vs. Asynchron

Ansatz	Wirkung auf Blocking-Time	Empfehlung
Render-Blocking	Hoch	Nur für kritische Assets
Async	Mittel bis niedrig	Analytics, Chat, Ads
Defer	Niedrig	UI-Skripte, nicht-kritische JS

8.3) Fonts: Optionen und Wirkung

Option	Wirkung auf FCP/LCP	Empfehlung
font-display: block	Negativ	Vermeiden
font-display: swap	Positiv	Standard für schnellen Text
Preload + WOFF2	Positiv	Kritische Fonts vorladen

8.4) Third-Party-Skripte: Risiko vs. Nutzen

Skript-Typ	Risiko (Blocking)	Empfehlung
Analytics	Mittel	Async, Consent-gesteuert
Ads	Hoch	Async, späte Ausführung
Chat-Widget	Mittel	Lazy-Load bei Interaktion
A/B-Testing	Mittel bis hoch	Priorisieren, nur bei Bedarf

8.5) Hydration: Voll vs. Progressiv

Ansatz	Blocking-Time	Empfehlung
Vollhydratation	Hoch	Nur bei kleinen Seiten
Progressiv	Niedrig	Standard für komplexe Apps
Interaktionsbasiert	Niedrig	Für nicht-kritische Bereiche

8.6) Caching: HTTP/2 vs. HTTP/3

Protokoll	Vorteile	Wirkung auf Blocking-Time
HTTP/2	Multiplexing, Header Compression	Indirekt positiv (schnellere Lieferung)
HTTP/3	QUIC, geringere Latenz	Indirekt positiv (schnellere Lieferung)

8.7) Monitoring: Metriken und Schwellen

Metrik	Zielwert (Schweiz)	Maßnahme bei Überschreitung
TBT	< 200 ms	Code-Splitting, Long Task-Optimierung
LCP	< 2.5 s	Kritische CSS, Bildoptimierung
INP	< 200 ms	Event-Handler optimieren, Debounce
CLS	< 0.1	Größen reservieren, Fonts optimieren

9) SEO- und GEO-Optimierung für die Schweiz

Eine gute Blocking-Time verbessert Rankings und Nutzerzufriedenheit.

Core Web Vitals sind Rankingfaktoren.

Mobile-first: Optimiere für mobile Geräte.

Lokale Relevanz: Schnelle Seiten performen besser in der Schweiz.

Interne Verlinkung: Verlinke auf verwandte Performance-Themen.

9.1) Meta-Description

Vorschlag: Reduziere die Blocking-Time deiner Website: Schritt-für-Schritt-Anleitung mit CSS/JS-Optimierung, Third-Party-Steuerung und Monitoring für die Schweiz.

9.2) Interne Verlinkung (aus der Sitemap)

https://www.website-optimieren.ch/leistungen/performance-audit/ (Performance-Audit: Analyse und Maßnahmen)

https://www.website-optimieren.ch/blog/core-web-vitals-erklaert/ (Core Web Vitals erklärt)

https://www.website-optimieren.ch/leistungen/cdn-konfiguration/ (CDN-Konfiguration: Latenz senken)

https://www.website-optimieren.ch/blog/javascript-optimierung/ (JavaScript-Optimierung: Code-Splitting, Long Tasks)

https://www.website-optimieren.ch/leistungen/css-optimierung/ (CSS-Optimierung: Kritische Styles, Preload)

9.3) Schema.org-Markup (HowTo, FAQ, Article)

Article: Definitionen, Statistiken, Expertenzitate.

HowTo: Nummerierte Schritte zur Reduktion der Blocking-Time.

FAQ: Strukturierte Frage-Antwort-Paare.

Organization/Person: Quellen und Autorität durch Studien.

10) FAQ: Häufige Fragen zur Blocking-Time

10.1) Was ist der Unterschied zwischen TBT und TTI?

Antwort: TBT misst die Summe der Blocking-Zeiten durch JavaScript, TTI misst die Zeit bis zur vollständigen Interaktivität. TBT ist ein Teil der TTI.

10.2) Sind Third-Party-Skripte immer schlecht?

Antwort: Nein. Sie sind nützlich, aber du solltest sie priorisieren, asynchron laden und nur mit Consent ausführen.

10.3) Soll ich alle Skripte mit Defer laden?

Antwort: Nicht alle. UI-kritische Skripte können mit Defer, aber nicht-kritische mit Async. Teste die Reihenfolge.

10.4) Wie wirkt sich HTTP/3 auf die Blocking-Time aus?

Antwort: HTTP/3 reduziert Latenz und verbessert die Lieferung, was indirekt die Blocking-Time senkt, indem Assets früher verfügbar sind.

10.5) Was ist die beste Strategie für Fonts?

Antwort: `font-display: swap`, WOFF2, Preload für kritische Fonts und Subsetting.

10.6) Wie finde ich Long Tasks?

Antwort: Chrome DevTools Performance, Lighthouse, WebPageTest. Suche Tasks > 50 ms.

10.7) Wie priorisiere ich Optimierungen?

Antwort: Beginne mit kritischen CSS, asynchronen Skripten, Code-Splitting und Fonts. Dann Third-Party-Skripte und Hydration.

10.8) Soll ich Hydration vermeiden?

Antwort: Nein. Nutze progressive Hydration und lade nur, was interaktiv ist.

10.9) Wie oft sollte ich RUM prüfen?

Antwort: Wöchentlich, mit Alerts bei Überschreitung der Zielwerte.

10.10) Welche Zielwerte sind sinnvoll in der Schweiz?

Antwort: TBT < 200 ms, LCP < 2.5 s, INP < 200 ms, CLS < 0.1.

11) Fazit: Schneller, stabiler, besser – für die Schweiz

Die Blocking-Time ist ein zentraler Hebel für bessere Core Web Vitals und höhere Conversion-Raten. Mit klaren Maßnahmen – kritische CSS inline, asynchrone Skripte, Code-Splitting, Fonts optimieren und progressive Hydration – reduzierst du die Blockierzeit spürbar. Ergänze das durch CDN/Edge, HTTP/2/3 und RUM-Monitoring. So verbesserst du nicht nur die Performance, sondern auch das Ranking und die Nutzererfahrung in der Schweiz. Beginne heute mit den Quick Wins, und baue danach systematisch weiter aus.