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–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 that part you can fix without upgrading anything.
You can’t render what hasn’t arrived. TTFB is the tax every other optimization pays first.
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.
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.
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.
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.
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.
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.