Codewerk.
Get a quote
Home/Blog/TTFB: what actually makes your shop slow to respond

TTFB: what actually makes your shop slow to respond

Time to First Byte is the number your CDN cannot fake. Five causes, in the order we check them on real Shopware shops.

Photo: free stock photography (Unsplash licence) — see imprint

What TTFB really measures

TTFB is the time from request to the first byte of the response: DNS, TLS, network, and — the part you control — your server thinking. If TTFB is 900ms, no amount of image optimisation will save your Core Web Vitals.

Cause one: no HTTP cache

An uncached Shopware category page rebuilds itself from the database on every hit. Varnish or the built-in HTTP cache turns that into a memory read. This is almost always the single biggest win, and it is a configuration change, not a rewrite.

Cause two: N+1 queries in a plugin

One plugin that loads the manufacturer inside a product loop turns 1 query into 51. Turn on the query profiler on staging with a real catalogue — the culprit is usually obvious within ten minutes and it is usually not the core.

Cause three to five

Missing database indexes on custom fields you filter by. A synchronous call to the ERP during page render — never do this. And a hosting plan whose CPU is shared with 200 other shops at 6 p.m. Check them in that order.

Key takeaways
  • Fix TTFB before touching images or JavaScript.
  • HTTP cache is the biggest single win.
  • Never call an ERP synchronously during render.

Frequently asked questions

We will not invent a number for you. Google publishes guidance on TTFB — check it in the current documentation rather than trusting a figure from an article. What matters more is the split: if your server is doing most of the thinking, that part is yours and it is fixable. At 900ms, no amount of image work will rescue your Core Web Vitals.

Partly. A CDN shortens the network distance and serves static files well. It cannot stop an uncached category page from rebuilding itself out of the database on every single hit — that time is your server thinking, and the CDN sits in front of it waiting like everybody else. Cache the HTML first. Then a CDN is worth having.

Check in this order: is the HTTP cache actually on, does a plugin fire N+1 queries, are there indexes on the custom fields you filter by, is anything calling the ERP synchronously during render. Only then blame the plan whose CPU is shared with two hundred other shops at 6 p.m. Most teams start at the end of that list and buy a bigger server.

Turning on the HTTP cache. An uncached Shopware category page reassembles itself from the database for every visitor; Varnish or the built-in cache turns that into a memory read. It is almost always the biggest single win, and it is a configuration change rather than a rewrite — which is why it is annoying how often we find it switched off.

We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.

Talk to an engineer

// Keep reading

Related articles