Case Study: Fixing Hosting Page Speed Fast

A site that loads in 2.8 seconds can still feel broken if the first byte shows up late, the page shifts, and the checkout button becomes clickable after the user already gave up. That is the reality for a lot of “fine on my machine” hosting setups: the dashboard is responsive, the origin isn’t down, but real users see hesitation.

This case study improving hosting page speed is about fixing that hesitation with the least moving parts. The scenario is common: a US-based small business site (WordPress with a few plugins) plus a lightweight customer portal on a subdomain, backed by a typical LEMP stack and a managed database. Traffic is steady, not massive. Complaints show up as “site feels slow” and “admin takes forever.”

The goal was not perfection. The goal was predictable speed with minimal operational overhead.

Baseline: what “slow” actually meant

We started by measuring from the outside, not from the server terminal. Server-side metrics can look clean while users wait.

The initial field symptoms were consistent:

• High TTFB on uncached requests during peak hours
• Largest Contentful Paint (LCP) drifting past 3 seconds on mobile
• Occasional long tasks from third-party scripts delaying interactivity
• Spiky response times on login and cart actions

Instead of chasing everything at once, we separated the work into three layers: origin behavior (server and app), edge behavior (caching and routing), and page weight (what the browser has to chew through).

The first key finding: the site had “caching” but not the kind that mattered for the slowest paths. Static assets were cacheable. HTML was effectively not. Logged-in sessions were treated as fully dynamic even when 80% of the page was identical.

The second key finding: the stack was under pressure in small, expensive ways. PHP workers were blocking, the database was doing repeated work that could be avoided, and TLS plus connection setup costs were being paid too often.

Server-side: reduce time-to-first-byte without guesswork

TTFB is usually where hosting-level fixes pay off fastest. You can minify CSS all day and still lose if the origin stalls.

Right-size concurrency instead of “more CPU”

The server had enough CPU most of the time, but PHP-FPM was configured with conservative limits left over from an earlier, smaller plan. During peaks, requests queued. That queue time is invisible if you only look at average CPU.

We increased PHP-FPM children and tuned the process manager for the actual traffic shape, then validated it by watching request queues and memory pressure. The trade-off is straightforward: more workers means more RAM. If you don’t have headroom, you swap, and swapping will bury you. The fix is safe only if you size it against real memory use.

Fix the “hidden” slow path: uncached HTML

Static caching was fine, but HTML generation was expensive because each request rebuilt the same header menus, product widgets, and personalization that wasn’t actually personalized.

We introduced full-page caching for anonymous users and fragment caching for logged-in pages where only a small portion changed. For WordPress, that typically means a caching layer that can vary by cookie, plus rules that bypass cache for checkout, account, and other sensitive flows.

This is where “it depends” matters. Full-page caching can cause correctness problems if you cache something that should be unique per user. The safer approach is:

• Cache anonymous HTML aggressively
• Cache logged-in HTML selectively, or cache fragments
• Explicitly bypass cart, checkout, and account updates

Database: cut repeated work before adding indexes

The database wasn’t “slow” in isolation. It was busy doing the same lookups repeatedly because the application was asking it to.

We did two practical things:

First, we enabled persistent object caching so repeated queries didn’t hit the database on every page view. Second, we cleaned up the worst offenders in the plugin stack – features that executed heavy queries on every request even when the output was not visible above the fold.

Indexing can help, but it’s not a substitute for eliminating unnecessary queries. Indexes also have a cost on writes. For ecommerce and membership sites, write performance matters.

Compression and HTTP behavior: cheap wins, but verify

We confirmed Brotli (or gzip where Brotli wasn’t available), enabled keep-alive, and ensured HTTP/2 was active. These are not exotic settings, but misconfigurations are common.

We also checked headers for accidental no-store directives on cacheable responses. One plugin was adding conservative headers sitewide.

Edge and routing: make distance less relevant

Hosting speed is not only origin speed. It is also where the request lands and how often it has to land at the origin.

Cache rules that match reality

A lot of setups default to caching “images, CSS, JS.” That helps, but it does not fix the initial navigation delay. The biggest improvements came from caching HTML for anonymous traffic at the edge with clear invalidation rules.

We set different TTLs by path. The homepage and category pages changed occasionally, so they got short TTLs with stale-while-revalidate behavior. Product pages changed less often, so they got longer TTLs. Checkout and account pages were never cached.

The trade-off is staleness. If pricing or inventory must be real-time, you either shorten TTLs or bypass cache for those components. Many stores can tolerate a short window of staleness on non-checkout pages if checkout is authoritative.

Preconnect and fewer handshakes

We reduced the number of distinct hostnames used for critical resources. Each additional hostname can mean DNS, TLS, and connection setup costs, especially on mobile.

This wasn’t about “using fewer tools.” It was about reducing the number of connections the browser must establish before rendering anything meaningful.

Lightweight front door for redirects

The customer portal lived behind a redirecting entry domain. The original redirect page was heavier than it needed to be: a full theme, multiple scripts, and tracking tags that ran before the redirect completed.

We replaced it with a minimal HTML response that prioritized immediate routing and provided a single fallback link. That shaved meaningful time for users who hit the portal link from email or bookmarks.

This is the same operating model used by utility-first routing domains like [turbo.host](https://turbo.host): the front door stays small so the user gets to the actual destination quickly. If your redirect page has a hero image and three analytics tags, it is not a redirect page. It is a delay.

Page weight: focus on what blocks rendering

Once TTFB was stable, we addressed what happens after the first byte.

LCP: make the largest element cheap

The LCP element was usually a large banner image on the homepage and a product image on detail pages. Both were oversized and served in a format that wasn’t optimal.

We resized images to match their rendered dimensions, served modern formats where supported, and ensured proper caching headers. We also fixed lazy-loading behavior that was delaying the LCP image itself. Lazy-loading is good for below-the-fold content, but if you lazy-load the thing you want to paint first, you lose.

CSS and JS: reduce blocking, not just file size

Minification helped a bit, but the bigger win was removing render-blocking behavior.

We inlined a small amount of critical CSS for above-the-fold layout and deferred the rest. For JavaScript, we audited third-party tags and removed two that provided marginal value but added long tasks on mid-range phones.

This is a business decision as much as a technical one. Some scripts pay for themselves. Some are just “nice to have.” Page speed improves fastest when you treat every script as guilty until proven necessary.

Fonts: stop paying the penalty repeatedly

The site loaded multiple font weights across multiple families. We reduced the number of weights, ensured fonts were cached correctly, and avoided loading fonts that weren’t used above the fold.

The visual difference was minimal. The speed difference was not.

Results: what changed in real terms

After changes across the origin, edge, and front-end layers, the performance profile stabilized:

• TTFB dropped significantly on both cached and uncached traffic, with the biggest improvement during peaks
• LCP improved on mobile because the origin responded faster and the LCP element became cheaper to render
• Login and cart flows became more predictable because PHP worker queues stopped forming
• Support tickets shifted from “site is slow” to actual product questions, which is the point

We did not chase perfect Lighthouse scores. We chased user-visible outcomes: faster navigation, fewer stalls, and fewer “why is this taking so long” moments.

What to copy from this case study (and what not to)

If you want the same kind of hosting page speed improvement, copy the ordering, not the exact tools.

Start with TTFB and concurrency. If requests are waiting in line, nothing else matters. Then cache HTML where it is safe, and only then obsess over asset optimization.

Do not blindly cache logged-in pages, and do not treat edge caching as a magic switch. Cache rules are production logic. They need ownership and periodic review.

Also, don’t keep a heavy redirect page because it “looks nicer.” A routing domain has one job: get out of the way.

Closing thought: speed work lasts longer when it is boring. Fewer moving parts, fewer exceptions, fewer pages doing special things – that is how you keep performance from drifting back to “mysteriously slow” six weeks later.