Zum Inhalt springen
Core Web Vitals Spezialisten

Blog — Seite 2

Query-Wasserfall: N+1 ungeindext vs. indiziert und gecachtDatenbankzeit einer Kategorieseite mit 20 Produktenvorher: N+1 ohne IndexSELECT Liste 18 ms+ 20x SELECT je ProduktFull Scan ohne IndexDB-Zeit gesamt 420 msnachher: Eager Load + IndexSELECT Liste 9 ms1x JOIN Produkte (Index) 6 msQuery-Cache HIT 0,3 msDB-Zeit gesamt 15 msQuery-Zeit vorher und nachhervorher420 msnachher15 ms0,8 sguter TTFB-Wert (web.dev)1%Umsatz je 100 ms (Amazon)8,4%mehr Conversion je 0,1 s32%mehr Absprung 1 zu 3 sEin guter TTFB liegt bei 0,8 Sekunden oder darunter (web.dev) -- jede zusätzliche 100 ms Latenz kostete Amazon rund 1 Prozent Umsatz (Amazon).Eine um 0,1 Sekunden schnellere mobile Ladezeit steigerte Retail-Conversions um 8,4 Prozent (Google/Deloitte 2020).Beispielwerte zur Veranschaulichung des N+1-Musters; reale Zeiten variieren je nach Datenbestand und Hardware.
Server-Performance 15. Juni 2026

Datenbank-Query-Optimierung für die Shop-Performance

Wie Indexe, das Auflösen von N+1-Queries, Query-Caching und EXPLAIN langsame Datenbankabfragen beschleunigen und die Time to First Byte Ihres Shops senken.

14 Min. Lesezeit Lesen →
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)
Performance 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 Lesen →
Edge-Auslieferung: Origin allein vs. CDN mit Edge-PoPsTime to First Byte je nach Distanz zum NutzerOrigin-ServerFrankfurtEdge-PoPNew YorkHIT 12msNutzerEdge-PoPSingapurHIT 15msNutzerEdge-PoPSao PauloMISS 14msNutzernur bei MISSOrigin-FetchTTFB für Nutzer in Sao Pauloohne CDN320 msmit Edge-HIT15 ms54%Requests via CDN1% UmsatzVerlust je 100 ms90,4%Antworten cachebar124 mi/msLicht im Glasfaser54 Prozent aller Requests werden von einem CDN ausgeliefert (Web Almanac 2024) --jede zusätzliche 100 ms Latenz kostete Amazon rund 1 Prozent Umsatz (Amazon).
Server-Performance 10. Juni 2026

CDN und Edge-Caching für Shop-Performance 2026

Wie CDN, Edge-Caching und durchdachte Cache-Control-Header die Time to First Byte weltweit senken und Ihren Shop auch fern vom Origin schnell ausliefern.

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

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 Lesen →
Interaction to Next Paint - Anatomie einer InteraktionKlick / Tippen / Tastendruck bis zum nächsten Frame1. Input Delay40msMain Thread durch Long Task belegt2. Processing Time95msEvent-Handler-Ausführung3. Presentation Delay30msRendering bis nächster FrameINP-SchwellenwerteGut< 200msMittel200-500msSchlecht> 500msSumme = INP-Wert165msInputProcessingPaintBerichtet wird die langsamste Interaktion (75. Perzentil)Long Tasks aufbrechenscheduler.yield()Chunking, YieldingHandler entschlackenrequestIdleCallbackWeb Worker auslagernDrittanbieter zähmenasync, deferLazy bei InteraktionDOM-Arbeit bündelncontent-visibilityLayout Thrashing meidenMessen im Feld statt im LaborFelddaten | web-vitals.js | Lab- und Feldmessung | Long Animation Frames API
Core Web Vitals 1. Juni 2026

INP optimieren: Interaction to Next Paint verbessern

INP optimieren: So senken Sie die Interaction to Next Paint unter 200 Millisekunden. Long Tasks, Event-Handler und Drittanbieter-Skripte gezielt entlasten.

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

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 Lesen →
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
Performance 21. Mai 2026

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 Lesen →