Response time

Both decide on money: one on conversion, the other on customer loyalty.

The figures are merciless. One additional second of loading time can noticeably push down the conversion rate, and an email that remains unanswered for three days has usually long since driven the customer to the competition. Response time is therefore not a technical footnote but a hard business metric.

Technical response time: server, time to first byte and loading time

When a browser requests a page, the request passes through several stations before the user sees anything. The technical response time can be broken down into sections, and only those who know which section is stuck can optimise in a targeted way, instead of blindly wanting to "make the page faster".

LCP and INP belong to Google's Core Web Vitals and feed directly into rankings. Google documents the official thresholds and measurement methods on web.dev: Web Vitals. In plain language: a slow response time costs you not only conversions at the checkout but also visibility in organic search. Punished twice.

What drives up server response time

In a Shopware shop, the usual suspects are quickly named: uncached pages that are freshly calculated from the database on every call; unoptimised database queries that become slower as the catalogue grows; badly programmed or outdated plugins that hook into every request; and missing or incorrectly configured caching layers. A shop that ran briskly with 200 products can become sluggish with 20,000 products if nobody has made the caching grow with it.

The most effective levers are usually unspectacular: HTTP caching and an upstream reverse proxy or CDN layer, so that not every call goes all the way through to the database. Image compression and modern formats, because images often make up the bulk of the data transferred. And the honest clear-out of plugins that eat up more performance than they deliver in benefit.

Caching: the biggest lever for technical response time

If a single factor decides on a shop's server response time, it is caching. Without a cache, the server has to rebuild every page on every call: fetch data from the database, render templates, calculate prices and availability. That costs the same work for every single visitor. With a cache, the result is calculated once and then delivered to many visitors: the difference between a workshop and an assembly line.

In a Shopware shop, several cache levels interlock. The HTTP cache delivers finished pages without troubling the shop at all. An upstream reverse proxy or a content delivery network serves visitors from a server near them and relieves your origin server. Object and database caches hold frequently used intermediate results. Only the interplay of these levels brings the response time down permanently.

The flip side: caching makes things fast but also potentially out of date. If a price changes but the cache still delivers the old one, you have a new problem. Clean cache invalidation, i.e. the targeted discarding of outdated content, is therefore the discipline that can turn caching from a performance gain into a constant annoyance if it is neglected.

Communicative response time: when the customer is waiting for you

The second meaning concerns customer service. Here the response time measures how long a customer waits for a reaction: to an email, a chat message, an enquiry via the contact form or a comment on social media. And here expectations differ brutally depending on the channel.

• Live chat: expectation in the range of seconds to a few minutes. Anyone who offers a chat and then does not answer for ten minutes would have been better off leaving the chat out.
• Social media: customers often expect a reaction within an hour, especially for complaints that are publicly visible.
• Email: a reply on the same working day counts as good, within 24 hours as acceptable.
• Phone: the expectation is immediate; nobody wants to languish in a queue.

The distinction between first response time (time until the first reaction) and resolution time (time until the final solution) is important. A quick first reply ("We are on it and will get back to you with a solution by tomorrow") often reassures the customer, even if the actual solution takes longer. The worst thing is radio silence.

Managing response time as a service KPI

Anyone who takes response time in service seriously defines service level targets and measures them. A helpdesk system automatically logs when a ticket came in and when it was answered. From this data, the average response time and, more meaningfully, the response time at the 90th percentile can be determined. The average conceals the outliers; the percentile shows how long the unluckiest ten per cent of your customers actually wait.

A pointed truth from practice: an accessible service with an honest acknowledgement of receipt beats a perfect but slow one. Customers are more forgiving of waiting time when they know that their enquiry has arrived and is being dealt with.

A concrete practical example

A Shopware shop for pet supplies measures two problems at the same time. First: the product pages have a TTFB of 1.2 seconds, far too high. An analysis shows that product caching is being bypassed by a review plugin that recalculates all reviews live on every page call. After switching to cached review snapshots, the TTFB falls to 280 milliseconds. The consequence: LCP slips below the 2.5-second threshold, and the conversion rate on the product pages rises measurably because fewer users bounce while the page is loading.

Second: in customer service, the average email response time is 38 hours, and the 90th percentile even more than three days. The shop introduces an automatic acknowledgement of receipt with a realistic processing estimate, prioritises tickets by urgency and defines an internal target of "first reply within 8 working hours". The average response time falls to around 6 hours, and the rate of follow-up enquiries ("Did you get my email?") collapses, because the acknowledgement removes the uncertainty.

Together, the two measures cost hardly any budget, just attention to the right metrics. That is exactly the point: response time is rarely a money problem and almost always a problem of measurement and prioritisation.

Why response time has a direct impact on revenue

The link between response time and money is not a supposition but well documented. For technical response time: with every additional second of loading time, the bounce rate rises and the conversion rate falls. The effect is particularly pronounced on mobile devices, because patience on a smartphone is even lower than on a desktop. So anyone who gets half of their traffic via mobile devices, which applies to most shops, is optimising the biggest lever with mobile response time.

For communicative response time, the effect is more indirect but just as real. Fast reactions in service lower the returns rate, because customers with questions before the purchase get answers instead of sending goods back in frustration. They increase the repurchase rate, because a customer who feels well looked after comes back. And they protect your reputation: a publicly unanswered complaint on social media or in a review has an effect on every potential new customer who reads it.

Measure response time instead of estimating it

Both types of response time can be measured cleanly, and you should do so. For the technical side, you combine lab data (synthetic tests from a controlled environment, for example via Lighthouse) with field data (real measurements from your users' browsers, for example via the Chrome User Experience Report dataset). Lab data shows you what is theoretically possible; field data shows what your customers really experience. Never rely on the lab alone.

For the communicative side, every decent helpdesk or ticket system supplies the necessary figures automatically: first response time and resolution time, broken down by channel and time of day. It is important that you look at these figures regularly and not just once a quarter. A response time that nobody measures deteriorates gradually until the complaints come in.

Common mistakes

The first mistake is to keep only one of the two response time concepts in view. A shop with a lightning-fast site but a three-day service response time loses out just as much as the other way round. The second mistake is to test technical response time only in your own office with fast internet; your customers are sitting on a smartphone on a mobile network, not on fibre in the office. Real field measurements from actual user traffic beat any lab test.

The third mistake is to take averages as the truth. An average response time of "2 seconds" sounds acceptable, until you notice that every tenth call takes eight seconds and it is exactly these users who bounce. Measure in percentiles, not averages, and you will see the reality of your customers instead of a flattering figure.

Managing expectations beats blind acceleration

One last, often forgotten lever: you do not always have to get faster; sometimes it is enough to manage expectations. For technical response time, this means giving users feedback that something is happening: a skeleton screen, a loading indicator, a page frame that is visible immediately while the rest loads. Perceived speed is not the same as measured speed, and for the customer it is the perceived speed that counts.

The same principle applies even more strongly to communicative response time. A clear statement ("We will reply within 24 hours") and keeping to it works better than a vague promise of instant service that you cannot keep. A customer who knows when to expect a reply waits patiently. A customer who is left in the dark writes the next, irritated message after two hours and then gives one star less.

In the end, response time is a promise: you tell the customer how seriously you take them, through the speed of your site and through the speed of your reaction. Both are measurable, both can be optimised, and both pay directly into revenue and loyalty.