Web Development Company in Pune: Why Your Website's Server Response (TTFB) Is Slow and How Caching and a CDN Fix It
A business website's server response is slow because the server does too much work before it sends the first byte of the page, or because that first byte has a long way to travel. The usual causes are cheap shared hosting, a server far from your visitors, no page cache, a database loaded with slow queries from plugins, and redirects that add trips before the page even starts. A good web development company in Pune fixes this in layers: better hosting in the right region, a full-page cache, an object cache for the work that cannot be cached whole, a CDN for distance, and a clean-up of plugins and queries. The target to aim for, according to web.dev, is a Time to First Byte (TTFB) of 0.8 seconds or less at the 75th percentile of real visitors.
This guide is for business owners, marketing heads and anyone who has been told "your site has a slow server response" by PageSpeed Insights and does not know what to ask next. It explains what TTFB is, how to measure it with free tools, what each fix does, and what to ask a developer before you agree to a quote. The worked example is hypothetical: the numbers are illustrations to show how the pieces add up, not measurements from a real site or benchmarks you should expect.
Our article on Interaction to Next Paint covers how a page reacts after a tap. This one is narrower: the time before the browser receives anything at all. For general speed work, see website speed optimisation for Indian businesses.
What TTFB actually measures
TTFB is the time between a visitor starting to navigate to your page and the first byte of the response arriving. web.dev describes it as the sum of several phases:
- Redirect time
- Service worker startup time, if one is used
- DNS lookup
- Connection and TLS negotiation
- The request itself, up to the point where the first byte of the response arrives
Two of those phases are about the network (DNS, connection and TLS) and one is about your server (the wait between the request and the first byte). The rest depend on how your links and redirects are set up. This split matters because each fix is different: caching for a slow server, a CDN or better location for distance, corrected links for redirects.
TTFB comes before everything else in the loading sequence. web.dev notes that for a page request it precedes every other meaningful loading metric, including First Contentful Paint and Largest Contentful Paint. So a slow server response adds its delay to every metric that follows. If the first byte arrives at 1.9 seconds, the page cannot show its main image at 1.5 seconds, however well the image is compressed.
What is a good TTFB? The thresholds
TTFB is not a Core Web Vitals metric, and web.dev says a site need not hit the "good" threshold if it still scores well on the metrics that count. Treat it as a diagnostic: if Largest Contentful Paint is slow and TTFB is poor, start at the server. If TTFB is fine, look at images or fonts instead.
web.dev gives these thresholds as a rough guide, and PageSpeed Insights uses the same cut-offs for its experimental TTFB field metric:
| Rating | TTFB at the 75th percentile |
|---|---|
| Good | 0.8 seconds (800 ms) or less |
| Needs improvement | Between 800 ms and 1,800 ms |
| Poor | More than 1.8 seconds (1,800 ms) |
The 75th percentile is deliberate. PageSpeed Insights explains that it chooses that point so developers can see the more frustrating experiences, not only the average. If your 75th percentile is 700 ms, three out of four visits got the first byte in 700 ms or less, and one in four took longer.
How to measure TTFB without paying for a tool
Do this before you speak to any developer. It takes about fifteen minutes and gives you facts instead of opinions.
Step 1: PageSpeed Insights field data
Enter your home page and one or two important inner pages (a service page and a contact page, for example) into PageSpeed Insights. At the top, under real-user data, look for the TTFB value.
Per Google's PSI documentation, this real-user data comes from the Chrome User Experience Report and covers the previous 28 days; if a page has too few visits, PSI falls back to the whole origin, or shows nothing. PSI labels TTFB experimental. web.dev recommends field data as the primary source for TTFB, partly because redirects affect it and many lab tools measure only the final URL, which hides that extra delay.
Step 2: Chrome DevTools
Open your page in Chrome, press F12, go to the Network tab, reload, and click the first request (the document). In the Timing tab you will see the phases. Chrome's documentation describes the "Waiting (TTFB)" phase as the browser waiting for the first byte, and says it includes one round trip of latency plus the time the server took to prepare the response. If that bar is long and the DNS and connection bars are short, your server is slow to build the page. If the connection bars are long, the distance or TLS setup is the issue.
Step 3: WebPageTest from a relevant location
WebPageTest lets you pick a test location and shows a waterfall. Catchpoint's documentation describes First Byte as the time from the start of navigation until the first byte of the server response, with the "back-end time" being the server's page-building time. Run the test from a location close to your real audience, and run it three or more times, because one run can mislead.
Step 4: test an uncached page
This step is the one most people skip. web.dev warns that caching can hide a slow backend: testing a cached page often shows no TTFB problem, while some real visitors still hit the slow path. Its advice is to test less common pages, or add a URL parameter that bypasses the cache, and see whether the result matches what field data shows.
It also explains the reverse. When field TTFB is much worse than your lab result, it often points to server-side caching, redirects or network differences that the lab run did not capture.
Why TTFB is high: the usual causes on business websites
Slow first bytes on business websites tend to trace back to a handful of patterns. This list is general and not a diagnosis of any one site.
1. Hosting that is too small or too crowded
web.dev puts it simply: before anything else, look at hosting. It says shared hosting is generally slower, which is fine for a small mostly static site but becomes a problem for larger sites with personalisation and heavy database work. It lists two things to look for in a host: how much memory your application instance gets (too little and it struggles to serve pages quickly), and whether the host keeps its backend software up to date, since newer language, HTTP and database versions improve performance over time.
For hosting choices in India, see our guide to choosing WordPress hosting.
2. The server is far from your visitors
web.dev notes that a well-optimised backend can still give a high TTFB to users far from the origin server. The fix is either hosting in a region close to your main audience, a CDN in front of the site, or both. Pick the hosting region from where your visitors are, not from where the cheapest plan happens to be.
3. No page cache, so every visit runs the whole application
On a typical WordPress site, the WordPress hosting handbook explains, each request involves processing PHP, querying the database and sometimes collecting information from external APIs, all of which take resources and time. Without a cache, this happens again for every visitor, even when the page has not changed since yesterday.
4. Slow database queries and heavy plugins
web.dev's guide says WordPress performance is affected by the number and quality of plugins and by the theme. A plugin that runs many queries on every page, or calls an external service during page generation, delays the first byte directly. This is one of the most common reasons a site with decent hosting is still slow.
5. Redirects before the page
web.dev lists redirects as a common contributor to high TTFB, and says a chain makes it worse. Typical examples are links without https:// and tracking redirects on ad links. web.dev suggests fixing the same-origin redirects you control first, and using HSTS to avoid the HTTP-to-HTTPS hop on repeat visits.
The fixes, in the order we would apply them
Think of caching as a series of layers a request passes through. The WordPress hosting handbook lists the typical order of checks: the browser cache, then a CDN, then a full-page cache on a reverse proxy such as Varnish or NGINX, then file-based full-page caching by a plugin, then static files, the opcode cache, the object cache and the fragment cache. A request is served from the first layer that has the answer. The earlier the hit, the less work the server does.
Layer 1: a full-page cache
A full-page cache stores the finished HTML of a page and serves it again without running PHP or touching the database. The WordPress handbook says the best approach is a reverse proxy like NGINX or Varnish, which serves cached output straight from memory or disk without involving the web server, PHP or database at all. If that is not available, a file-based cache from a plugin still helps, although each request reaches the web server and PHP at least once.
Two cautions from the same handbook: exclude pages that differ per user (cart, checkout, account, logged-in users), and clear selectively, because purging everything forces WordPress to rebuild every page.
For a brochure or service website where most pages are the same for everybody, this single layer often produces the biggest drop in TTFB.
Layer 2: an object cache
Some pages cannot be cached whole: a logged-in dashboard, a store cart, a search result. For these, an object cache saves the results of expensive operations. The WordPress developer reference says the object cache exists to save trips to the database, and that by default it is non-persistent: data lives in memory only for the duration of one request. A persistent object cache (the reference mentions Memcached-based options, and Redis is widely used as well) keeps results between requests.
A related point from the same reference: if persistent caching is configured, the Transients API uses it. If not, transient data is stored in the database options table. So on a site with no persistent object cache, plugins that rely on transients are quietly adding database work.
Persistent object caching needs server support. It is typically available on VPS, cloud or managed WordPress plans, and not always on basic shared hosting. Ask your host before you pay a developer to configure it.
Layer 3: a CDN
A content delivery network keeps copies of your files on edge servers close to visitors. web.dev says this solves the proximity problem and often brings fast DNS and modern protocols and TLS.
There is a catch many owners miss. A CDN only helps TTFB for the HTML if it is allowed to cache the HTML. Cloudflare's documentation says that by default its CDN caches files by extension and does not cache HTML or JSON, and that it does not cache a response when the Cache-Control header is private, no-store, no-cache or max-age=0, or when a Set-Cookie header is present. The WordPress hosting handbook makes the same warning in different words: without full-page caching on the CDN edges, TTFB can increase because the edge must fetch the page from your origin server before serving it.
So "we put the site behind a CDN" is not an answer by itself. Ask: is the HTML cached at the edge, for how long, and how is it cleared when I publish an update? Cookies set on every page (by plugins, for instance) can quietly stop edge caching from working.
The handbook also warns that a CDN must be purged properly when you change content, otherwise people in some regions may see old results, a problem that is hard to troubleshoot.
Layer 4: clean up the application
Caching hides work. It does not remove it. The first uncached visit, a logged-in user, a cache that has just been cleared: all of these still run the application. So the underlying cost needs attention too:
- Audit plugins. Remove those that are unused, replace heavy ones, and find the ones that run slow queries or external calls on every page.
- Find slow queries. The free Query Monitor plugin, described on WordPress.org, shows database queries, flags slow, duplicate or erroneous ones, and groups them by the plugin, theme or function responsible. It is a development tool, so use it on a staging copy where possible.
- Add Server-Timing headers. web.dev explains that the Server-Timing header lets the backend report how long database queries, server-side rendering or CDN cache hits took, visible in Chrome DevTools and in the Navigation Timing API for real visitors. A developer who adds this can show exactly where the time goes.
- Fix redirects and keep PHP and the stack up to date.
A hypothetical worked example
This example is invented for illustration. The site, the numbers and the results are not from a real client and are not benchmarks.
Imagine a service business in Pune with a 25-page WordPress site. It runs on an inexpensive shared plan hosted overseas. Visitors are mostly in Maharashtra, on mobile. PageSpeed Insights field data shows a 75th percentile TTFB of 1.9 seconds, which falls in the "poor" band (above 1.8 seconds).
A developer reviews the site and finds, in order:
| Finding | Illustrative effect on TTFB | Fix |
|---|---|---|
| Server located far from visitors, no CDN | Adds a long network round trip to every phase | Move to a host in a nearby region, add a CDN |
| No page cache, so every view runs PHP and database | Largest share of the delay | Full-page cache for public pages |
| One plugin runs a slow query on every page | Adds delay on uncached views | Replace or remove the plugin |
| Marketing links without https:// and a tracking redirect | Adds an extra hop for ad traffic | Correct the links, use final URLs |
After the changes, suppose the 75th percentile TTFB drops to around 600 ms. That would be in the "good" band (800 ms or less). Remember that PageSpeed Insights field data covers 28 days, so the improvement will appear gradually, not the next day. The lab test would show the change sooner.
The useful lesson is that four separate causes needed four different fixes. Paying only for a CDN would have helped one of them.
What a web development company in Pune should tell you before quoting
Whether you work with us or another team, a quote for server-response work should answer these questions. Use this as a checklist.
- Which TTFB did you measure, where, and with which tool? Ask for the PageSpeed Insights field value, a DevTools timing screenshot and at least one WebPageTest run.
- Where is the server now, where are most of my visitors, and how much memory and which PHP version does the plan have?
- Is a full-page cache in place, which layer is it (server, plugin, CDN), and which pages are excluded?
- Is there a persistent object cache, and does the host support one?
- Is the HTML cached at the CDN edge, for how long, and how is it purged when I publish?
- Which plugins add the most queries or external calls? Will you show me the Query Monitor results?
- Which redirects are in the chain for my main pages and ad links?
- How will we know it worked? Agree a target (for example, field TTFB at or below 800 ms at the 75th percentile) and a date to re-check, allowing for the 28-day field window.
Working with Govindani Infotech on a slow-server review
Govindani Infotech is a Pune-based web development company at 2nd Floor, Landmark Plaza, 206 Satara Road, Parvati Paytha, Pune 411009. We build business websites, e-commerce stores, CRM systems, WhatsApp integrations and NGO platforms, and a slow first byte is a question that comes up on all of them, because a store, a donation page and a brochure site have different caching limits.
If you already have a site, the most useful first step is a short review: your PageSpeed Insights field data, a DevTools timing view of your main pages, the hosting plan and region, and a list of the plugins in use. From that we can tell you whether the problem is hosting, caching, plugins or redirects, and what each fix would involve, before any work is scoped. You can send the site address on WhatsApp at wa.me/919201958278 or write through our contact page to ask for a quotation. For a rebuild instead of a repair, our website creation service page describes how we approach new builds, and pricing for websites shows how packages are structured.
Frequently Asked Questions
What is a good TTFB for a business website?
web.dev's rough guide is 0.8 seconds (800 ms) or less at the 75th percentile of real visitors, with anything above 1.8 seconds rated poor. Treat these as guidelines. A site that responds a little slower but renders quickly can still deliver a good experience, because TTFB is not itself a Core Web Vitals metric.
Does a CDN always reduce TTFB?
No. A CDN reduces distance for files it can cache, and it needs to cache your HTML to help the page request itself. Cloudflare's documentation says it does not cache HTML by default and does not cache responses with certain Cache-Control values or a Set-Cookie header. If the edge has to fetch every page from your origin, TTFB may not improve and can even rise.
Why is my TTFB fine in a test but poor in PageSpeed Insights field data?
Field data reflects real visitors over 28 days, including those on slow networks, those who hit uncached pages and those arriving through redirects. A lab test often hits a warm cache from one location. web.dev suggests testing uncached pages, checking redirects and looking at where your traffic comes from to explain the gap.
Do I need Redis or a persistent object cache for my WordPress site?
Not always. A simple brochure site with a good full-page cache may not need one. It becomes useful for pages that cannot be cached whole, such as logged-in areas, stores and sites with heavy database work. It also needs host support, which is usually found on VPS, cloud or managed plans.
Will changing my hosting alone fix a slow server response?
It can help, especially if the current plan has little memory, is far from your visitors or runs old software. But web.dev and the WordPress hosting handbook both point to several other contributors: missing caches, plugin and query load, and redirects. Measure first so you know which of these is actually the cause.
Sources: web.dev: Time to First Byte (TTFB), web.dev: Optimize Time to First Byte, PageSpeed Insights documentation (Google), Chrome DevTools: Network features reference, Make WordPress Hosting: Performance handbook, WordPress Developer Resources: WP_Object_Cache, Cloudflare Docs: Default cache behavior, Query Monitor on WordPress.org, Catchpoint: WebPageTest Instant Test