Page speed stopped being a nice-to-have when Google made Core Web Vitals a ranking signal. But the more immediate cost of a slow site is usually conversion rate, not rankings — visitors abandon slow pages, and the ones who stay are already annoyed before they’ve read a word. Speed optimization is one of the few technical investments that pays back in multiple directions simultaneously. That return is especially clear in high-traffic verticals like software for restaurants, where a slow ordering interface directly costs conversions.

What Core Web Vitals Actually Measure

Google’s Core Web Vitals are three specific metrics that measure how a page feels to a real user:

  • Largest Contentful Paint (LCP): How long until the main content — usually a hero image or headline — is visible. Target: under 2.5 seconds.
  • Interaction to Next Paint (INP): How responsive the page is when a user clicks or taps something. Replaced First Input Delay in 2024. Target: under 200 milliseconds.
  • Cumulative Layout Shift (CLS): How much the page layout shifts unexpectedly while loading. Unstable layouts that jump around as elements load frustrate users. Target: under 0.1.

These metrics are measured on real users via the Chrome User Experience Report (CrUX), which means lab scores in PageSpeed Insights and field data can differ significantly. The field data is what Google uses for ranking. It’s worth knowing which one you’re actually looking at.

The Common Bottlenecks (and Which Ones Matter)

Most speed problems I encounter fall into a predictable set of categories. The order of impact varies by site, but these are worth checking systematically:

  • Unoptimized images: The single most common culprit. Full-resolution images loaded on mobile, wrong formats (JPEG/PNG where WebP or AVIF would be half the size), no lazy loading on below-fold images.
  • Render-blocking resources: JavaScript and CSS that loads in the document head and delays paint. Deferred or async loading of non-critical scripts removes this.
  • No caching: Every page request hitting the server fresh, rebuilding the page each time. A page cache serves a pre-built HTML file instead, reducing server response time dramatically.
  • Third-party scripts: Analytics, chat widgets, ad tags, social embeds. Each one adds a DNS lookup, a connection, and execution time. They’re also outside your control, so they show up as INP problems on sites that have otherwise done everything right.
  • Hosting infrastructure: Shared hosting on an overloaded server has a floor on how fast it can respond regardless of other optimizations. Time to First Byte (TTFB) above 600ms usually points here.
  • Plugin bloat on WordPress: Themes and plugins that load CSS and JS on every page, not just the pages where they’re used. A page builder running on a simple blog post carries overhead it doesn’t need.

How I Approach a Speed Audit

The first thing I do is measure before touching anything. PageSpeed Insights, WebPageTest, and Chrome DevTools give different views of the problem — lab data, waterfall timing, and real-user field data. The goal is to find the bottlenecks with the most leverage, not run through a generic checklist.

Then I prioritize by impact. Fixing image sizing on a page that’s already fast won’t move the needle. Finding a 400KB JavaScript file loading synchronously in the head will. The fixes that take 20% of the effort and produce 80% of the gain are what matter first. Surfacing that data efficiently often means building a custom API endpoint that aggregates performance metrics from multiple monitoring sources into one view.

On WordPress sites, this usually involves: a server-side page cache, image optimization and next-gen format conversion, deferring non-critical JavaScript, cleaning up plugin overhead, and often switching to a faster hosting tier if the server is genuinely the bottleneck.

What Not to Do

A few approaches I see pushed heavily that I’m skeptical of:

AMP (Accelerated Mobile Pages) was a Google initiative that’s effectively been deprecated in favor of Core Web Vitals. Don’t build new AMP pages in 2024. Sites with many indexed pages — like a custom directory website with thousands of listing pages — see the largest aggregate gains from systematic Core Web Vitals work. Aggressive JavaScript minification and bundling helps at the margins but rarely moves CWV scores materially. And chasing a perfect 100 in PageSpeed Insights lab score is a distraction — field data on real users is what matters for rankings, and a site with a 72 lab score can outrank one with a 95 if its field data is better.

Realistic Expectations

Speed optimization on an existing site is constraint-based. There are limits to what’s achievable without a rebuild. A page builder theme with 80 plugins has a performance ceiling that no amount of caching will fully overcome. I’ll tell you where that ceiling is, and whether you’re better served by optimization or migration to a leaner setup.

For sites built through Salterra, performance is part of the build spec from day one rather than a retrofit. It’s easier to build fast than to fix slow.

Connection to Ongoing Maintenance

Speed regressions happen. A plugin update adds overhead; a new feature embeds a third-party script; image uploads accumulate without optimization. Performance monitoring as part of ongoing maintenance catches these before they compound. Automating manual processes around script governance — scheduled audits that flag new third-party additions — keeps this category of regression from accumulating silently. A one-time optimization effort without monitoring tends to drift back.

If you want to understand the full picture of what’s slowing your site down and what fixing it would actually involve, the software development page covers how I approach technical audits and what a realistic engagement looks like.