Guide to Response Time Monitoring
Author<br>Rudi Kraeher
Published<br>Jul 7, 2026
Reading time<br>21 min read
Categories<br>Guides (11)<br>Updates (5)
On this page<br>As computing technology continually advances, the concerns of the humans who use it remain stable.<br>People want things to be fast, reliable, and easy to use. People also want their technology to give them agency<br>so that they feel in control.
Internet technology has been developed to help us distribute information, and access to that information<br>should not be impeded by confusing language and interfaces or sluggish response times.
Although network speeds and computing power have improved, the psychological limits on response time are the<br>same ones researchers measured in the late 1960s and<br>Jakob Nielsen popularized in the 1990s:
0.1 seconds feels instantaneous
1 second is a noticeable delay, but thought stays on track and the user still feels in control
10 seconds is the limit of attention — beyond it, the mind drifts to other things
Tip<br>It’s easy to remember these thresholds as a triplet of 1s: 0.1 / 1 / 10.
These thresholds have been public knowledge for decades, yet most websites still do not manage to provide<br>the quality of experience that these limits define. In the HTTP Archive’s<br>2025 Web Almanac, only 48% of mobile sites<br>and 56% of desktop sites passed all three of Google’s Core Web Vitals, the closest thing the<br>modern web has to an agreed measure of those perception limits.
There are real technical constraints that make<br>achieving Nielsen’s response time limits a challenge. Even as tech has improved, so too have user expectations<br>for the richness of web content and interactions — median page weight<br>has grown nearly 6x on desktop since 2011 and over 13x on mobile — making a consistent, high quality experience<br>difficult to deliver in practice. If keeping a site fast were as simple as following a checklist of universal,<br>actionable bullet points, the numbers would look very different.
You will find plenty of online content with suggestions about what could be going wrong and how to<br>improve your response time. The truth is that there are too many technical factors for any general<br>list of issues and fixes to be useful. You have to get specific about your own system and use<br>measurements to narrow down the possibilities until you find the bottleneck. This is detective work:<br>measuring, comparing, and looking for patterns. Generic advice like “optimize your database queries”<br>doesn’t help you do it. What helps is knowing, from your own data, where in your stack the slowdowns<br>happen, under what conditions, and what you can realistically do about them. So this is not a<br>“how to fix latency” article, because no honest article can be.
What we can do here is give you a foundational understanding from which to build your optimization plan.<br>This article explains what response time is, how it is measured across the phases of a web request,<br>how to read and start analyzing the data your monitoring collects, and why automating that measurement is worth it.
What is response time?
Response time is the time between a client making a request to a service and receiving the full<br>response, usually measured in milliseconds (ms). For web technologies, it includes not only the time<br>the server needs to process the request but also the transmission time over the network. Together,<br>the initial connection, request, waiting, and content download phases make up<br>the total response time. We discuss each phase in detail below.
The response time measures the difference between two moments in the flow of data between client and server:
Start : the moment the client initiates the connection to the server
End : the moment the last bit of data is received from the server by the client
A lot of things can happen between those two moments and not every step will take equal time.<br>Before we get into the details of the full request cycle, we should first distinguish response time<br>from a similar set of concepts related to web performance: Google’s Core Web Vitals.
How does response time relate to Core Web Vitals?
Core Web Vitals and response time are both topics related to measuring and improving<br>site performance and user experiences on the web. However, there are important differences<br>in what they measure and how to use the metrics in managing and maintaining your site.<br>Where Nielsen’s thresholds describe pure human perception, Google’s Core Web Vitals balance those<br>limits against achievability,<br>setting targets that a realistic share of the web can actually meet.
Core Web Vitals
Core Web Vitals are three metrics Google uses to measure the quality of a page’s user experience:<br>Largest Contentful Paint (LCP), which tracks loading; Interaction to Next Paint (INP), which tracks<br>responsiveness to input; and Cumulative Layout Shift (CLS), which tracks visual stability. They are<br>measured from real users at the 75th percentile and are used as a search ranking signal. These are<br>frontend,...