What is a good TTFB for ecommerce?

Although this question focuses on one specific type of site, it remains very broad. That's because no two audiences or technology stacks are alike. While TTFB marks the start of page load, it may not correlate strongly with user experience.

TTFB impacts other metrics

Make no mistake: poor TTFB will delay other related metrics such as First Contentful Paint (FCP) and Largest Contentful Paint (LCP).

An important nuance to note is that users do not perceive TTFB directly, as there are no visual changes at this stage, unlike with FCP and LCP:

First Contentful Paint

FCP indicates the point when the screen is no longer blank.

For instance, numerous render-blocking resources and A/B tests can delay this critical moment of initial user engagement.

Largest Contentful Paint

LCP measures when the largest element within the viewport is rendered.

Homepages and product pages often feature a prominent image above the fold, making LCP more challenging for these pages than for others.

Stack, platform, redirect time, and your audience

Metrics like FCP and LCP are typically affected by TTFB regressions or structural TTFB challenges. However, noticeable delays in FCP and LCP can occur even with a healthy TTFB.

CSR vs SSR

This might happen with Single Page Applications (SPAs) lacking a Server Side Rendering (SSR) strategy, where TTFB is expected to be more healthy due to less initial server work. Yet, within SPAs, FCP and LCP often worsen as rendering key page elements requires more browser processing.

Your e-commerce platform

TTFB depends on more than just hosting. A demanding platform requires better hosting specs, but the platform itself significantly influences server response times and, consequently, TTFB.

For example, managing WooCommerce and Magento platforms can be more challenging than Shopify, as evidenced by public data.

Following that link, you can apply TTFB filters to see data specifically or view the summarized information I've included in the charts and tables below.

It's important to note that rather than providing raw TTFB data at the 75th percentile, the CWV Technology report shows what percentage of shops on each platform achieve a TTFB below 800ms. This is still conveying insights into TTFB difficulty per platform though.

While Shopify, as a SaaS platform, eliminates server configuration challenges, it does highlight that the choice of platform is crucial when determining a good TTFB for e-commerce.

For shops on WooCommerce or Magento, prioritizing FCP optimization -by managing render-blocking resources and limiting client-side A/B tests- becomes even more essential alongside TTFB efforts.

TTFB is more than server response time

"Reduce server response times" is a common recommendation seen when running a Lighthouse test, but it's crucial to understand that server response time is not synonymous with TTFB. For example, TTFB also includes server-side redirects and DNS lookup times.

So, when determining a good TTFB, should we exclude navigations originating from ads? Because ads typically include measurable redirect delays that can easily be measured to end up affecting the overall TTFB.

International audience

If your e-commerce site targets a specific region like Belgium or the Netherlands, your TTFB challenges may be less severe than those of a site attracting an international audience. Another important difference you might want to take into account.

Google's perspective on optimal TTFB

Google's recommended server response times have varied. Deprecated documents suggest 200ms, while more recent TTFB guidelines on web.dev suggest 800ms, previously revised from 500ms.

TTFB is experimental

Google still considers the TTFB metric experimental, not accounting for navigations served from the bfcache via back/forward button attempts. However, TTFB has been well-defined and used longer than any Core Web Vital metric. It should be noted that this is the only thing that is keeping TTFB from becoming stable. But it does add another nuance that one could take into account when trying to answer our main question.

Other considerations

The discussion doesn't stop there. We must also consider:

• Page hits actively served from a server (possibly via a CDN)
• Instant client-side page hits from the bfcache (as illustrated above)

And additionally decide whether to:

• Ignore server-side cache hits
• Combine them with caching statuses like HIT, DYNAMIC, and MISS.

Setting different TTFB goals

Ideally and based on the nuances that are explained above, you would want to set goals for different TTFB categories:

• The proportion of back/forward attempts not served by the browser itself
• The amount that could be served from server-side cache (learn more about improving your CDN cache hit ratio)
• The TTFB for pages with caching status HIT
• The TTFB for all other page hits

These considerations are critical as you might expect different cache hit ratios for different page types, such as the homepage versus product pages, where the latter may involve more server-side processing and might typically deal with a lower cache hit ratio.

Percentiles

Discussing percentiles adds another layer to understanding TTFB answering our question. For instance, while Google uses the 75th percentile for its metrics, aiming for a TTFB of 800ms at higher percentiles, such as the 80th, 85th, or 90th, might be aspirational.

TTFB and impact on revenue

To directly address the question, we should consider from what TTFB threshold conversion rates begin to suffer. Once determined, this also informs the ideal FCP, as FCP is where users first notice visual changes. While TTFB is crucial for technical stakeholders, users perceive nothing at this stage.

Nevertheless, if pressed for a specific number, I'd align with Google's CrUX thresholds and suggest:

• A TTFB of 600 to 800ms is good, especially for international shops on demanding platforms. This is achievable by larger e-commerce sites, as shown when comparing their Core Web Vitals data.
• A TTFB of 400 to 600ms is very good but less realistic at higher percentiles where the cache hit ratio tends to decrease.
• For e-commerce, anything below 400ms is impressive.