WordPress Site Speed Optimization: A Developer’s Checklist

Short answer: Optimise a WordPress site in this order: measure with field data first, fix hosting and server response time, then caching, then images, then scripts, then the database. Working in that sequence matters, because most of the time spent on minification and script deferral is wasted if the server takes 800ms to return HTML. The largest wins are almost always hosting, caching and images.

Measure Before You Change Anything

Optimisation without measurement is guesswork, and the tool you use determines whether you are solving a real problem or an imaginary one.

Two rules worth holding to. First, field data beats lab data: a lab score reflects one simulated run on a throttled connection, while field data reflects your actual visitors. Second, test the same page repeatedly, since a single run tells you almost nothing on a shared host.

The metrics that matter

• TTFB (Time to First Byte) — server response. Under 200ms is good, over 600ms means the problem is hosting or backend, not front-end
• LCP (Largest Contentful Paint) — when the main content appears. Target under 2.5s
• CLS (Cumulative Layout Shift) — visual stability. Target under 0.1
• INP (Interaction to Next Paint) — responsiveness to input. Target under 200ms

Step 1: Hosting and Server

This is where the largest and least glamorous wins are. No amount of front-end work compensates for a slow server, and cheap shared hosting is the most common root cause of a site that resists every optimisation attempt.

• Confirm the PHP version is current. Older versions are meaningfully slower and no longer receive security fixes
• Check TTFB against the 200ms benchmark; consistently above 600ms points at the host
• Ensure object caching is available and enabled, via Redis or Memcached, particularly for dynamic sites
• Verify HTTP/2 or HTTP/3 is in use
• Confirm the server is geographically sensible for your audience
• Check whether you are on genuinely shared hosting with noisy neighbours

Migrating from budget shared hosting to competent managed hosting often produces a bigger improvement than every other item on this list combined.

Step 2: Caching

Caching converts dynamic PHP execution into static file delivery. It is the highest-leverage change after hosting.

• Page caching for anonymous visitors, served before PHP executes where possible
• Object caching via Redis or Memcached to avoid repeated database queries
• Browser caching with sensible expiry headers on static assets
• CDN for static assets, and edge caching for HTML if your setup supports it
• OPcache enabled at server level for compiled PHP

Exclude cart, checkout and account pages from page caching. Caching them produces stale totals, session bleed between customers, and on a store, genuinely serious bugs. This is the single most common caching mistake on WooCommerce sites, and we cover its checkout consequences in WooCommerce checkout issues that kill conversions.

Step 3: Images

Images are usually the largest payload on a WordPress page and the most straightforward thing to fix.

• Serve WebP or AVIF with fallbacks for older browsers
• Size images to their display dimensions rather than uploading originals from a camera or stock library
• Use responsive srcset so mobile devices are not downloading desktop-sized files
• Lazy-load below-the-fold images, but never the LCP image, which should load eagerly
• Set explicit width and height attributes to prevent layout shift
• Compress at 75–85% quality, which is visually indistinguishable from full quality at a fraction of the size
• Audit the media library for unused originals and orphaned thumbnail sizes

Step 4: Scripts, Styles and Fonts

This is where most optimisation effort goes and where returns are smaller than expected. Do it after the previous three steps.

Reduce what loads

• Dequeue plugin assets on pages that do not use them, since many plugins load everywhere by default
• Remove page builder assets on pages not built with the builder
• Disable WordPress emoji scripts and unused block library CSS
• Audit third-party scripts ruthlessly — each tracking pixel, chat widget and A/B testing tool is a third-party dependency on your load time

Change how it loads

• Defer non-critical JavaScript, and inline critical CSS for above-the-fold content
• Self-host fonts rather than calling Google Fonts, which removes a DNS lookup and a connection
• Use font-display: swap and preload the fonts used above the fold
• Subset fonts to the character sets you actually need
• Preconnect to domains you genuinely depend on, but sparingly

Step 5: Database and Backend

• Clean post revisions, transients, spam comments and orphaned metadata
• Check autoloaded options, which should generally stay under about 1MB; a bloated wp_options table slows every single request
• Identify slow queries with Query Monitor, particularly on category and archive pages
• Check for plugins making external HTTP requests during page load, which is a common hidden cause of high TTFB
• Review scheduled tasks, since a heavy cron job firing on a visitor request delays that visitor
• Ensure custom queries are indexed appropriately, especially on large product catalogues

Step 6: Verify and Keep Verifying

1. Re-measure with the same tool, on the same page, several times
2. Test as a logged-out visitor, since logged-in requests bypass page caching and look artificially slow
3. Check on a real mobile device over mobile data, not office wifi
4. Confirm nothing broke — aggressive script deferral frequently breaks sliders, forms and checkout
5. Watch field data over the following weeks, which is where the real result appears

Speed regresses quietly. Plugin updates reintroduce assets, new marketing scripts get added, and the media library fills with oversized uploads. Re-check quarterly rather than treating optimisation as a one-off project.

The Checklist

Frequently Asked Questions

What is the fastest way to speed up a WordPress site?

Fix hosting and caching first. A slow server response cannot be compensated for with front-end optimisation, so if your time to first byte is consistently above 600 milliseconds, moving to better hosting will usually produce a larger improvement than every other change combined. Page caching and image optimisation come next.

Does PageSpeed Insights score affect Google rankings?

The field data does, through Core Web Vitals, but the lab score shown for a single simulated run does not directly. Chasing a perfect lab score is often wasted effort. Focus on the field measurements from real visitors, particularly Largest Contentful Paint under 2.5 seconds and Interaction to Next Paint under 200 milliseconds.

Should I exclude WooCommerce pages from caching?

Yes. Cart, checkout and account pages must be excluded from page caching. Caching them causes stale cart totals and can leak session data between customers, which is among the most serious and most common caching mistakes on WooCommerce stores.

Why is my WordPress site still slow after installing a caching plugin?

Usually because the bottleneck is elsewhere. Caching plugins help anonymous page loads but cannot fix a slow server, oversized images, a bloated plugin stack, or a database with excessive autoloaded options. Measure time to first byte first: if it is high, the problem is the server or backend rather than the front end.

How often should I check WordPress site speed?

Quarterly for most sites, and monthly for stores. Performance regresses quietly as plugin updates reintroduce assets, marketing scripts accumulate, and oversized images are uploaded. Treating optimisation as a one-off project means the gains erode within months.

Need someone to work through this properly rather than guessing at it? Our developers handle WordPress performance work daily. Hire a WordPress developer or get a fixed quote within 24 hours, with a 30-day bug-fix warranty.