Skip to content
Core Web Vitals specialists

Fundamentals & strategy

Loading time is not an end in itself but a chain of network, server, transfer and rendering in the browser. This category lays the groundwork: how a page display is produced technically, which steps block each other, why lab and field measurements differ, and which order of work delivers the greatest effect on a limited budget. We classify common recommendations, separate effective measures from cosmetics and show how optimisation can be anchored permanently in operations — with page weight budgets, checks before every release and clear responsibilities. Articles on sustainability are included too: less transferred data means less energy per page view. We also clarify which metrics are suitable for management reporting and which are only useful inside the technical team.

Sustainable websites: from byte to gram of CO2Fewer byteskeep images, JavaScript, fonts leanLess energykWh in the data center and deviceLess CO2smaller footprint per viewWhere page emissions come fromImages69.6 %JavaScript20.8 %Fonts4.8 %CSS3.1 %HTML1.7 %SWD model, 90th percentile (HTTP Archive Web Almanac)Cut page weight-75 %fewer bytesfrom a 2.0 MB median toward a 0.5 MB targetFewer bytes mean less energy, less CO2 and faster Core Web Vitals0.33 gCO2 per page view at the median(HTTP Archive Web Almanac)363 gCO2 per kWh in the Germanpower mix 2024 (Umweltbundesamt)20 bnkWh of data-center electricityin Germany 2024 (Bitkom)

Sustainable Websites: How Performance Cuts CO2

Sustainable websites: how fewer bytes, lean JavaScript and efficient caching cut the CO2 footprint while improving Core Web Vitals at the same time.

12 min read
Three Views on Speed DataLab (Lighthouse)one simulated testfixed device, fixed networkno ranking impactCrUX (field data)real Chrome users28-day window, p75Google's ranking sourceYour own RUMall browsers, liveelement and script detailshows the whyPerformance budget at the 75th percentilegoodneeds improvementpoor75th percentileLCP lab: 1.9 sLCP field p75: 3.1 slab value clean, field data breaks the budget

RUM vs. CrUX: Using Field Data Right for Speed

Lighthouse lab scores do not affect ranking. Google rates Core Web Vitals via CrUX field data at the 75th percentile. How to use RUM, CrUX and budgets.

15 min read
CLS vs. Visual Stability Index - what gets measuredCLS - the load phase onlyPage render0 to ~5 sscroll, interaction and late loading stay unaccounted forblind spot after loadVisual Stability Index - the whole visitLoadingimages, fontsScrollinglazy contentInteractionclick, filterDwell timebanners, adsintentional movements are recognized - unexpected jumps count across the whole visitintent-aware scoring instead of load phase onlyField data May 2026 (CrUX)81.3%good CLSof origins55.9%pass all threeCore Web VitalsWhat VSI captures on topshifts during scroll and lazy loadinglate-injected banners and sticky elementsmovement during interaction

Visual Stability Index 2026: The Next CLS Step

Visual Stability Index (VSI): in 2026 Google measures layout stability across the whole visit, not just page load. How to make your website future-proof.

14 min read
Progressive Image Display: Perception vs. BytesFrom the tiny placeholder to the sharp image along the timeline0 msHTML parsed~50 msLQIP visibleloadingBlur-up fadedonesharp imageEmpty / CLS riskLQIP ~400 bytesBuilding / fadeFully resolved83.3%LCP is an image (desktop)~400 Btypical LQIP size11-15%faster perceived with feedbackReserved space via width/height + aspect-ratio = no layout shiftThe placeholder fills the box from the first millisecond, the real image fades in on top

Progressive Image Display: LQIP and Blur-up for Speed

LQIP, blur-up and responsive images for faster image build-up: better perceived and measured performance, fewer layout shifts, strong Core Web Vitals.

13 min read
Hydration Cost: Full Hydration vs. Islands ArchitectureServer-Side Rendering (HTML generated on the server)0s1s2s3sFull HydrationJS download (entire bundle)Hydration of the whole pageMain thread blockedinteractiveIslands / partial hydrationisland JS onlyselectiveinteractiveinteractive soonerinteractive earlierTime to Interactive80%less JS possible200msTBT target mobile8.4%more conversions per 0.1sServer renderHTML firstCritical islandshydrate by priorityLazy/on demandon interactionResumabilityno re-run

Server-Side Rendering and Hydration Done Right

SSR delivers HTML fast, but hydration costs performance. Islands, partial hydration and resumability for fast shops and strong Core Web Vitals.

15 min read
Cumulative Layout Shift - unstable vs. stable shop layoutUnstable - CLS 0.28HeaderImage without width/heightloads in lateProduct title and priceCookie banner injected lateButton shifts downwardWeb font swap shifts textAd without reserved spaceStable - CLS 0.02HeaderImage reserved via aspect-ratiospace reserved upfrontProduct title and priceButton stays in placeFont fallback metrically matchedAd slot with fixed heightOverlay as position fixedCLS thresholdsGoodMidPoor0.10.250.25+Top causesUnsized images, fontsAds, late injectionsBanners without placeholdersSession windowlargest shift burstmax 5s window1s gap per window

Avoid Cumulative Layout Shift: Stable Shops

Avoid CLS: fix layout shifts from images, fonts, ads and injections precisely. The result is measurably more stable shop layouts with a good CLS score.

13 min 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)

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

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

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

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
Critical CSS: Above-the-Fold Rendering PipelineWithout Critical CSSHTML loaded - waiting for CSS...Render-Blocking: styles.css (180 KB)Render-Blocking: vendor.css (95 KB)Blocked 1.8sLCP: 3.2sFCP: 2.4sWhite screen until CSS fully loadedWith Critical CSSInline Critical CSS (8 KB in HTML Head)Header, Hero, Navigation, Typography, LayoutInstant rendering of visible areaLoad remaining CSS async: media=print, onload=this.media=allLCP: 1.4sFCP: 0.6sInstantly visible content, rest loads in backgroundResult: 56% Faster LCP | 75% Faster FCP1. ExtractIdentify critical-path CSSfor the viewportPenthouse, Critical, Critters2. InlineEmbed critical CSS as styletag in the HTML headMax. 14 KB (TCP Window)3. Defer RestLoad full CSS asyncafter initial renderingmedia=print + onload TrickCommon Pitfalls to AvoidToo much CSS inlinedWeb fonts forgottenFOUC not testedNo fallback styling

Critical CSS: Visible Area Loaded in Milliseconds

Extract, inline and automate Critical CSS. Load the visible area in milliseconds and sustainably improve your LCP score.

13 min read
Image Optimization: Format PipelineSource ImagePNG/JPEG (2400x1600)3.2 MB OriginalBuild Pipeline1. Resize (srcset breakpoints)2. Format conversionOutput FormatsAVIFWebPJPEGFallback chain in picture elementResponsive Delivery with srcset and sizesMobile400w AVIF: 18 KB400w WebP: 24 KBSavings: 99%Tablet800w AVIF: 42 KB800w WebP: 58 KBSavings: 98%Desktop1200w AVIF: 78 KB1200w WebP: 105 KBSavings: 97%Retina2400w AVIF: 145 KB2400w WebP: 195 KBSavings: 94%50%smaller than WebP96%Browser Support WebP92%Browser Support AVIF-40%LCP ImprovementLazy Loading StrategyAbove the Fold: eagerViewport + 200px: loading=lazyfetchpriority=high for LCPdecoding=async

Image Optimization 2026: WebP, AVIF and Responsive Delivery

WebP, AVIF, responsive images and lazy loading: How to optimize images for faster loading times, better Core Web Vitals and up to 95% smaller image data.

13 min read
JavaScript Performance Budget PipelineSource Bundle1.8 MB JavaScript (uncompressed)145 npm packagesTBT: 3200ms | INP: 450msOptimizationTree ShakingCode SplittingDead Code EliminationOptimized Bundle380 KB JavaScript (compressed)42 npm packagesTBT: 280ms | INP: 85msPerformance Budget: max 150 KB JS (initial, compressed)Critical PathFramework Core: 45 KBRouter: 8 KBCritical CSS-in-JS: 12 KBTotal: 65 KBLazy ChunksProduct Page: 28 KBCheckout: 35 KBSearch: 18 KBLoaded on demandThird-PartyAnalytics: 22 KBConsent: 15 KBChat Widget: 45 KBBudget Risk!Bundle AnalysisTreemap visualizationDuplicate detectionImport cost trackingCI/CD integration-79%JS bundle reduced200msINP target150KBInitial JS budget3xfaster interactionOptimization Path1. Audit and Measure2. Define Budget3. Split and Shake4. Audit Third-Party5. CI/CD Checks

JavaScript and Performance Budgets: Less Code, Faster Websites

Minimize JavaScript impact on INP and loading time: performance budgets, code splitting, tree shaking and third-party management for Core Web Vitals.

14 min read
Multi-Tier Caching ArchitectureBrowser / ClientCache-Control, ETag, SWCDN Edge (Global PoPs)Static assets, HTML cache, BrotliVarnish HTTP AcceleratorVCL Rules | Grace Mode | Cache Tags | ESIHit Rate: 95%+ | Response Time: 1-5msCache MISSRedisSession Cache: 0.2msObject Cache: 0.5msFragment Cache: 0.3msApplication ServerPHP/Node.js RuntimeOPcache / JITTemplate RenderingDatabaseQuery Cache: disabledInnoDB Buffer Pool: 80%Slow Query Log: active1-5msVarnish Cache Hit95%+Cache Hit Rate0.2msRedis Latency-90%TTFB ReductionCache-Control: max-age | ETag | stale-while-revalidate | Purge API | Tag-based Invalidation

Caching Strategies: Varnish, Redis and Browser Cache

Multi-tier caching architecture with Varnish, Redis and browser cache: strategies for TTFB under 100ms, 95% cache hit rate and optimal invalidation.

14 min read