Website Speed Optimization: Fixing Core Web Vitals for Good
A field-data-first approach to LCP, INP, and CLS — images, JavaScript, third parties, delivery, and performance budgets.
Speed is the one performance metric that touches revenue, search visibility, and brand perception at the same time. The good news is that most slow sites are slow for a handful of well-understood reasons, and each of them has a durable fix that does not require a rebuild.
Key takeaways
- Core Web Vitals — LCP, INP, and CLS — are the measurements Google actually uses.
- Images and third-party scripts cause the majority of real-world slowdowns.
- Field data from real users matters more than a single lab score.
- Performance budgets keep a fast site fast after launch.
Measure the right things first
Largest Contentful Paint measures how quickly the main content appears and should land under 2.5 seconds. Interaction to Next Paint replaced First Input Delay and measures responsiveness across the whole session, with a 200 millisecond target. Cumulative Layout Shift measures visual stability and should stay below 0.1.
Lab tools like Lighthouse are useful for diagnosis but they simulate one device on one connection. Field data from the Chrome User Experience Report or your own real user monitoring reflects the devices and networks your customers actually have, which is usually slower than the machine you tested on.
Start here: Pull the last 28 days of field data for your top five templates before changing anything. Optimizing a page nobody visits is the most common wasted sprint in performance work.
Images: the highest-leverage fix
On a typical marketing site, images represent well over half the transferred bytes and are almost always the LCP element. Modern formats and correct sizing routinely cut image weight by seventy percent with no visible quality loss.
The fix is mechanical. Serve AVIF or WebP with a fallback, generate responsive variants and let the browser choose with srcset, set explicit width and height to reserve space, lazy-load anything below the fold, and preload the hero image so it is not discovered late.
- Convert to AVIF or WebP and cap dimensions at the largest rendered size.
- Use srcset and sizes so phones never download desktop assets.
- Set width and height attributes to eliminate layout shift.
- Lazy-load below-the-fold media, and never lazy-load the hero.
- Preload the LCP image with fetchpriority high.
Tame JavaScript and third parties
Every kilobyte of JavaScript must be downloaded, parsed, and executed, and execution is the expensive part on mid-range phones. Route-level code splitting, tree shaking, and removing abandoned dependencies typically reclaim a substantial share of main-thread time.
Third-party tags are the silent killer. Chat widgets, heat mapping, tag managers, A/B testing platforms, and ad pixels each add network requests and main-thread work that your team did not write and cannot profile easily. Audit them quarterly and delete the ones nobody has looked at in six months.
- Split bundles by route so the homepage does not ship checkout code.
- Defer non-critical scripts and load analytics after interaction where possible.
- Self-host fonts, subset them, and use font-display swap.
- Replace heavy embeds with a facade that loads on click.
- Audit and prune third-party tags on a schedule.
Server and delivery
Time to First Byte sets the ceiling for everything that follows. Static or pre-rendered pages served from a CDN edge, sensible cache headers, and server-side rendering for content that must be crawlable will beat a client-rendered application on nearly every metric.
Compression and protocol choices still matter: Brotli over gzip, HTTP/2 or HTTP/3, and long cache lifetimes on fingerprinted assets. These are one-time configuration wins that keep paying.
Keep it fast with a budget
Sites regress because nobody owns the number. A performance budget — for example, 150KB of JavaScript, 1MB total page weight, LCP under 2.5 seconds on a mid-tier phone — converts performance from an occasional cleanup project into a build-time gate.
Wire the budget into continuous integration with Lighthouse CI or a bundle-size check, and route real user monitoring alerts to whoever owns the template. A regression caught in a pull request costs minutes; the same regression found a quarter later costs a sprint.
Frequently asked questions
How much revenue does speed actually affect?
Published studies from large retailers consistently show conversion improvements in the range of several percent per second of load time saved. The exact number varies, but the direction is never ambiguous.
Is a perfect Lighthouse score the goal?
No. Field Core Web Vitals passing for 75 percent of real users is the goal. A perfect lab score with failing field data means you tested a device your customers do not own.
Ready to move on this?
We run performance engagements as a fixed-scope audit followed by implementation against a measurable target. If your Core Web Vitals are failing, we will tell you exactly which changes will move them.