Zum Inhalt springen
Core Web Vitals specialists

Blog — Page 2

Query Waterfall: Unindexed N+1 vs. Indexed and CachedDatabase time of a category page with 20 productsbefore: N+1 without indexSELECT list 18 ms+ 20x SELECT per productfull scan, no indextotal DB time 420 msafter: eager load + indexSELECT list 9 ms1x JOIN products (index) 6 msquery cache HIT 0.3 mstotal DB time 15 msQuery time before and afterbefore420 msafter15 ms0.8 sgood TTFB value (web.dev)1%revenue per 100 ms (Amazon)8.4%more conversions per 0.1 s32%more bounce 1 to 3 sA good TTFB is 0.8 seconds or less (web.dev) -- every additional 100 ms of latency cost Amazon about 1 percent in sales (Amazon).A mobile load time 0.1 seconds faster increased retail conversions by 8.4 percent (Google/Deloitte 2020).Illustrative values for the N+1 pattern; real timings vary by data volume and hardware.
Server-Performance Jun 15, 2026

Database Query Optimization for Shop Performance

How indexes, resolving N+1 queries, query caching and EXPLAIN speed up slow database queries and lower the Time to First Byte of your online shop fast.

14 min read Read →
Third-party scripts on the main thread - blocking vs. relievedBefore: everything synchronous on page loadAfter: defer, lazy and facadeMain thread occupancyApp JSTag managerAnalyticsChat widgetSession rec.A/B testLong task > 50 ms - input waitsMain thread occupancyApp JSTag managerWeb WorkerAnalyticsdeferChat widgetfacade, lazy on clickSession rec.removed / reviewedA/B testafter first interactionThread free - INP respondsAudit path per tag1. Inventory - which tag, which purpose2. Assess - measure blocking time per script3. Decide - remove, defer, lazy, workerEffect on the vitalsINPmain thread freeLCPless render blockCLSreserved spaceThird-party load is real and measurable10third-party JS requests at the median (HTTP Archive)92 %of pages embed third parties (HTTP Archive)-92 %TBT from offloading the tag manager to a worker (Chrome)
Performance Jun 12, 2026

Trimming Third-Party Scripts: Reclaim Your Speed

Trimming third-party scripts: audit tags, defuse them with defer and lazy loading, use facades and measurably improve INP and LCP for better Core Web Vitals.

13 min read Read →
Edge Delivery: Origin Alone vs. CDN with Edge PoPsTime to First Byte by distance to the userOrigin serverFrankfurtEdge PoPNew YorkHIT 12msuserEdge PoPSingaporeHIT 15msuserEdge PoPSao PauloMISS 14msuseron MISS onlyorigin fetchTTFB for a user in Sao Paulowithout CDN320 mswith edge HIT15 ms54%requests via CDN1% revenuelost per 100 ms90.4%responses cacheable124 mi/mslight in fiber54 percent of all requests are served from a CDN (Web Almanac 2024) --every additional 100 ms of latency cost Amazon roughly 1 percent in sales (Amazon).
Server-Performance Jun 10, 2026

CDN and Edge Caching for Shop Performance 2026

How a CDN, edge caching and well-set cache-control headers cut Time to First Byte worldwide and keep your shop fast even far from the origin server.

14 min read Read →
Loading Timeline: Monolithic Bundle vs. On-Demand ChunksWithout SplittingWith Lazy Loading and Code Splittingapp.bundle.js -- 880 KB (blocks main thread)Parse and compileExecuteFirst Paintlate interactivityEverything loads upfront -- even code for pagesthe user never visits.core.js -- 140 KBParseExec.Paintearly interactivityroute: product.js 28 KBroute: checkout.js 34 KBchat-widget.js (click)image (viewport)On demandOnly the critical path starts immediately.Chunks follow on navigation or interaction.Initial JavaScript (compressed)before880 KBafter140 KB44%JS unused at median34%sites using lazy loadingplus 8.4%conversions per 0.1 s2.5 sLCP targetAt the median, 44 percent of delivered JavaScript is unused during load (Web Almanac 2024) --a 0.1 s faster mobile load lifted retail conversions by 8.4 percent (Google/Deloitte).
Frontend-Performance Jun 8, 2026

Lazy Loading and Code Splitting Done Right in 2026

Lazy loading for images and components, route-based code splitting and dynamic imports cut initial JavaScript and improve Core Web Vitals on every page.

14 min read Read →
Web Font Loading Chain: FOIT, FOUT and the Optimized StrategyUnoptimized: FOIT + Layout ShiftHTML loaded - text invisible (FOIT)fonts.googleapis.com - DNS + connect (3rd party)Download font (TTF 280 KB, no subset)blocked 2.1sCLS: 0.18 (font swap)Text jumps on font swap - poor CLSOptimized: font-display + preloadPreload WOFF2 (self-hosted, 22 KB subset)rel=preload as=font crossorigin in HTML headfont-display: swap + size-adjust fallbackFallback metrics matched: barely visible swapCLS: 0.01Instantly readable text, stable layoutResult: no FOIT, CLS below 0.1, font data ~75% smaller1. Self-HostingServe fonts locallyinstead of 3rd partyGDPR + 1 fewer roundtrip2. WOFF2 + subsetCompression + onlyneeded glyphsup to 70% smaller3. font-displayswap or optionalavoid FOITtext visible instantly4. Fallback matchmatch size-adjust,ascent, line-gapCLS toward 0font-display strategiesswapfallback first, then swapoptionalno swap after 100ms - CLS 0fallbackshort block, then swap windowauto / blockFOIT risk - avoidFormat comparison (same font)TTF / OTF~100%WOFF~60%WOFF2~30%
Frontend Jun 5, 2026

Web Font Performance: Cut Load Time With Fonts

Web fonts cost load time and cause layout shifts. Learn how to optimize fonts with font-display, preload, subsetting and WOFF2 for fast pages.

13 min read Read →
HTTP/3 with QUIC: Connection Setup ComparedHTTP/2 over TCP + TLS 1.3TCP HandshakeTLS HandshakeRequest1 RTT1 RTTData2 RTT to first bytePacket loss blocks all streams(head-of-line blocking at TCP layer)HTTP/3 over QUIC (UDP)QUIC + TLS combinedRequest1 RTTData1 RTT (0-RTT on repeat visit)Packet loss affects one stream only(independent streams at QUIC layer)QUIC moves transport and encryption into user space over UDP port 443Roundtrips1instead of 2 to 3 with TCP+TLSConnection MigrationWiFi -> 5Gno new handshakeStream Isolationno HoLloss isolated per streamPortUDP 443Alt-Svc header requiredServer-side activationNginx 1.25+ | LiteSpeed | Caddy | Cloud edgeopen UDP 443 + send Alt-SvcAutomatic fallbackBrowsers without HTTP/3 keep using HTTP/2backward compatible and low riskQUIC | 0-RTT | Connection ID | Alt-Svc | UDP 443 | TLS 1.3 | Multiplexing without HoL blocking
Performance Jun 3, 2026

HTTP/3 and QUIC for Faster Online Shop Speed

HTTP/3 with QUIC cuts latency and connection setup time in online shops. How the protocol works, when migration pays off and how to enable it correctly.

13 min read Read →
Interaction to Next Paint - Anatomy of an InteractionClick / Tap / Key press until the next frame1. Input Delay40msMain thread busy with a long task2. Processing Time95msEvent handler execution3. Presentation Delay30msRendering until next frameINP ThresholdsGood< 200msNeeds Work200-500msPoor> 500msSum = INP value165msInputProcessingPaintSlowest interaction is reported (75th percentile)Break up long tasksscheduler.yield()Chunking, yieldingSlim down handlersrequestIdleCallbackOffload to Web WorkerTame third partiesasync, deferLazy on interactionBatch DOM workcontent-visibilityAvoid layout thrashingMeasure in the field, not the labField data | web-vitals.js | Lab and field measurement | Long Animation Frames API
Core Web Vitals Jun 1, 2026

Optimizing INP: Improving Interaction to Next Paint

Optimizing INP: how to bring Interaction to Next Paint below 200 milliseconds. Targeted relief for long tasks, event handlers and third-party scripts.

13 min read Read →
Core Web Vitals 2026 - Metrics DashboardLCP1.8sLargest Contentful PaintINP180msInteraction to Next PaintCLS0.04Cumulative Layout Shift2024: FID Removed | 2025: INP Required | 2026: Stricter ThresholdsThresholds 2026MetricGoodNeeds WorkPoorLCP2.5s4.0s4.0s+INP200ms500ms500ms+CLS0.10.250.25+Optimization Pipeline1. Measure (Field)2. Analyze3. Optimize (Code)4. Validate (Field)Server OptimizationTTFB, CDN, CachingHTTP/3, CompressionRendering PerformanceCritical CSS, Lazy LoadJS Budgets, Tree ShakingInteractivity (INP)Event Handlers, Main ThreadWeb Workers, DebouncingLayout StabilityDimensions, FontsReserved AreasField Data | Lab and Field Measurement | Browser Developer Tools
Performance May 24, 2026

Core Web Vitals 2026: New Metrics and Strategies

Core Web Vitals 2026: INP replaces FID, updated thresholds and optimization strategies. How to measure and improve your scores systematically.

14 min read Read →
TTFB Analysis: Server Response Time in DetailTTFB WaterfallDNS (45ms)TCP (30ms)TLS (55ms)Server Processing (420ms)TTFB: 550msTTFB ComponentsDNS ResolutionNameservers, TTL, AnycastTLS HandshakeTLS 1.3, OCSP StaplingBackend LogicPHP, DB Queries, APIDatabaseQueries, Indexes, BufferOptimization LeversOpcode CacheOPcache, JIT CompilerHTTP CachingVarnish, Redis, CDNDB TuningQuery Optimization, IndexesCDN + EdgeGeo-Distribution, PoPsTarget: TTFB below 800ms (Google) | Ideal: below 200msShared Hosting800-2000msShared ResourcesVPS / Managed300-600msDedicated CPU/RAMOptimized Server100-300msOPcache, DB TuningCDN + Edge Cache50-150msGlobal DistributionDNS Prefetch | TLS 1.3 | HTTP/2+3 | Brotli | OPcache | Redis | Query Cache | CDN PoPs
Performance May 21, 2026

TTFB: Why Server Response Time Determines Everything

Optimize Time to First Byte: identify causes of slow server response times and fix them systematically with DNS, TLS, backend and caching strategies.

14 min read Read →