Web performance quick wins: fixing Core Web Vitals fast

Running Lighthouse on a client's homepage last spring turned up a Largest Contentful Paint of 4.8 seconds. The instinct is to start compressing images immediately. Instead, the request waterfall in WebPageTest showed the real bottleneck was a render-blocking web font loaded from a third-party CDN with no preconnect hint, taking 1.9 seconds on its own. Fixing that single line moved LCP to 2.6 seconds before a single image was touched. Measure before you guess — it's the difference between a fifteen-minute fix and a wasted weekend.

Get a documented baseline before changing anything

Run Lighthouse in Chrome DevTools, or PageSpeed Insights for the same engine layered with real-world CrUX field data, and record your actual Core Web Vitals — Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint — before making a single change. Without a documented baseline, you have no way to tell afterward whether a change helped, hurt, or did nothing at all, which happens more often than people expect.

Read the request waterfall before touching images

Image compression matters, but it's often not the actual bottleneck. WebPageTest's waterfall view will frequently show that the real delay is a render-blocking third-party script, an unoptimized web font, or a slow API call the page waits on before painting anything visible. Spend fifteen minutes reading the waterfall before deciding where to spend the rest of your time.

Preconnect and preload for anything blocking render

Adding <link rel="preconnect"> for third-party origins — fonts, analytics, CDNs — lets the browser start DNS lookup and the TLS handshake before it even discovers the resource is needed, often saving 100-300ms per origin. Adding <link rel="preload"> for your actual LCP image or a critical font tells the browser to fetch it immediately instead of discovering it partway through CSS parsing.

Image sizing and format are still one of the biggest wins

Serving a 3000px-wide product photo into a 400px-wide card is one of the largest and easiest performance losses on most sites. Resize images to their actual maximum display dimensions and serve modern formats like WebP or AVIF, which typically cut file size 25-50% over JPEG at equivalent visual quality. Use the srcset attribute so mobile devices download an appropriately smaller file rather than the full desktop-sized one.

Layout shift almost always traces back to three specific causes

Images and embeds without explicit width and height attributes, web fonts that swap in and reflow visible text (fixable with font-display: swap paired with matched fallback font metrics), and dynamically injected content like ads that don't reserve space in advance account for the vast majority of Cumulative Layout Shift issues. Fixing all three is usually a half-day task, not a redesign.

Execution time matters more than raw bundle size

A smaller JavaScript bundle that still does expensive work on the main thread during load can produce worse Interaction to Next Paint than a slightly larger bundle that defers non-critical work until after initial render. Use Chrome DevTools' Performance panel to look at actual main-thread blocking time, not just transferred file size, when deciding what to defer or code-split.

Third-party scripts are the bottleneck nobody wants to own

Analytics tags, chat widgets, ad tags, and A/B testing scripts routinely account for more main-thread blocking time than a site's own code, yet they're politically the hardest thing to remove because a different team usually owns them. Lighthouse's "reduce impact of third-party code" section gives you the actual millisecond cost to bring to whoever owns that tag, which tends to be more effective than trying to fix it unilaterally.

Font subsetting cuts payload beyond just font-display

Beyond font-display: swap, subsetting a web font to only the character set and weights actually used, instead of downloading a full family with hundreds of unused glyphs, can meaningfully shrink font payload. A site using only Latin characters in three weights can end up with an unsubsetted variable font that's needlessly larger than a properly subsetted static version covering the same content.

Caching headers matter until they silently don't

A misconfigured cache-control header that sets a short max-age on genuinely static assets like versioned JavaScript bundles forces repeat visitors to re-download files that never changed, quietly hurting return-visit performance in a way a single-visit Lighthouse run won't reveal. Checking response headers on your actual static assets, not just the HTML document, is worth doing after any hosting or CDN migration.

Server response time is easy to forget when you're focused on the frontend

Time to First Byte — the delay before the browser receives even the first byte of HTML — is entirely a backend and hosting concern that no frontend technique touches. A slow database query or an under-provisioned server can add a full second or more before any frontend optimization even gets a chance to matter. Check TTFB specifically before spending a weekend on frontend tuning that's optimizing the wrong end of the pipeline.

Re-measure one change at a time

After each individual change, re-run Lighthouse and note exactly which metric moved and by how much, rather than bundling five changes together and testing once at the end. This is the only reliable way to build a mental model of which fixes matter most on your specific site, since the answer genuinely differs between projects.

Frequently asked

Which Core Web Vital should I prioritize if I can only fix one? Largest Contentful Paint is usually the highest-leverage starting point since it drives perceived load speed most directly, and fixing it often surfaces or resolves issues with the other two metrics along the way.

Do caching and a CDN matter as much as code-level fixes? Often more — proper cache-control headers and a CDN serving assets near your actual visitors can shave hundreds of milliseconds off every request without touching application code at all.

How often should performance audits be repeated? At minimum after any significant page or dependency change, and ideally on an ongoing basis through Search Console's Core Web Vitals report, since third-party scripts can silently degrade performance with no change on your end.