A website can look simple and still make the browser do unnecessary work. It can also send a quick first response and take much longer to show the main content. We kept both points in mind while improving our own WordPress website.
Our WordPress speed optimisation work combined Cloudflare caching, Redis at the hosting layer and smaller, page-specific CSS bundles. A fresh check on 22 October 2026 recorded a 79 ms median time to the first response headers across five anonymous homepage requests.
Four requests were below 100 ms. The first took 209 ms. These figures describe the initial HTML response on one network route, not the time needed to display a complete page on a customer’s phone.
WordPress speed optimisation: what we measured, and what we did not
Time to First Byte, or TTFB, measures the wait before a page response starts arriving. It includes more than the time spent running WordPress. DNS lookup, connection setup and network travel can all affect it.
Our check used five consecutive HTTPS requests to the public homepage. Each opened a new connection, sent no login cookies and waited for the response headers and HTML body. We did not clear Cloudflare’s cache. All five responses returned HTTP 200 and CF-Cache-Status: HIT, with Cloudflare’s Delhi location code in the response.
| Request | First response headers | HTML body complete | Cloudflare cache |
|---|---|---|---|
| 1 | 209 ms | 221 ms | HIT |
| 2 | 79 ms | 90 ms | HIT |
| 3 | 78 ms | 90 ms | HIT |
| 4 | 80 ms | 93 ms | HIT |
| 5 | 62 ms | 73 ms | HIT |
The median was 79 ms for the first response and 90 ms for the HTML body. The first request included more connection setup time. It was still a cache hit, so it should not be labelled an uncached server test.
This was a small command-line check from one client connection. It did not render the page, download its images and scripts, simulate a mobile network or measure real visitors. We did not preserve a matched pre-change baseline, so we are not claiming a percentage improvement from these samples.
1. Let Cloudflare serve suitable public pages
WordPress normally builds a page by running PHP and reading stored content. For a public page that has not changed, repeating all that work for every visitor is often unnecessary.
We configured Cloudflare to cache eligible public HTML. A cached response can be delivered from Cloudflare’s network without asking the hosting server to rebuild the page each time.
The Cloudflare cache response documentation explains the difference between a HIT, a MISS and a response that bypasses caching. Recording that status alongside a timing helps explain which part of the system you are testing.
Our rule uses a four-hour edge cache period for eligible pages. Admin screens, logged-in visitors, form routes, WordPress endpoints and requests carrying relevant session cookies are excluded. The rule also excludes query-string requests and XML files.
Those exclusions matter. An enquiry form or job application page should not accidentally receive another visitor’s session state. A blanket rule that caches every response would be a poor fit for this website.
2. Use Redis for work at the hosting server
We enabled Redis-backed page caching through W3 Total Cache. We also enabled its Redis object cache, which can reuse stored WordPress data across requests instead of repeating some database work.
Page caching and object caching do different jobs. The first stores a prepared page response. The second helps with reusable data inside WordPress. Neither removes the need to keep content current or handle forms correctly.
There is also an important measurement limit here: a Cloudflare HIT usually avoids the hosting server. Our 79 ms median therefore does not measure Redis performance or prove how much time Redis saved. Testing that would require a separate, controlled comparison at the hosting layer.
The WordPress optimisation handbook describes caching as one part of a wider performance review. Hosting, software, images and server load still affect the result.
3. Send CSS that belongs to the page
Our theme builds separate CSS bundles for the homepage, service pages, form pages and blog. A page loads the bundle for its layout rather than several separate theme stylesheets.
We also reviewed frontend assets from the page builder, WordPress and plugins. Where our custom templates did not need them, we removed them from that route. Assets needed by the Contact form were retained, and blog pages keep the WordPress styling they require.
This needs care. Removing a stylesheet because the page still looks fine at first glance can break a menu, validation message or small-screen layout. We checked the affected page types and kept the changes specific to the templates we control.
Bundling CSS can reduce separate file requests. Keeping unused assets off a page reduces unnecessary work. Neither is a substitute for checking what the browser actually downloads and renders.
4. Keep images and optional features under control
A fast HTML response can still lead to a heavy page. Large images, unnecessary fonts and third-party tools can add download time after the first response arrives.
For this article, the featured image is about 85 KB and the second image is about 95 KB in WebP format. WordPress provides smaller responsive versions. The featured image is loaded promptly, while the image further down the article uses lazy loading.
Our chat widget is deferred until interaction or a short delay. That reduces work at the start of the page load, but it still needs testing when the visitor begins using it. Delaying a script does not remove its cost.
A fast response must lead to a usable page
TTFB is only the beginning. Largest Contentful Paint, or LCP, measures when the largest visible image, text block or other qualifying element is rendered. That is closer to what a visitor experiences while waiting to read a page.
We also need to watch layout shifts and interaction delays. A page that moves while someone taps a button, or freezes while they type, needs attention even if its server response is quick.
The five-request check above does not establish a Lighthouse score or a Core Web Vitals pass. Ongoing review should include browser tests, mobile conditions and real visitor data where enough data is available.
The part that is easy to forget: refreshing cached content
Caching introduces another responsibility. When an article, price or service detail changes, the website must refresh the correct cached copies.
During our blog rollout, a published article appeared on its own page while an older blog listing was still cached. We refreshed the listing. We also found an older sitemap response in the WordPress page cache. We excluded sitemap XML from page caching and regenerated the SEO sitemap, then confirmed that the newly published article appeared.
Our publication checks now cover the article URL, blog listing, canonical address and sitemap. A successful save inside WordPress is not the end of the check.
What should an Indian business check first?
Start with the pages that bring enquiries or bookings. Ask your developer for a short review covering:
- The first response time and the visible loading experience.
- Which pages can be cached and which must stay dynamic.
- Images and scripts that make important pages unnecessarily heavy.
- Mobile menus, forms, validation and confirmation messages.
- How content changes are refreshed across the cache and sitemap.
The useful lesson from our own site is to remove repeated work, send less unnecessary material and verify the customer journey. The right setup depends on what your website does.
Netens can review this through our web development services and cloud and hosting services. Share the pages that feel slow, and we can discuss what to measure before deciding what to change.
Measurements recorded on 22 October 2026 from five anonymous requests on one network route. Results vary by device, connection, location and cache state. Images are AI-generated representations, not photographs of our team.