Seven hundred milliseconds is a strange target. It is fast enough that a visitor never consciously waits, but slow enough that you cannot fake it with a green Lighthouse score and a prayer. I picked it deliberately when I rebuilt one of my WordPress sites last winter, because "700ms fully interactive on a mid-range Android phone over real 4G" is the kind of number that forces you to stop optimizing the lab and start optimizing the field. Here is the actual path I walked to get there, what mattered, and what turned out to be theater.

First I defined what 700ms even meant

The number on its own is meaningless until you say which 700ms. A page has at least four clocks running, and conflating them is how people end up "optimizing" the wrong thing for a week.

TTFB (time to first byte): how long the server takes to start answering. On WordPress this is almost entirely PHP execution plus database round-trips.
FCP (first contentful paint): when the browser paints anything at all.
LCP (largest contentful paint): when the main hero element — usually an image or a headline block — finishes rendering. This is the Core Web Vital Google grades, and the "good" threshold is under 2.5 seconds at the 75th percentile.
INP (interaction to next paint): how fast the page responds to taps once it is up. Good is under 200ms.

My 700ms goal was specifically LCP on a throttled Moto G-class device. If I hit that, FCP and TTFB would have to be excellent as a precondition, and INP would mostly take care of itself once I cut the JavaScript. So I instrumented before I touched anything: a WebPageTest run from the nearest cloud node to my real audience, the Chrome User Experience Report (CrUX) data in Search Console for field numbers, and the local web-vitals library logging to my analytics so I could see real users, not just synthetic runs.

The server was the first 400ms, and it was the easiest win

My starting TTFB on cellular was hovering near 900ms. That is a server problem, full stop, and no front-end trick fixes it. Two changes collapsed it.

The first was getting PHP off the critical path for repeat views with a real page cache. I was on a host that did not cache at the server layer, so every request spun up the full WordPress bootstrap. Moving the page cache up the stack — either to the host's own NGINX FastCGI cache or to a CDN edge cache — meant most visitors got a static HTML document served in tens of milliseconds, never touching PHP or MySQL at all. On managed WordPress hosts like Kinsta, WP Engine, or Cloudways with Varnish, this is a toggle. On a generic VPS it is a few lines of NGINX config plus a cache-purge plugin so the edge clears when I publish.

The second was object caching with Redis for the requests that genuinely can't be cached — logged-in views, the admin, anything dynamic. WordPress hammers the database with repeated identical queries inside a single request; persistent object cache keeps those results in memory between requests. On a query-heavy theme this alone took uncached TTFB from roughly 600ms to under 250ms.

I also moved to PHP 8.3 with OPcache properly sized. People forget that an outdated PHP version is a silent 20–30% tax on every dynamic request. If your host still defaults you to 7.4, that is free performance sitting on the table.

The hero image was lying about its size

With the server fast, LCP was now gated by whatever the largest paint element was — in my case a full-width hero photo. The original asset was a 2400px-wide JPEG weighing about 480KB. The browser was downloading every one of those bytes before it could finish the paint that defines LCP.

Three fixes, stacked:

I served AVIF with a WebP fallback. AVIF routinely lands 40–50% smaller than JPEG at the same perceptual quality. My 480KB JPEG became a 110KB AVIF.
I added real responsive srcset so a phone never downloads a desktop-width image. A 390px-wide screen has no business pulling a 2400px file.
I preloaded the LCP image with <link rel="preload" fetchpriority="high"> and explicitly removed lazy-loading from that one image. The single most common LCP mistake I see is people lazy-loading their hero — the browser dutifully waits to even start the download, sabotaging the exact metric they care about.

I also set explicit width and height attributes so the layout never shifted, which kept Cumulative Layout Shift near zero as a bonus.

JavaScript was the part nobody wanted to talk about

This is where most "speed plugin" advice quietly fails. A caching plugin makes the document arrive fast, but if 300KB of render-blocking and main-thread-clogging JavaScript loads on top of it, the page still feels slow and INP still suffers. So I audited every script the page actually shipped using the Chrome DevTools Coverage tab, which shows you the percentage of each file that never executes on the page.

The results were embarrassing in the way they usually are. A social-sharing library was loading its own copy of a framework. An animation library was present on pages with no animations. A font-loader script existed solely to do what a single CSS line could do. I removed what I could, and for the rest I used per-page conditional dequeuing — WordPress lets you wp_dequeue_script on pages where a script isn't needed, and plugins like Perfmatters or Asset CleanUp give you a UI for it if you'd rather not write the hooks yourself.

For the scripts that had to stay, I deferred them. Anything non-critical got defer so it stopped blocking the parser. Third-party embeds — the genuinely heavy stuff like chat widgets and analytics — got loaded on interaction or after the page was idle, not during the initial render. A live-chat bubble does not need to exist in the first 700ms; nobody is going to message you before the page has even painted.

Fonts: the quiet 300ms that hides in plain sight

Web fonts block text rendering by default, and a font hosted on a third-party domain adds a fresh DNS lookup and TLS handshake right when the browser is busiest. I self-hosted my fonts so they came from the same origin as everything else, subset them to only the characters the site uses, added font-display: swap so text shows immediately in a fallback, and preloaded the one weight used above the fold. Self-hosting also sidesteps the privacy and consent headaches of loading fonts from an external provider in regions with strict data rules.

What actually moved the needle, ranked

If I had to do it again on a fresh site and could only keep four moves, in order of impact:

Edge/page caching so most visitors never run PHP — the biggest, most reliable single win.
A correctly handled LCP image — AVIF, responsive, preloaded, never lazy-loaded.
Ruthless JavaScript removal, because deleting a script beats deferring one, and deferring beats minifying.
Self-hosted, subset, swap-displayed fonts.

The honest caveats

Synthetic scores are not field reality. A Lighthouse run on a fast laptop can read 98 while real users on older phones in weaker coverage experience something far worse — always trust your CrUX field data over a lab number. Caching also hides slow code rather than fixing it; the day someone logs in or hits an uncacheable endpoint, the real TTFB resurfaces, so the object-cache and PHP-version work still matters. And page builders make all of this harder — a heavily nested builder layout ships markup and CSS that a lean block theme simply does not, which is a real architectural cost worth weighing before you start.

Seven hundred milliseconds was not the product of one heroic plugin. It was the server getting out of the way, one image behaving honestly, a pile of unnecessary JavaScript getting deleted, and fonts that stopped holding text hostage. None of it is exotic. It is just done in the right order, measured against the field instead of the lab, and verified on the device a real visitor is actually holding.

How I Got My WordPress Site to Load in 700ms