Website Speed Optimization: A Developer's 2026 Guide

How fonts and modern image formats affect LCP and CLS

Fonts and images are the two asset types most likely to own your LCP and CLS scores. Getting both right is one of the highest-leverage moves in the optimization stack.

Font loading with font-display

The font-display descriptor in your @font-face rule controls what the browser shows while a web font loads. The two values that matter most for performance:

• font-display: swap renders text immediately in the fallback font, then swaps to the web font when it loads. Fast to first paint, but the swap itself causes a layout shift if the fallback and web font have different metrics.
• font-display: optional gives the font a very short load window; if it doesn't arrive in time, the browser uses the fallback for the entire page visit. Near-zero CLS, but the web font may not appear on first load.

Pair font-display: swap with font metric overrides (size-adjust, ascent-override, descent-override) to make the fallback font dimensionally match the web font. The swap happens invisibly because the layout doesn't shift.

WOFF2, WebP, and AVIF

Serve fonts exclusively in WOFF2. It offers the best compression of any web font format and has full support across modern browsers. A subsetted WOFF2 file for a single weight of a Latin-script font typically runs 15-25KB.

For images, AVIF and WebP deliver significantly smaller file sizes than JPEG at equivalent visual quality. AVIF compresses more aggressively and handles photographic content particularly well; WebP is the safer default given its longer browser support history. Use the <picture> element to serve AVIF to supporting browsers with WebP and JPEG fallbacks:

Always include explicit width and height attributes. The browser uses the aspect ratio to reserve space before the image loads, which eliminates the layout shift that pushes CLS scores above 0.1.

‍

Lazy loading beyond images: iframes and videos

The loading="lazy" attribute is well understood for images, but the same principle applies to iframes and video embeds — and the performance gains are often larger because these elements are heavier.

Iframes

Add loading="lazy" to any iframe that appears below the fold. This defers the iframe's network requests (including all its sub-resources) until the user scrolls near it. A YouTube embed without lazy loading fires dozens of requests on page load; with loading="lazy", those requests don't start until the embed is about to enter the viewport.

For third-party embeds where you want even more control, use a facade: render a static thumbnail image in place of the iframe and swap in the real embed only on user click. This approach eliminates the third-party script load entirely until the user explicitly requests it, which can remove hundreds of kilobytes from the initial page weight.

Videos

For self-hosted videos, set preload="none" to prevent the browser from downloading video data before the user interacts. Combine it with a poster attribute so the video area shows a static image rather than a blank space:

For videos used as background or decorative elements, consider replacing them with an animated AVIF or WebP image. The visual result is often indistinguishable, and the file size is a fraction of the equivalent video.

‍

HTTP caching strategies: Cache-Control, ETag, and validation

Caching is the most cost-effective way to reduce page load time for returning visitors. The browser cache eliminates network requests entirely for cached resources; a CDN cache eliminates origin round trips for new visitors.

Cache-Control

The Cache-Control header tells browsers and CDNs how long to store a response. Key directives: max-age=31536000, immutable for versioned static assets (JS bundles, CSS files, images with content hashes in their filenames) — the browser never re-requests these until the filename changes. no-cache for HTML documents — the browser must revalidate with the server on every request, but if the content hasn't changed, the server returns a 304 and the browser uses its cached copy. stale-while-revalidate for API responses and CDN-cached HTML — serves the stale cached version immediately while fetching a fresh copy in the background.

ETag and conditional requests

An ETag is a fingerprint the server assigns to a response. On subsequent requests, the browser sends If-None-Match: [etag]. If the content hasn't changed, the server returns 304 Not Modified with no body — saving bandwidth and reducing load time to the round-trip cost of the validation request alone.

Last-Modified / If-Modified-Since works the same way using a timestamp instead of a hash. ETags are more reliable because timestamps can be imprecise across server clusters.

Practical caching setup

Set long max-age on all fingerprinted assets and no-cache on HTML. This combination gives you instant cache invalidation (change the filename, the browser fetches fresh) with zero stale-content risk on HTML. For a CDN layer, add s-maxage to control CDN TTL independently of browser TTL:

Cache-Control: public, max-age=31536000, immutable   # versioned assets
Cache-Control: no-cache                               # HTML
Cache-Control: public, s-maxage=3600, stale-while-revalidate=86400  # CDN-cached HTML

‍

How hosting environment and server location affect your speed

Infrastructure sets the performance floor. A slow origin or a server on the wrong continent limits what every frontend optimization above can achieve. Verify origin TTFB before spending engineering time on frontend work.

Hosting tier matters

Shared hosting environments often have variable TTFB because server resources are contended. A VPS or dedicated instance with a properly tuned web server (Nginx, Caddy) and a PHP-FPM or Node.js process manager typically delivers more consistent sub-200ms TTFB. Managed cloud platforms (Vercel, Netlify, AWS CloudFront with Lambda@Edge) push rendering to the edge and can deliver HTML TTFB under 50ms for SSG content.

Cloudflare's guidance recommends targeting average server response times under 200ms. If your origin consistently exceeds that, the CDN layer becomes load-bearing rather than a performance enhancement on top of a fast origin.

Server location and RTT

A user in Los Angeles hitting an origin server in Frankfurt adds roughly 140ms of RTT before a single byte arrives. For a page requiring three sequential server round trips (HTML → CSS → JS), that's 420ms of pure latency before the browser has what it needs to render. A CDN with a PoP in Los Angeles reduces that to under 5ms per round trip.

For teams serving North American audiences, choose a primary origin in a US Central or US East region and let the CDN handle geographic distribution. For global audiences, consider multi-region origins with latency-based routing. The performance implications of server geography compound quickly at scale.

DNS resolution speed

DNS adds latency before the first TCP connection. Use a fast DNS provider (Cloudflare DNS, AWS Route 53) and set a reasonable TTL — 300 seconds for records that change infrequently. Avoid DNS chains (CNAME pointing to CNAME pointing to CNAME) that require multiple resolution steps.

‍

The performance fixes most teams get wrong

Most teams treat Lighthouse score as the goal. It isn't. The score is a lab proxy for user experience; the actual goal is moving p75 field metrics into the "good" range for real users on real connections. Chasing a 100 Lighthouse score on a desktop emulation while your mobile p75 LCP sits at 4.2s is a common and expensive misdirection.

The second mistake is patching around a slow origin. We see this constantly: teams spend weeks optimizing images and deferring scripts, then wonder why LCP barely moves. If TTFB is 1.8s, the LCP clock starts at 1.8s before the browser has even discovered the LCP image. Fix the origin first.

Third-party script budgets are almost universally ignored until a performance crisis forces the conversation. A single A/B testing script, a chat widget, and two analytics tags can collectively add 400-600ms of main-thread blocking time. The fix isn't always removal — it's sequencing. Load third-party scripts after the page is interactive, use async or defer, and set a hard budget (for example, no more than 30KB compressed of third-party JS per page) enforced in Lighthouse CI.

The prioritization framework that actually works in practice: triage by traffic volume times revenue impact times metric severity. A checkout page with a "poor" INP score gets fixed before a blog post with a "needs improvement" LCP. Quick wins (images, compression, caching) ship first because they move the metric in the current CrUX window. Pipeline changes (code-splitting, SSG migration) follow because they require coordination. Infrastructure changes (CDN configuration, origin upgrade) run in parallel when the team has the capacity, because they set the floor everything else builds on.

‍

Your site's performance deserves more than a score

Slow pages cost conversions. A faster site isn't just a better user experience — it's a direct input to revenue, paid media efficiency, and organic search ranking. The Branded Agency delivers strategic website development that treats performance as a first-class requirement, not an afterthought.

Our performance engagements start with a technical audit: we capture your field p75 baseline across all critical URLs, run lab diagnostics with WebPageTest and Lighthouse, and deliver a prioritized roadmap ranked by impact relative to engineering cost. From there, we handle implementation — image pipelines, JS deferral, CDN configuration, critical CSS, and Lighthouse CI setup — or work alongside your existing team. For Webflow and Shopify builds, we bring platform-specific expertise that generic audits miss. The result is a site that loads fast for real users, not just in a lab run.

Ready to move your Core Web Vitals into the "good" range? Request a technical audit and we'll show you exactly where your performance budget is leaking and what to fix first.

‍

Authoritative Docs and Tools to Bookmark

• PageSpeed Insights: Combined field + lab report for any URL; the fastest way to check p75 CWV and get Lighthouse diagnostics in one place.
• Core Web Vitals documentation — Google Developers: The canonical reference for LCP, INP, and CLS definitions, thresholds, and how Google uses them in search.
• Web.dev: p75 thresholds: Explains the data-driven rationale behind the p75 aggregation rule and the good/needs improvement/poor bands.
• Web.dev: Vitals: Covers the web-vitals JS library, RUM setup, and monitoring patterns for ongoing field measurement.
• Understanding latency — MDN: The clearest explanation of how DNS, TCP, and TLS latency compounds across multi-request pages, with throttling preset reference data.
• WebPageTest: Free filmstrip testing with custom throttling, geographic locations, and waterfall detail — the best free tool for deep LCP and TTFB debugging.
• GTmetrix: Scheduled synthetic monitoring with historical trend views; useful for tracking performance over time and catching gradual regressions.
• Web performance best practices — MDN: Practical checklist covering critical rendering path, resource hints, compression, and image optimization with tool recommendations.

‍

Sources

• Core Web Vitals documentation — Google Developers
• Understanding latency - Performance | MDN
• Web.dev: Defining Core Web Vitals thresholds
• Web Performance Optimization: Overview and Playbook — Sujeet Jaiswal
• PageSpeed Insights

‍

Recommended

• Shopify Speed Optimization: Fix Slow Stores in 2026
• Website Design for Creatives That Wins More Clients in 2026
• Webflow SEO: Optimize Your Site for Higher Rankings in 2026
• Advanced Webflow SEO: Optimize Beyond the Basics