Under 700 milliseconds is a specific, demanding target, and the reason most "speed up WordPress" advice never gets you there is that it treats the number as a vague aspiration instead of a budget you have to spend deliberately. Seven hundred milliseconds from request to a usefully painted page is not achieved by stacking thirty tweaks. It is achieved by understanding where every one of those milliseconds is allowed to go, then refusing to let any single stage overspend. This article walks through that budget the way you would actually have to build it, on a real content site, and is honest about the cases where 700ms is simply not reachable.

What "under 700ms" actually measures

First, define the number, because people quietly mean different things. The most useful framing splits the journey into two halves: Time to First Byte (TTFB) — how long the server takes to start sending HTML — and render time — how long the browser then needs to lay out, fetch critical resources, and paint. Google's own guidance treats a TTFB under 800ms as the threshold below which server response is no longer your bottleneck, and Largest Contentful Paint (LCP) under 2.5 seconds as the "good" Core Web Vitals bar.

So when a site claims "loads in 700ms," the meaningful version of that claim is: TTFB landed in the low hundreds of milliseconds, and the largest visible element painted shortly after. If your TTFB alone is 1.8 seconds, no amount of image compression saves you — you have already blown the entire budget before the browser receives a single byte. That ordering matters, and it dictates the sequence of everything below.

The case: a 240-post content blog

Picture a typical mid-size WordPress blog — roughly 240 published posts, a popular multipurpose theme, decent managed hosting, and a homepage heavy with a hero image and a "related posts" block under each article. A site like this commonly starts around 1.5–1.9s TTFB with an LCP near 3.5s on mobile, scoring in the low 60s on PageSpeed Insights. Nothing is catastrophically broken. It is death by a few specific, identifiable culprits. Here is where the budget leaks, in order of how much they cost.

Leak 1: the database, not the front end

The single most expensive thing on a slow-but-not-broken WordPress site is usually an uncached, unbounded query running on every page load. The classic offender is a related-posts plugin that, for each article view, queries every post for tag or category overlap, sorts the matches in PHP, and returns five. On 240 posts with no purpose-built index, that one feature can add several hundred milliseconds of pure server time to every single request.

The fix is not "optimize the query" — it is to stop running it at request time. Plugins that precompute relationships into a custom table (or cache the result for hours) turn a per-request join into a single indexed lookup. If you cannot replace the plugin, wrapping the result in a WordPress transient with a multi-hour expiry achieves the same thing. This category of fix typically reclaims the largest single slice of TTFB, because it removes work entirely rather than doing it faster.

Leak 2: no full-page cache at the server

The biggest structural truth about hitting 700ms is this: you cannot PHP-and-MySQL your way to a low-hundreds TTFB on every request. WordPress assembling a page from the database takes real time. The only way around it is to not assemble the page at all — serve a pre-rendered HTML copy from a cache that lives as close to the network edge as possible.

That means a server-level full-page cache: Nginx FastCGI cache, Varnish, LiteSpeed Cache on a LiteSpeed server, or your host's built-in layer (SiteGround's SuperCacher, Kinsta and WP Engine's edge caching, Cloudways with Varnish + Redis). A page-level cache plugin like WP Rocket or W3 Total Cache helps, but server-level caching is what reliably drops a cached page's TTFB into the 100–300ms range. The catch worth stating plainly: caching helps anonymous traffic. Logged-in users, carts, and personalized pages bypass the cache and pay full price — more on that limitation below.

Leak 3: the hero image is the LCP

Once TTFB is under control, the render half of the budget is almost always dominated by one element: the largest image above the fold, which is usually your LCP element. A 1.4MB hero JPEG at 1920px wide is a budget killer on mobile, where the connection is slower and the viewport smaller.

The remedy is unglamorous and reliable. Convert to WebP or AVIF (often a 60–80% size reduction at equivalent quality), serve responsive srcset sizes so phones never download desktop-resolution files, set explicit width and height to prevent layout shift, and add fetchpriority="high" to the LCP image so the browser fetches it before anything else. Critically, do not lazy-load the hero — lazy loading the LCP element delays the very paint you are trying to speed up. Getting a hero from ~1.4MB down to a couple hundred KB routinely pulls mobile LCP from the mid-3s range to under 2s.

Leak 4: render-blocking third-party scripts

Chat widgets, analytics, consent banners, and font loaders parked in the document <head> block rendering while they fetch and execute. Deferring non-critical JavaScript so it loads after first paint is what protects your Interaction to Next Paint (INP) — the responsiveness metric that replaced First Input Delay in March 2024, with a "good" threshold under 200ms. Load the chat widget on interaction, async your analytics, and self-host fonts with font-display: swap. None of this moves TTFB, but it keeps the render half of the budget from being squandered on someone else's code.

Leak 5: object caching and dead plugins

For the cache-miss pages that do hit PHP — and they always exist — a persistent object cache via Redis or Memcached keeps WordPress's repeated database queries and transients in memory instead of round-tripping to MySQL. On a busy cache-miss page this is often the difference between a sub-600ms and a 1-second-plus response. Finally, audit and remove plugins you no longer use: each one that enqueues CSS and JS on every page adds bytes and HTTP work to a budget you are trying to shrink. A handful of dead plugins can easily cost 80–100KB of render-blocking assets sitewide.

Putting the budget together

Sequenced correctly, the result on a site like this is a TTFB that lands comfortably under 700ms (often well under it on cached pages), an LCP near 1.5s, CLS in the good range below 0.1, and a PageSpeed mobile score in the high 80s. The point is not that you must do all six things. It is that the first two — killing the unbounded query and turning on server-level caching — typically account for the majority of the gain, because they attack TTFB, which is the half of the budget that gates everything else.

When 700ms is genuinely impossible

Be honest with yourself before you spend a weekend on this. Three situations cap your floor no matter how clean your code is:

Underpowered shared hosting. If the server itself responds slowly, optimization cannot overcome it. If you have done the work above and TTFB still sits above one second on cached pages, the host is the bottleneck, and moving to a faster stack is the highest-leverage change you can make — not another plugin.
Inherently uncacheable pages. Membership sites, WooCommerce carts, and any logged-in experience bypass the full-page cache by design. Those requests live or die on raw PHP and database speed, where 700ms is far harder and object caching plus a fast host become non-negotiable.
Geographic distance with no CDN. A visitor an ocean away from your origin pays network latency you can't optimize away in code. A CDN that serves cached HTML and static assets from an edge near the user is the only real fix.

The discipline that ties all of this together is measurement. Change one thing, measure TTFB and LCP, record the delta, then move on. Bundled changes hide which lever actually worked, and "the site feels faster" is not a number you can defend. Build the budget one line item at a time, and 700ms stops being luck.

How One Site Got Its Page-Load Time Under 700ms