WordPress powers 43% of the web. It’s also frequently blamed for slow sites — but slow WordPress sites are almost always a configuration problem, not a WordPress problem. A properly optimized WordPress site can score 95+ on PageSpeed Insights and load in under 1 second. Here’s how.

Measure First, Optimize Second

Don’t guess what’s slow. Use these tools to get a baseline:

• PageSpeed Insights (pagespeed.web.dev) — lab data + real user data (CrUX)
• WebPageTest — detailed waterfall analysis, multiple test locations
• Chrome DevTools Performance tab — profile specific interactions
• Query Monitor plugin — identify slow database queries in your WordPress admin

Run tests from a cold cache (disable caching temporarily) to see your true baseline.

The Server Stack Matters Most

The single biggest performance lever is your hosting and server configuration. In order of impact:

1. PHP version — PHP 8.2+ is ~30% faster than PHP 7.4. Update immediately if you haven’t.
2. OPcache — caches compiled PHP bytecode in memory. Should be enabled on any production server.
3. Redis object cache — caches WordPress database query results in memory. Critical for sites with heavy wp_options usage.
4. Server hardware — more CPU cores and RAM directly improve response time under load.

Largest Contentful Paint (LCP): Make It Fast

LCP measures how quickly the largest visible element loads — usually a hero image or headline. Google’s Core Web Vitals threshold is under 2.5 seconds. To improve LCP:

• Preload your LCP image: <link rel="preload" as="image" href="hero.webp">
• Serve it from a CDN with a short TTFB
• Use WebP format with appropriate compression
• Never lazy-load the LCP image — it should load immediately

Cumulative Layout Shift (CLS): Stop Things From Jumping

CLS measures visual stability — elements that shift after initial render. Common causes in WordPress:

• Images without explicit width/height attributes
• Web fonts that swap after load (use font-display: optional or preload fonts)
• Ads and embeds that load asynchronously and push content down
• Cookie consent banners that appear after render

Interaction to Next Paint (INP): Responsive Clicks

INP replaced FID as a Core Web Vitals metric in 2024. It measures how quickly your page responds to user interactions — clicks, taps, keyboard input. Poor INP is almost always caused by excessive JavaScript on the main thread.

Audit with Chrome DevTools Performance Insights. Long tasks (>50ms) block the main thread. Break them up with scheduler.yield() or move work to Web Workers.

Critical CSS and Font Loading

Render-blocking CSS delays the First Contentful Paint. Inline your critical CSS (above-the-fold styles) and load the rest asynchronously:

<link rel="preload" href="styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">

For fonts, preload the specific weights you use and use font-display: swap to avoid invisible text during font load.

WordPress-Specific Optimizations

• Limit post revisions — add define('WP_POST_REVISIONS', 5); to wp-config.php
• Disable unused post types and taxonomies — reduces query complexity
• Autoloaded options audit — run SELECT * FROM wp_options WHERE autoload = 'yes' ORDER BY LENGTH(option_value) DESC LIMIT 20; — large autoloaded options hurt TTFB
• Heartbeat API — reduce frequency from 15s to 60s on the frontend to reduce AJAX overhead

Caching Stack for WordPress

A complete caching stack has four layers:

1. Bytecode cache — OPcache (server level)
2. Object cache — Redis or Memcached (database query results)
3. Page cache — full HTML of each page (WP Rocket, LiteSpeed, or Nginx)
4. CDN cache — static assets cached at edge (Cloudflare, Bunny.net)

Layers 1 and 2 are server configuration. Layers 3 and 4 are plugin + CDN configuration. All four together produce the fastest possible WordPress response time.

The 95+ PageSpeed Score Goal

Scoring 95+ on PageSpeed Insights is achievable on a well-configured WordPress site. The roadmap: fix your server stack, implement all four cache layers, optimize images, eliminate render-blocking resources, and audit your JavaScript. Each step produces measurable improvement.

Running a WooCommerce store? Also check out our guide on optimizing your shipping workflow — a fast store and a fast fulfillment process go hand in hand. Questions? Contact our team.

Full Site Editing (FSE) arrived in WordPress 5.9 and has been maturing rapidly ever since. In 2025, with WordPress 6.9, it’s no longer experimental technology — it’s the direction WordPress is heading, and WooCommerce has been building to match. Here’s what store owners need to understand.

What Is Full Site Editing?

Full Site Editing means using the block editor not just for post and page content, but for every part of your site — headers, footers, sidebars, archive templates, single product pages, 404 pages, everything. Instead of editing theme files in PHP, you edit templates visually in the Site Editor (Appearance → Editor).

This only works with block themes — themes built specifically for FSE. Classic themes (most older themes, including many WooCommerce themes) don’t support the Site Editor.

Block Themes vs Classic Themes

The key differences:

• Classic themes use PHP templates, CSS files, and the Customizer. Familiar, widely supported, but increasingly limited.
• Block themes use HTML block templates, theme.json for global styles, and the Site Editor. More flexible, but requires learning the new paradigm.

Both continue to be supported in WordPress. But new WordPress features are being built for block themes first — including many of the WordPress 6.9 improvements like Zoom Out mode and Section Styles.

WooCommerce and Block Themes

WooCommerce now provides block templates for every store page — shop archive, single product, cart, checkout, account pages. These templates are editable in the Site Editor on block themes, giving you visual control over your store layout without touching PHP.

The WooCommerce block checkout (available on block themes) also loads faster than the classic shortcode checkout and supports more payment methods natively.

Should You Switch to a Block Theme?

Honest answer: it depends on where your store is in its lifecycle.

Switch if:

• You’re building a new store from scratch
• You want visual control over product page and checkout layout
• Your current theme is outdated and you need a redesign anyway
• You have a developer who’s comfortable with the block ecosystem

Stay on a classic theme if:

• Your store is running well and a theme migration would be disruptive
• You rely on heavily customized PHP templates
• Your key plugins don’t have block theme compatibility yet

Recommended Block Themes for WooCommerce

• Storefront (block version) — WooCommerce’s official theme, optimized for commerce
• Twenty Twenty-Five — the current default WordPress theme, excellent starting point
• Kadence — popular freemium option with strong WooCommerce integration
• GeneratePress — lightweight and performance-focused

Plugin Compatibility

Before switching to a block theme, verify your key plugins are compatible. Shipping plugins, payment gateways, and page builders are the most common friction points. Plugins built on modern WordPress APIs — like the TheForge EasyPost Shipping plugin — are fully compatible with block themes and the WooCommerce checkout block, so your shipping configuration carries over without changes.

Testing Before You Switch

Use WordPress Playground to test a block theme with your plugins before switching on your live store. You can verify the entire checkout flow — including shipping rate display — without risking live orders. Questions? Reach out to our team.