Web performance quick wins: 10 things you can ship this weekend

Before changing anything on a client's site last spring, I ran Lighthouse and found a Largest Contentful Paint of 4.8 seconds. The instinct is to start optimizing images immediately. Instead, the waterfall in WebPageTest showed the actual bottleneck was a render-blocking web font request that took 1.9 seconds on its own, loaded from a third-party CDN with no preconnect hint. Fixing that one line moved LCP to 2.6 seconds before we touched a single image. The lesson: measure before you guess.

Step one: get a baseline, not an opinion

Run Lighthouse in Chrome DevTools (or PageSpeed Insights for the same engine with real-world CrUX data layered in) and record your actual Core Web Vitals numbers — Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint — before making any change. Without a documented baseline you can't tell afterward whether your changes helped, hurt, or did nothing, which is more common than people assume.

Read the waterfall before touching images

Everyone's first instinct for performance is image compression, and it does matter, but WebPageTest's request waterfall view will often show you that the actual delay is a render-blocking third-party script, an unoptimized web font, or a slow API call the page waits on before painting anything. Spend fifteen minutes reading the waterfall chart before deciding where to spend your weekend.

Preconnect and preload for the requests that block rendering

Adding <link rel="preconnect"> for third-party origins (fonts, analytics, CDNs) lets the browser start the DNS lookup and 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 critical font tells the browser to fetch it immediately instead of discovering it partway through CSS parsing.

Image format and sizing, done properly

Serving a 3000px-wide product photo into a 400px-wide card is one of the single largest and easiest wins available 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 version rather than the desktop-sized file.

Layout shift is usually caused by three specific things

Images and embeds without explicit width and height attributes, web fonts that swap in and reflow text (fixable with font-display: swap paired with matched fallback font metrics), and ads or dynamic content injected above existing content without reserved space are responsible for the vast majority of Cumulative Layout Shift issues. Fixing all three is usually a half-day task, not a redesign.

JavaScript execution time versus JavaScript file size

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

Re-measure and document what actually moved the number

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

Performance troubleshooting FAQ

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 affects perceived load speed most directly and issues with it often cascade into or reveal issues with the other two metrics.

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

How often should I re-run performance audits? At minimum after any significant page or dependency change, and ideally on an ongoing basis via Search Console's Core Web Vitals report, since third-party scripts and ad networks can silently degrade performance over time without any change on your end.

Is mobile or desktop performance more important to optimize for? Mobile, for most sites, since mobile devices have less CPU headroom and often slower networks, and Google's indexing and Core Web Vitals evaluation are primarily mobile-based for most sites today.

Third-party scripts are the bottleneck nobody wants to touch

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. Auditing third-party script impact with Lighthouse's "reduce impact of third-party code" section and presenting the actual millisecond cost to whoever owns that tag is often more effective than trying to fix it unilaterally in code.

Font loading strategy affects more than layout shift

Beyond font-display: swap, subsetting a web font to only the character set and weights you actually use, rather than downloading a full family with hundreds of glyphs you never render, can cut font payload significantly. For a site using only Latin characters in three weights, a full unsubsetted variable font can be needlessly larger than a properly subsetted static version covering the actual content.

Caching headers get overlooked because they seem to just work until they 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, silently hurting return-visit performance in a way a single-visit Lighthouse run won't even reveal. Checking response headers on your actual static assets, not just your HTML, is a five-minute audit 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 amount of frontend optimization touches, and a slow database query or an under-provisioned server can add a full second or more before any of the frontend techniques in this list even get a chance to matter. Checking TTFB specifically in your Lighthouse report before spending a weekend on frontend tuning avoids optimizing the wrong end of the pipeline.