Site Speed Optimization: What Actually Moves the Needle

A client came to us panicking because their PageSpeed Insights score dropped from 92 to 71. Their site loaded in 1.8 seconds on both mobile and desktop. No real user had noticed any change. The score drop was caused by a third-party analytics script that PageSpeed started penalizing differently. Their actual performance was fine.

Chasing a perfect 100 score is a trap. What matters is real-world load time as experienced by your visitors. That said, genuinely slow sites do lose both visitors and rankings. Here's what actually makes a difference.

The Three Things That Slow Down Most Sites

Images

On average, images account for about 50% of a page's total weight. An unoptimized hero image can easily be 2-3MB. That single image takes longer to download than the rest of the page combined.

Convert to WebP or AVIF. WebP typically reduces file size by 25-35% compared to optimized JPEG with minimal quality loss. AVIF goes even further but has slightly less browser support. Most CDNs now handle format conversion automatically.

Serve responsive images. A 2400px-wide image displayed in a 600px container is wasting 75% of the data transferred. Use srcset to serve different sizes based on the viewer's screen. WordPress handles this automatically with its media library, but check that it's actually working.

Lazy load below-fold images. Images that aren't visible when the page first loads don't need to load immediately. Add loading="lazy" to img tags (native browser support, no JavaScript needed). But never lazy-load your hero image or LCP element — that will hurt your Core Web Vitals.

JavaScript

Every JavaScript file your page loads needs to be downloaded, parsed, compiled, and executed. Heavy JS is the primary cause of slow Interaction to Next Paint (INP) scores.

Audit your third-party scripts. Analytics, chat widgets, social media embeds, advertising code, heatmap tools — each one adds weight and execution time. We've seen sites loading 15-20 third-party scripts. Remove anything you're not actively using. For the rest, defer or async load them.

Defer non-critical JavaScript. Add the defer attribute to script tags that don't need to run before the page renders. This lets the browser download them in parallel while continuing to parse HTML. The async attribute works similarly but executes scripts immediately once downloaded, which can cause layout shifts.

Code split if you're using a JavaScript framework. React, Next.js, Vue — all support code splitting so users only download the JavaScript needed for the current page, not the entire application. A single-page app that loads 2MB of JS upfront is always going to feel slow.

Server Response Time

Your server response time (Time to First Byte, or TTFB) sets the floor for everything else. If your server takes 2 seconds to respond, your page can't possibly load in under 2 seconds. Aim for TTFB under 600ms, ideally under 200ms.

Use a CDN. Content delivery networks serve your assets from servers physically closer to the user. A visitor in Tokyo loading a page from a US server adds 200-300ms of latency just from the physical distance. CDNs like Cloudflare (free tier is genuinely useful) eliminate this.

Enable server-side caching. For CMS-powered sites, page caching means the server delivers a pre-built HTML file instead of running PHP and database queries on every request. On WordPress, a caching plugin like WP Super Cache or W3 Total Cache typically cuts TTFB by 60-80%.

Upgrade your hosting if needed. Shared hosting where 200 sites share one server will always be slower than a VPS or dedicated server. If you've optimized everything else and TTFB is still over 800ms, your hosting is the bottleneck. Quality hosting with NVMe SSD storage makes a noticeable difference — we've seen TTFB improve from 900ms to 180ms just by moving to better hosting.

Quick Wins That Take Under an Hour

Enable text compression. Gzip or Brotli compression reduces HTML, CSS, and JavaScript file sizes by 60-80% during transfer. Most web servers support this with a simple configuration change. Check if it's enabled by looking at the "Enable text compression" audit in PageSpeed Insights.

Set browser cache headers. Static assets (images, CSS, JS) should have cache-control headers that tell the browser to store them locally. A returning visitor shouldn't have to re-download your logo, stylesheets, and unchanged scripts. Set cache duration to at least 30 days for static assets.

Preconnect to critical third-party domains. If your page loads fonts from Google Fonts, add rel="preconnect" for fonts.googleapis.com and fonts.gstatic.com. This starts the DNS lookup and connection early, saving 100-300ms per domain.

Minimize CSS. Remove unused CSS. Tools like PurgeCSS can strip unused styles from your stylesheet. We've seen CSS files shrink from 300KB to 40KB after purging unused rules, especially on sites using large frameworks like Bootstrap or Tailwind.

Measuring What Matters

Use these tools in this order:

Google Search Console Core Web Vitals report — shows real-user data. This is what Google uses for ranking.

PageSpeed Insights — shows both lab data and field data (from Chrome UX Report). Useful for specific page diagnostics.

WebPageTest.org — waterfall charts show exactly what loads when. Best for diagnosing specific bottlenecks.

Don't optimize for a score. Optimize for the actual metrics: LCP under 2.5s, INP under 200ms, CLS under 0.1. If those three numbers are green, your site is fast enough. A PageSpeed score of 75 with good Core Web Vitals is better than chasing a score of 100 by removing features your site actually needs.

Run speed tests from multiple locations, not just your local connection. Your site might load in 1.5 seconds from your office on fiber internet but take 5 seconds for a visitor in a different country on a 3G connection. Geographic performance matters, especially for sites with international audiences.

Speed optimization is iterative. Fix the biggest bottleneck, measure the impact, then move to the next one. Trying to fix everything at once usually leads to breaking things. We typically see the biggest improvements from images and JavaScript — start there.