How to Speed Up WordPress (and Cut TTFB Below 200ms)

Start by Measuring TTFB, Not Just PageSpeed Scores

Before changing anything, get a baseline. Time to First Byte (TTFB) is how long the server takes to start sending the page after a request. It's the foundation of every other metric, including Largest Contentful Paint (LCP). If TTFB is 800ms, no amount of front-end tuning will make the page feel fast.

Run a few tests from a location near your audience. The quickest check is curl, which isolates server time from browser rendering. Test the home page and one heavy page (a product page or a long post), uncached and cached, three or four times each.

• curl -w "TTFB: %{time_starttransfer}s\n" -o /dev/null -s https://yoursite.com
• Google's targets: aim for LCP under 2.5s; a healthy TTFB is roughly under 200ms, and Google flags 'good' at ~800ms.
• Use WebPageTest or GTmetrix for a waterfall; use the Query Monitor plugin to see slow database queries and which plugins add load.

Fix the Server Layer First: PHP, Caching, and Object Cache

The single biggest WordPress speed win is page caching. A cached HTML page skips PHP and the database entirely, dropping TTFB from 500-1500ms to 50-150ms. Use a full-page cache at the server level (NGINX FastCGI cache or Redis page cache) or a plugin like WP Super Cache, W3 Total Cache, or LiteSpeed Cache if your host supports it.

For uncached requests (logged-in users, carts, dynamic pages), two things matter most. First, run PHP 8.1 or newer with OPcache enabled. Moving from PHP 7.4 to 8.x routinely cuts execution time 20-40%. Second, add a persistent object cache with Redis to store the results of repeated database queries in memory. On a query-heavy site, that alone can shave 100-300ms off uncached TTFB.

The server itself matters too. WordPress on shared, oversold hosting fights neighbors for CPU. NVMe-backed bare metal or a properly resourced cloud instance gives consistent, low TTFB because disk I/O for the database is no longer the bottleneck.

Tame Plugins and the Database

Plugins are the most common cause of slow uncached pages. Every active plugin can add queries, autoloaded options, and front-end scripts. Use Query Monitor to find the worst offenders, then deactivate anything you don't truly need. Page builders and 'all-in-one' suites are frequent culprits.

The database also bloats over time. Trim post revisions, clear expired transients, and delete spam and trashed comments. Check the wp_options table for autoloaded data: run a query for the largest autoload rows, since a few oversized entries can be loaded on every single request.

If you run WooCommerce, keep autoloaded options lean and make sure HPOS (High-Performance Order Storage) is enabled. Schedule cleanups monthly rather than letting cruft accumulate for years.

Optimize Images and Front-End Delivery

Once the server is fast, fix what the browser downloads. Images are usually the heaviest payload. Serve modern formats (WebP or AVIF), resize to the actual display dimensions, and enable native lazy loading so off-screen images don't block the initial render. A single 2MB hero image can cost more than your entire HTML document.

Reduce render-blocking resources: minify and combine CSS/JS where it helps, defer non-critical scripts, and remove unused CSS from heavy themes. Be conservative here, as aggressive JS deferral can break sliders, forms, and analytics, so test after each change.

Add a CDN to push static assets close to visitors and offload bandwidth from the origin. A CDN doesn't fix a slow server, but it removes geographic latency for images, CSS, and JS, which improves perceived load time worldwide.

A Realistic Order of Operations

Speed work pays off fastest when done in the right sequence. Chasing image optimization while the server takes a second to respond is wasted effort. Work from the server outward.

Here's the priority list that delivers the most measurable improvement per hour spent:

• 1. Enable full-page caching (biggest single win).
• 2. Upgrade to PHP 8.1+ with OPcache.
• 3. Add Redis object cache for uncached/dynamic pages.
• 4. Audit and remove heavy plugins; clean the database.
• 5. Optimize images (WebP/AVIF, correct sizing, lazy load).
• 6. Defer non-critical CSS/JS and add a CDN.
• 7. Re-measure TTFB and Core Web Vitals after each step.

When Hosting Is the Bottleneck

You can apply every tip above and still hit a wall if the underlying server is slow or oversold. If your uncached TTFB stays above 500-600ms after caching, PHP 8.x, and object cache are in place, the host itself is usually the limiting factor. Shared plans that pack hundreds of sites per server can't deliver consistent sub-200ms responses no matter how clean your WordPress install is.

This is where the hardware genuinely matters. NordicVentures runs WordPress on NVMe bare-metal and properly resourced cloud across Stockholm, Frankfurt, and Ashburn, so the database and PHP layer aren't starved for I/O or CPU. Server-level caching, PHP 8.x, OPcache, and Redis come configured, and migration is free with 24/7 human support if you get stuck.

If you've done the optimization work and want a server that actually keeps up, see our fast managed WordPress hosting at /managed-wordpress-hosting. Bring your current TTFB numbers and compare.