Time to First Byte is the delay before your server sends anything at all, the silent gap before the browser has a single byte to render. On cheap shared hosting, TTFB of 1.5 to 2 seconds is common, and it puts a hard floor under every other speed metric: your LCP can never beat your TTFB. The good news is that most of that delay is WordPress working harder than it needs to, not the hardware, and you can reduce that part without upgrading anything.
You can’t render what hasn’t arrived. TTFB is the tax every other optimization pays first.
Why TTFB is high on shared hosting
On a shared plan, your site is one of many on the same machine. The CPU, memory and disk are split between all of them, and most plans also cap how many PHP processes your account can run at once. When several uncached requests arrive together, they queue, and every request in the queue waits before it sends a byte.
That is why cheap hosting punishes uncached WordPress so hard. Each page view needs PHP and the database to do real work on a server that is already busy. Take that work away and the same server suddenly looks a lot better.
Measure before you change anything, so you can prove each fix worked. Test logged out, in a private window, and run each test a few times. If you want the full method for splitting the network from the server, I wrote it up in how to fix a slow time to first byte before blaming your host.
Fix 1: Stop building pages per visitor (page caching)
By default, WordPress rebuilds every page on every visit: PHP boots, plugins load, dozens of database queries run, HTML is assembled, hundreds of milliseconds of work to produce the same page it produced last time. Page caching saves the finished HTML and serves it directly, collapsing TTFB from 1,500ms toward 200ms in one move.
On LiteSpeed servers (most budget Hostinger-class hosting runs LiteSpeed), use LiteSpeed Cache. It serves cached pages at the server level, before PHP even wakes up, which is exactly what slow shared hardware needs. One caching layer, configured once; a second caching plugin on top adds conflicts, not speed.
Then confirm it is working. Open DevTools, reload the page while logged out, click the HTML document and read the response headers. On LiteSpeed, x-litespeed-cache: hit means the visitor got the cached copy. If you only ever see a miss, something (a cookie, a query string, a plugin setting) is stopping the cache.
Fix 2: Find the plugin dragging every request
Cache misses and logged-in pages still run full WordPress, and one heavy plugin can add a second to every one of those requests: security suites scanning inline, "related posts" plugins running brutal queries, anything phoning an external API before the page renders. Install Query Monitor briefly and read the slowest queries and the plugin timings; the offender is usually obvious.
Replace or reconfigure it. This is also the moment to delete deactivated plugins entirely: dead weight is still attack surface and clutter.
Be careful with the newer wave of AI plugins for the same reason. Anything that waits for an outside AI service while the page is being built adds that whole wait to your TTFB. If you are weighing one up, read what an AI agent actually is, and when your business needs one before you install it on a busy shared plan.
Fix 3: Shrink the database WordPress wades through
Years of accumulated post revisions, expired transients, and, the sneaky one, autoloaded options from long-deleted plugins load on every single request. Check your autoload size; anything past ~1MB is adding drag to every page build. Clean revisions and transients, and clear orphaned autoloaded options. Ten minutes of housekeeping, permanent per-request savings.
Recent WordPress versions include a Site Health check that warns when autoloaded options get large, which is a quick first look. Take a database backup before any cleanup, and remove options only when you are sure the plugin that created them is gone.
Fix 4: Object caching and PHP version
If your host offers Redis or Memcached (many budget hosts now do), enable object caching. It saves repeated database lookups within page builds and noticeably helps dynamic pages, admin, and WooCommerce. And confirm you’re on a current PHP version; each major release has been meaningfully faster, and hosts frequently leave old sites on old versions unless asked.
Before switching PHP versions, check that your theme and plugins support the new one, and test on a staging copy if your host provides it. Most control panels let you switch back in a minute if something breaks.
Fix 5: Know when it really is the host
After caching, plugin cleanup, and database hygiene, measure again: Google’s TTFB guidance calls under 800ms acceptable and cached pages should sit far below that. If cached pages are fast but uncached requests still crawl, you’ve hit the hardware floor: oversold shared CPUs are the bottleneck, and decent LiteSpeed hosting costs little enough that migration beats further tinkering.
After TTFB, the next bottleneck
Once the first byte arrives quickly, the delay moves into the page itself. On most WordPress sites the next thing holding up the first paint is a stack of stylesheets in the head. My guide to stopping render-blocking CSS in WordPress picks up exactly where this one ends.
This exact sequence (cache, cull, clean, then judge the host honestly) is the first hour of every speed optimization project I run, and keeping it fast afterward is half the point of monthly maintenance: TTFB decays quietly as plugins and data accumulate, and quarterly measurement catches it early.
If you would rather have someone do the cleanup and leave notes on what changed, you can hire a WordPress developer for a one-off pass.
