Reduce Initial Server Response Time: A Guide for eCommerce Stores

If you’ve ever tested your store in Google PageSpeed Insights, or in Lighthouse, the audit tool built into Chrome, and seen the warning “Reduce initial server response time”, your server took too long to start sending the page. The check fails when the first bytes of the page’s HTML take more than 600 ms to arrive. Since October 2025, the same check appears under a new name, “Server responded slowly”, in the Document request latency section of PageSpeed Insights.

Google also measures that moment on real visits, as time to first byte (TTFB). It counts a page as good when 75% of visits get the first byte within 800 ms. So a store can fail the test in PageSpeed Insights and still pass on real visits, or the other way round.

Homepage TTFB is one of the first numbers we look at in our store health checks, and the warning never says which part of the setup is slow. The host, the platform, the theme and the code all get blamed in turn, and each fix only works if it targets the step that is slow on your store.

What does “reduce initial server response time” mean?

Reduce initial server response time is the Lighthouse warning for a slow main document. It appears when the browser waits more than 600 ms for the server to start sending a page’s HTML. Lighthouse 13 moved the check into the Document request latency insight, which now reports it as “Server responded slowly” next to redirect and compression checks.

The main document matters more than any other request because everything else waits for it. Until the HTML arrives, the browser has no list of stylesheets, scripts or images to fetch, so a slow initial server response time delays everything that follows.

Where the warning went in Lighthouse 13

Since Lighthouse 13, published on October 10, 2025 and in PageSpeed Insights within a week, the server response check is grouped with the redirect and compression checks in the Document request latency insight. The insight shows three lines, each with a pass and a fail version:

• “Avoids redirects” or “Had redirects (N redirects, +X ms)”
• “Server responds quickly (observed X ms)” or “Server responded slowly (observed X ms)”
• “Applies text compression” or “No compression applied”

The threshold stayed at 600 ms, and the performance score didn’t change, because scoring is based on the metrics rather than the audits. Google’s Document request latency page lists the three failure conditions and the fix for each.

What is a good server response time?

A good server response time is under 600 ms in a Lighthouse test and 800 ms or less for real users at the 75th percentile, as measured by the Chrome UX Report (CrUX). The two numbers measure different things, which is why the same store can pass one and fail the other.

What is TTFB, and what makes up time to first byte?

Time to first byte (TTFB) measures how long a page takes from the start of navigation until the first byte of its response arrives. Google’s web.dev splits it into five phases: redirect time, service worker startup, DNS lookup, connection and TLS negotiation, and the request itself. That last phase is where the server builds the page.

Here are the five phases in order, as web.dev defines TTFB:

1. Redirect time. Any hop before the final URL, such as http to https or a trailing-slash fix.
2. Service worker startup time. Only counts if the site registers a service worker.
3. DNS lookup. Turning the hostname into an IP address.
4. Connection and TLS negotiation. The TCP handshake and the TLS handshake.
5. The request itself, until the first byte of the response arrives. This is the phase where the server runs your application and builds the page.

Field TTFB from CrUX includes all five phases. Lighthouse’s server response check isolates the last one and leaves DNS and redirect time out. That difference explains most cases where the lab number and the field number disagree. It also means a redirect chain can push a store over the 800 ms field line while the lab check passes, because the lab never saw the redirect.

Web.dev adds that TTFB comes before every other loading metric. A slow first byte pushes back First Contentful Paint and Largest Contentful Paint by the same amount, which is why a server fix often moves the rendering metrics too.

How to measure TTFB: lab data vs field data

Measure TTFB in two places. Field data from the Chrome UX Report, shown in PageSpeed Insights, tells you what real Chrome users got at the 75th percentile over the last 28 days. Lab tools such as Lighthouse, Chrome DevTools and curl time one request at a time, so you can compare a cached page with an uncached one.

Field data: PageSpeed Insights and the Chrome UX Report

Field TTFB is what real Chrome users got, at the 75th percentile, over the last 28 days. PageSpeed Insights labels it an experimental metric and shows it in the field section next to the Core Web Vitals. A page with little traffic may have no field data at all, and then the lab is all you have. Our older guide to lab and field data in PageSpeed Insights explains how the two sections are built.

Lab data: Lighthouse and Chrome DevTools

Lighthouse times one simulated load and checks the server’s response against 600 ms, with DNS and redirect time left out. To check TTFB in Chrome yourself, open DevTools, go to the Network panel, click the document request and open the Timing tab. Read the DNS Lookup, Initial connection and Waiting (TTFB) rows. Then do it twice: once on a page the cache has already served, and once on a page it hasn’t, such as a category URL with a filter combination nobody has used. The gap between the two Waiting (TTFB) values is the first clue about where the time goes.

How to check server response time with curl

curl’s write-out timings show each phase from the command line, with no browser cache in the way. This command prints every phase as a cumulative time from the start of the request:

curl -s -o /dev/null -L -w "dns %{time_namelookup}\nconnect %{time_connect}\ntls %{time_appconnect}\nredirects %{time_redirect}\nfirst byte %{time_starttransfer}\ntotal %{time_total}\n" "https://www.example.com/"

time_starttransfer is the time until the first byte was received, and curl’s documentation notes that it includes the time the server needed to calculate the result. time_redirect is the cost of every redirect step before the final request started. Run the command twice: once as it is, and once with a throwaway query parameter such as ?nocache=1234 on the URL, which makes most caches treat it as a new page. The difference between the two first byte values is the cost of an uncached page build.

Split server time with the Server-Timing header

The Server-Timing response header lets your backend report where its own time went on each request. web.dev’s example looks like this:

Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2

The values appear in the Timing tab of Chrome DevTools next to the network phases, and you can collect them from real users through the Navigation Timing API’s serverTiming property. That turns “the server is slow” into “the database took 121 ms”. MDN’s Server-Timing reference adds a warning: the header can expose application and infrastructure details, so send it only to your own team or to authenticated users.

How to reduce server response time, cause by cause

To reduce server response time, find the slow phase first, then fix that layer. Remove redirects, put a CDN in front to cut DNS, connection and TLS time, cache full pages at the server or edge, give the store enough dedicated hosting, fix slow database queries, and speed up the code that builds each page.

Anyone searching for how to reduce initial server response time gets the same six fixes in a fixed order. The order that works is the one your measurements set, because each symptom points at a different layer.

Remove redirects before the real page

Link straight to the final URL. Same-origin redirects are the ones you control: http to https, a missing or extra trailing slash, a hop to a country store. Cross-origin redirects from ad platforms, link shorteners and newsletter tools are often outside your control, so give partners the final URL from the start. Add a Strict-Transport-Security header so returning visitors skip the http hop, and submit the domain to the HSTS preload list to remove it on the first visit too. PageSpeed Insights reports leftover hops as “Had redirects” with their cost in ms.

Cut DNS, connection and TLS time with a CDN

Put a CDN in front of the store so shoppers connect to an edge server near them. CDN providers usually offer very fast DNS resolution, and they support HTTP/2 or HTTP/3 and current TLS versions, which shortens the connection and TLS phases. Lighthouse lists “Use a CDN to reduce network latency” among its own fixes for this audit. Without HTML caching at the edge, the CDN still forwards every page request to the origin and waits for it, so the server phase of TTFB doesn’t move at all.

Cache full pages at the server or the edge

Cache full pages so the application doesn’t run for most requests. Set Cache-Control headers so the CDN can hold the HTML at the edge, and use a server-side page cache for the rest. Caching can hide a slow backend, and every cache has misses: the first request after a deploy, every request after you flush the whole cache, URLs nobody has asked for yet, and pages with many variants, such as one entry per customer group or per search term. A cache warmer refills the top pages after a deploy, though it can’t cover every URL. Those pages still go through the cache. They hit it less often.

Give the store enough dedicated hosting

Give the application enough CPU and memory, keep the backend stack updated, and move off crowded shared hosting, which is generally slower. On larger stores, split the tiers. Adobe’s own guidance for Magento (Adobe Commerce) is to install Varnish on a separate server in front of the web tier. Server autoscaling adds capacity when traffic peaks, which keeps response times from climbing under load. It leaves a single request exactly as fast as before, so a slow page build needs a different fix.

Fix slow database queries

Find the slow queries first. They show up as a large db value in Server-Timing or as entries in the database’s slow query log. Index the columns your filters and sorts use, and keep the database’s max_connections setting in line with the number of PHP threads in the application server, as Adobe recommends. Platforms with flexible attribute models are query-heavy by design, and Magento’s EAV model is the one most eCommerce teams meet, so query count matters there as much as query speed.

Speed up the code that builds each page

Lighthouse’s doc for this audit, “Reduce server response times”, puts application logic first: optimize it to prepare pages faster. Profile the templates, loops, extensions and apps that run on a slow page and remove what doesn’t earn its time. 103 Early Hints can start asset downloads while the server is still working, and web.dev recommends it when backend work is significant, but it can mask a slow backend, so keep measuring real server time with Server-Timing. Which code to profile depends on the platform: the Magento page build, the Shopify theme’s Liquid, or the renderer on a headless frontend. The next three sections take them in turn.

How to reduce TTFB on Magento and Adobe Commerce

Magento stores fail TTFB far more often than Shopify stores. In HTTP Archive’s September 2026 data, 23% of Magento sites had a good TTFB, against 84% (mobile) to 93% (desktop) of Shopify sites. The fixes are Varnish for cached pages, a tuned server stack, and a faster page build for every request the cache can’t answer.

Those figures come from HTTP Archive’s technology report, which counts the share of sites with a field TTFB of 800 ms or less at the 75th percentile. The Magento share is improving, from 16.6% on mobile in September 2025 to 23.0% a year later. The dataset holds about 13 times more Shopify sites than Magento sites, and HTTP Archive itself warns that correlation doesn’t equal causation.

Cached pages: Varnish and a tuned server stack

Lighthouse’s whole Magento advice for this audit is one line: “Use the Varnish integration.” Adobe says the same with more force. It strongly recommends Varnish in production and calls the built-in full page cache, which writes to the file system or database, much slower. Once Varnish answers the cached pages, the rest of the stack decides how fast the remaining requests are:

• Valkey for cache and sessions on 2.4.9, since Redis cache isn’t supported there, with cache and sessions kept separate.
• Production mode, because default mode isn’t optimized for production due to how it handles static files.
• A supported PHP version (8.5 on 2.4.9, 8.4 or 8.3 on 2.4.8) with OPcache sized for the codebase, for example opcache.memory_consumption=512 and opcache.max_accelerated_files=60000.
• Indexers set to Update on Schedule, with cron running so the schedule is honored.

The full list of fixes is in our guide to speed up Magento.

Uncached pages: a faster page build with Expedio

Every request the cache can’t answer goes to PHP: the first request after a deploy or a cache flush, URL combinations no shopper has opened yet, and any page with one cacheable="false" block, which makes the whole page uncacheable. Catalog pages for logged-in customers and search results are cached too, one entry per customer group or search term, but those entries miss far more often than the homepage does, and a flush empties them all. Our guide to the Magento full page cache shows which requests miss and why.

For the requests your cache can’t answer, Expedio makes the server build each Magento page at least 2x faster, measured as TTFB, and lets the same server handle 3x the traffic before response times start to rise. It is scandiweb’s software for the page build itself. It applies Liquid, the open-source template language created at Shopify, and its core is open source. In a benchmark on one merchant’s Hyvä store, measured as server response time, pages built with all caches empty took a median of 57 ms instead of 181 ms, and a full category page made 30 database queries instead of 655. Expedio works on Magento Open Source, Adobe Commerce and Commerce Cloud, with any theme and any host, and comes built into ReadyMage hosting. It doesn’t change the theme, the data, the checkout or the admin.

Why a new theme leaves TTFB where it was

A new theme fixes what the browser does, and the server’s first byte needs server work. HTTP Archive’s September 2026 data makes the split visible: 23.2% of Hyvä sites had a good TTFB on mobile, the same share as Magento overall at 23.0%, while 66.4% of them passed all Core Web Vitals on mobile, against 44.6% for Magento overall. The theme moved the rendering metrics and left the first byte alone. A store can run both: a Hyvä frontend for the browser side and a faster page build on the server.

How to improve TTFB on Shopify

To improve TTFB on Shopify, start with the theme’s Liquid code. Shopify renders Liquid on the server for every page request, and its developer docs say most of a storefront’s response time is Liquid rendering. Nested loops over products, variants or options are the most common cause, and Shopify Theme Inspector shows which lines are slow.

Shopify’s TTFB is good for most stores. In September 2026, 83.8% of Shopify sites had a good TTFB on mobile and 92.6% on desktop, so when a Shopify store fails the check, the theme is the first place to look.

Install the Shopify Theme Inspector for Chrome, a browser plugin that shows Liquid render profiling data as a flame graph for your own store or any store where you have collaborator access. Load the slow page and read the graph from the widest bars down. Shopify’s theme performance guidance names the patterns to look for: loops nested across products, variants or options, which grow quadratically with catalog size, iterating all variants of a product, which forces expensive database queries, and metafield access inside loops.

Hosting isn’t a lever here. Shopify runs the platform on a global CDN backed by Cloudflare, and theme assets get HTTP/3, Brotli and edge caching without any setup on your side. Redirects are still worth a check: apps that add their own redirect chains show up in the “Had redirects” line, and the curl command above puts a number on them. For the browser-side work that comes after the first byte, our guide to speed up a Shopify store covers apps, images and scripts.

Server response time on headless storefronts

On a headless storefront, TTFB depends on how the frontend server renders HTML. Cache rendered pages at the CDN edge, render pages that need no personalization ahead of time, stream server-rendered HTML so the first bytes leave early, and start API calls in parallel. Server-Timing headers show whether rendering or data fetching is the slow part.

In a headless setup the HTML comes from the frontend’s own server, a Node or edge runtime, which calls the commerce platform’s APIs and then renders the page. Server response time is rendering time plus API time, and the fixes follow from that split.

• Cache rendered HTML at the CDN edge with Cache-Control headers for pages that look the same to every shopper.
• Use static rendering for pages that need no personalization, so they are built ahead of time and served as files.
• Stream server-rendered HTML where the runtime supports it, so the first bytes leave before the whole page is ready. Google’s guide to optimizing TTFB covers both options.
• Start API requests in parallel. In Next.js, for example, one slow data request blocks the whole route, so start the requests together and await them with Promise.all.

Add a Server-Timing header with ssr and api or db entries so you can see whether rendering or data fetching is the slow part. One caveat from web.dev: a server-rendered page can show a higher TTFB than a client-rendered one and still paint content sooner, with a better FCP and LCP, because the browser receives finished HTML. Judge a headless storefront on all three metrics, with TTFB as the one you fix first.

Frequently asked questions about reducing initial server response time

Is a 100 ms server response time good?

Yes. A 100 ms server response time is very fast. Lighthouse calculates its estimated savings against a 100 ms target and fails the check only above 600 ms, and Google rates field TTFB of 800 ms or less as good. The 200 ms target still quoted online comes from an old PageSpeed Insights rule written for API version 4, which Google shut down in May 2019.

Is TTFB a Core Web Vital?

No. The Core Web Vitals are Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, and web.dev says plainly that TTFB isn’t one of them. It still matters because it comes before every other loading metric. A slow first byte pushes back First Contentful Paint and LCP, which leaves less time for everything else on the page.

Why is my TTFB so high?

High TTFB usually comes from one of four places: redirects before the real page, a long network path to a distant server, a cache miss that makes the server build the page from scratch, or slow code and database queries during that build. Time the same URL with and without the cache to see which one applies to your store.

What does “Waiting (TTFB)” mean in Chrome DevTools?

Waiting (TTFB) is a row in the Timing tab of the Chrome DevTools Network panel. It covers the time when the browser is waiting for the first byte of the response, after the request is sent. DNS lookup and initial connection appear as separate rows above it, so a long Waiting (TTFB) bar points at the server.

Does a CDN reduce initial server response time?

Yes, in two ways. A CDN shortens DNS, connection and TLS time because shoppers connect to a nearby edge server, and when it caches HTML, those pages never wait on the origin. It can’t speed up pages it doesn’t cache, such as the cart, checkout or customer account pages, which still depend on how fast the origin server builds them.

Why does PageSpeed Insights show a different TTFB than my own test?

PageSpeed Insights shows two different measurements. The field TTFB comes from real Chrome users over the last 28 days and includes redirects, DNS and connection time. The Lighthouse lab check times one simulated load and leaves DNS and redirect time out. Your own test adds its own location, network and cache state, so the three numbers rarely match.

Where to start when you need to reduce initial server response time

To reduce initial server response time, measure before you fix. Check field TTFB in PageSpeed Insights, then time a cached and an uncached page with curl or DevTools to find the slow phase. Redirects and distance are quick wins. A slow page build needs work on caching, hosting, the database or the application code. On Magento, our list of causes of a slow Magento store helps match the symptom to the layer.

On Magento, the page build is the layer Expedio speeds up. On Shopify or a headless frontend, profile the Liquid or the renderer.

If one of your store's pages keeps failing the server response check, send it to scandiweb and we'll tell you which layer is slow.

Share on: