Perf runbook · Intermediate · an afternoon
How to speed up WordPress — Measure, Change One Thing, Measure Again
You want the site to be faster for the people using it, not merely to score better in a tool that grades a single load from a data centre.
The short answer
Work the loop: record four numbers, make exactly one change, re-measure the same URL the same way, keep the change only if a number moved. TTFB from curl, largest contentful paint and interaction to next paint from field data, and query count from Query Monitor.
The order that pays is server cache first, then the image pipeline, then removing what you are not using, then the engine underneath. Doing it in that order means the biggest win comes first and every later change is measured against a site that is already caching properly.
By the HostingFast team · Reviewed 24 August 2026
Intermediate
Skill floor
5
Stages start to end
Free
Support, every tier
Proven
Run on the live stack
You need a terminal, DevTools, Query Monitor and somewhere safe to test. Managed WordPress plans allow up to 10 staging copies, so nothing here has to happen on production.
An afternoon for the work and a few weeks before the field data confirms it, because real-user metrics report on a rolling window rather than instantly.
The four numbers, and where each one comes from
Time to first byte comes from curl -o /dev/null -s -w '%{time_starttransfer}\n' against a real URL, five runs, median. Largest contentful paint and interaction to next paint come from field data — Search Console's Core Web Vitals report, or the web-vitals library reporting from your own visitors. Cumulative layout shift comes from the same place. Query count comes from Query Monitor on the page you actually care about.
The good bands are published: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1, TTFB under 800 milliseconds. Note which of the four you are failing before you change anything, because the fix for a slow TTFB and the fix for a bad LCP have almost nothing in common.
Cache at the server before you cache in PHP
A page cache that runs inside WordPress still boots PHP, loads the autoloaded options and runs the plugin stack before it decides to serve a cached file. A server-level cache answers before PHP starts at all. LiteSpeed sits in front of NVMe storage on every tier here, so turning LSCache on and confirming a cache hit header is the cheapest large win available.
Then deal with the requests that cannot be page-cached. Logged-in traffic, checkout and account screens are uncacheable by definition, and those run the full PHP and database path. That is where an object cache earns its keep: Redis object caching and AccelerateWP come with the managed WordPress plans and cut repeated queries out of exactly those requests.
The image pipeline is usually your LCP
On most content sites the largest contentful paint element is the hero image, so the entire LCP measurement is a story about one file. Serve it at the size it renders at, in WebP — conversion is built in on every plan — with explicit width and height attributes so nothing shifts, and with fetchpriority high so the browser fetches it early.
The mistake that costs more than it saves is lazy-loading the hero. A loading=lazy attribute on the LCP image delays the request until layout, which makes the number you are trying to improve worse. Lazy-load everything below the fold and nothing above it.
Proving it moved, rather than proving the score changed
Lab tools grade one load from one place on one connection, so a two-point score change is noise. Same URL, same tool, same network profile, three runs, take the median, and only believe a difference you can reproduce. A change that improves a lab score and touches no field metric has helped nobody.
Field data is the arbiter, and it lags: real-user reports are built from a rolling window measured in weeks, so a genuine improvement shows up as a trend rather than a jump. Keep a short log of what you changed and when, and read the field data against that log rather than against your memory.
The stack these steps were measured on
Every walkthrough here is run against the platform we operate — cPanel, LiteSpeed in front of NVMe, Softaculous, WP-CLI over SSH — so the field names in the instructions are the field names on your screen.
NVMe storage sits behind a LiteSpeed cache on every tier including the smallest, so speed is the baseline rather than the upsell.
- Four numbers, each with its own tool
- One change per measurement, in order
- Lab results separated from field data
- Engineers on support at any hour
Why HostingFast
Standard on every plan
A loop, not a list
Measure, change one thing, measure again is the whole method, and it is what stops a page of tips becoming cargo cult.
Four numbers, four tools
TTFB, LCP, INP and query count each come with the specific command or report that produces them, plus the published good band.
Ordered by payoff
Server cache, then images, then removal, then the engine — so the largest win lands first and later changes are measured fairly.
5 steps, no padding
Five stages, each ending in a re-measurement, and any stage that moves nothing is reverted rather than kept.
Lab and field kept apart
The page is explicit that a lab score change is not evidence, which is the difference between a real gain and a screenshot.
Engineers on call
Support answers at any hour, and on the Nitro tiers PHP X-Ray points at the slow function rather than leaving you to infer it.
Quick Start
From order to online
- 1
Record the baseline: TTFB, LCP, INP, CLS and query count
Five curl runs for TTFB and take the median. Read LCP, INP and CLS from your field data. Note the query count from Query Monitor on your heaviest real page. Write all of it down with the date; this is the only reference you will have.
- 2
Turn on the server cache and re-measure
Enable LSCache, then confirm you are actually getting a hit by reading the cache header in curl -sI. Re-measure TTFB on the same URL. This is usually the largest single change available, which is why it goes first.
- 3
Fix the hero image, then re-measure LCP alone
Serve the LCP image at its rendered size in WebP, add explicit width and height, set fetchpriority high, and remove any loading=lazy from it. Then check LCP specifically rather than looking at an overall score.
- 4
Remove what you are not using, one item at a time
Deactivate unused plugins and dequeue scripts that load on pages that do not need them, measuring between each removal. Check the autoloaded options size while you are in there, since that is read on every single request.
- 5
Change the engine last, then wait for the field data
Move the PHP version up, add an object cache, or move to a tier with more CPU and RAM — then re-measure. Field data reports on a rolling window, so give a genuine improvement a few weeks to appear before you judge it.
Built In
Loaded onto every plan
- LiteSpeed caching in the server, not bolted on by plugin
- NVMe storage on every tier, not only the expensive ones
- WebP conversion built in, at no extra cost
- Per-site PHP version switching in the control panel
- Staging environments for testing before you ship
- SSH with Git and Composer on the developer plans
- Daily backups with self-service restores from the panel
- Support staffed by humans, every hour of the day
- 99.9% uptime as the target, monitored around the clock
- A renewal price identical to the one you signed up at
Frequently Asked
What people ask us most often
How do I know a change helped and not just moved a score?
Re-measure the same URL the same way, then wait for the field data. A lab tool grades one simulated load, so take three runs and the median before you believe any difference, and treat a two-point score change as noise. The deciding evidence is what real visitors experience — LCP, INP and CLS — which reports on a rolling window and moves as a trend rather than a jump. Keep a dated log of what you changed and read the field data against the log rather than against your memory.
TTFB dropped but LCP has not moved. What now?
Then the bottleneck is on the client rather than the server, and a faster first byte cannot help you. LCP is the render time of the largest element, which on most pages is one image. Identify that element in DevTools first, then check it is discoverable in the initial HTML rather than injected by script, that it is not carrying loading=lazy, that it has fetchpriority high, and that it is served at its rendered size in WebP. Fix those and re-measure LCP on its own.
Does any of this make the WordPress dashboard quicker?
Only some of it. The dashboard is logged-in traffic, so no page cache ever touches it and every click runs the full PHP and database path plus whatever admin-ajax polling your plugins do in the background. Server-level page caching therefore changes nothing there. What does help is an object cache such as Redis, a current PHP version, and removing the plugins that poll. Measure inside the admin with Query Monitor rather than on the front end.
A CDN or a bigger plan?
Depends which number is failing. A CDN moves static assets and cached HTML closer to distant visitors, so it helps if your audience is far from London and your TTFB is dominated by distance. It does nothing for the WordPress dashboard, checkout, account pages or any uncached database query — those run the full distance to the origin regardless. If those are your problem, more CPU and an object cache are the answer.
Keep reading
How to Use a WordPress Staging Site
Clone the live site, test the change on the clone, and push it only when it behaves.
How to Park an Extra Domain
An alias mirrors your site at a second address; a 301 keeps one authoritative. Pick deliberately.
Best Drupal vs WordPress
Two content management systems compared on what each costs you per request and per update.
Web Hosting
cPanel hosting on NVMe with LiteSpeed caching from the entry tier upwards.
Email Hosting
Mailboxes on your own domain, with filtering in front and IMAP, POP and SMTP available.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Put the site on faster ground.
NVMe behind a LiteSpeed cache, staging copies to test on, free SSL and migration, and a renewal price that never moves.
View Web Hosting plans