Site Speed Optimization: The Three Moves of Images, Caching, and CDN

On mobile 4G, the homepage keeps spinning for four seconds before loading — the user has already gone back to the search results and clicked the second result. Site speed optimization is the foundation of technical SEO; don’t put it on your “when I have time” list. Loading two seconds slower pushes bounce rate up noticeably and slowly drags your rankings down too.

Play the three moves in order: first convert images to WebP, then add a year of browser caching to static assets, and finally put a CDN in front — most sites can cut their load time by more than half. Don’t scramble the order; putting a CDN on before compressing images just delivers big files faster. Retest with PageSpeed Insights after each step, and you’ll know where each dollar of effort actually went.

1. Compress image size: Batch-convert images to WebP while keeping original backups, add width/height, loading=”lazy”, and srcset, targeting each image under 100KB.
2. Configure static-asset caching: Set a year of Cache-Control on static files with hash fingerprints, run page caching and Redis object caching together, and push TTFB down to the tens of milliseconds.
3. Put a CDN in front: Enable Brotli compression, force HTTPS on origin fetches, exclude utm tracking parameters from the cache key, and average static-asset latency drops from ~200ms to tens of milliseconds.
4. Retest after each step: Re-run PageSpeed Insights after each move, logging LCP, CLS, and INP, to confirm which step the improvement came from.
5. Six-point pre-launch check: Confirm main images are WebP with width/height attributes, cache expiry is at least a year, curl spot-checks status codes and cache headers, and mobile 4G first screen loads within 3 seconds.

Move one: cut image size to a third

A 400KB PNG converted to WebP often drops to around 80KB with no visible difference; AVIF can shrink another 20%, at the cost of slightly worse support on older browsers. Plugins like Imagify or ShortPixel on WordPress can batch-convert while keeping original backups, so you can roll back anytime if something breaks.

Format is only half of it — the tag markup is the other half. Add width and height attributes to your img tags together with loading=”lazy” to prevent layout shift (CLS) when images load and push content below. Then use srcset to offer multiple sizes, so mobile only downloads the version matching the screen width and desktop doesn’t waste bandwidth.

• Run images through a compressor before uploading, targeting under 100KB each
• Use SVG or pure CSS for decorative graphics to save a network request
• Preload above-the-fold key images and defer the rest until they enter the viewport
• Use the picture tag as a fallback so browsers without WebP automatically fall back to JPEG
• Keep uploaded originals under 2000px wide; crop locally anything larger

Move two: browser caching plus object caching together

In Nginx, set Cache-Control: public, max-age=31536000, immutable on static files so the browser stops re-downloading CSS, JS, and fonts for a full year. The prerequisite is that filenames carry hash fingerprints — when you release a change, the filename changes and the cache invalidates automatically; otherwise users keep seeing the old styles forever.

Hand page-level caching to WP Rocket or W3 Total Cache, which stores the dynamically generated HTML as static files served straight to visitors. Wire in Redis or Memcached for object caching to hit repeated database queries from memory — TTFB dropping from a few hundred milliseconds to under a hundred is a common result, and the admin backend feels smoother too.

Don’t mix up the three caching types

• Browser cache: saves download volume for returning users; does nothing for first-time visits
• Page cache: saves PHP rendering time, directly compressing TTFB
• Object cache: saves database queries; the more complex the site, the bigger the payoff

Keep a manual purge entry for all three caching types. Forget to clear the cache after publishing a post, changing a price, or swapping navigation, and users see a page half an hour old — these are among the most time-consuming problems to track down.

Move three: use a CDN to push content next to users

Mainstream CDNs all support edge caching, bringing average static-asset latency from the ~200ms range down to tens of milliseconds. When you integrate one, remember to turn on Brotli compression — it makes text resources 15%–20% smaller than Gzip, and that gain costs almost nothing.

Two pitfalls to hit: origin fetches must go over HTTPS, or you’ll trigger mixed-content warnings; and the cache key must ignore tracking parameters like utm, or the same page gets stored as thousands of copies, tanking your hit rate and actually increasing origin pressure. Validate mobile performance separately — the judgment criteria can follow the mobile-first indexing checklist.

Compare data before and after optimization

Above is a typical enterprise site’s measured before-and-after range: after swapping image formats, size drops to a third; with caching and CDN added, LCP returns from the failing 4.1 seconds into the good range. To calibrate the thresholds and collection definitions of these metrics, cross-check with the Core Web Vitals practical guide — don’t fool yourself with lab data; for ranking reference, look at the real-user data (CrUX) set.

Six-point pre-launch check

• Run PageSpeed Insights and WebPageTest, recording LCP, CLS, and INP separately
• Confirm main images are WebP with width/height attributes and lazy loading
• Static-asset Cache-Control expiry of at least a year, with fingerprinted filenames
• CDN has Brotli enabled, covering both JS and CSS
• Spot-check a few URLs with curl -I to confirm correct status codes and cache headers
• Simulate mobile 4G and keep first-screen completion under 3 seconds

Turn these six into a fixed checklist and run it before every redesign. To fold speed into a fuller launch flow, combine it with the technical SEO audit checklist so the speed work isn’t canceled out by other technical issues.

When it comes to execution, the rhythm is smooth: first use PageSpeed Insights to measure the current LCP of the homepage and your most important landing page, noting the baseline; batch-convert media-library images to WebP, prioritizing above-the-fold hero images; configure the year-long static-asset cache and confirm filenames carry hash fingerprints; integrate a CDN with Brotli enabled and tracking parameters excluded from the cache key; then retest after each step and store the three metric sets in one comparison table. After these three moves, most sites cut load time by more than half, and rankings and bounce rate start giving you positive feedback in return.

FAQ

Which step comes first in site speed optimization?

Compress images first — converting to WebP usually cuts size to a third, the biggest win. Don’t scramble the order: a CDN on un-compressed images just delivers big files faster. Retest with PageSpeed after each step.

Does converting images to WebP hurt quality?

Visually there’s almost no difference — a 400KB PNG to WebP often lands at 80KB. Use Imagify or ShortPixel for batch conversion with original backups, and fall back via the picture tag for old browsers.

How long should cache expiry be?

Set Cache-Control: public, max-age=31536000, immutable on static assets so they’re not re-downloaded for a year — provided filenames carry hash fingerprints so they invalidate automatically when the filenames change on release.

What are the must-hit pitfalls when integrating a CDN?

Origin fetches must use HTTPS to avoid mixed-content warnings; exclude utm tracking parameters from the cache key or the same page gets stored as thousands of copies and the hit rate collapses; and enable Brotli — text is 15%–20% smaller than Gzip.

Should I judge speed by lab data or real-user data?

Trust real-user data (CrUX) — a lab score of 90 with a failing field score is common. The thresholds are LCP under 2.5s, CLS under 0.1, and INP under 200ms.