In btlabs Core, a website response time of under 200 ms refers to the Time to First Byte (TTFB) : the time from the start of navigation until the arrival of the first response byte. This value does not describe the total loading time or the Lighthouse score. Without raw data on the test URL, test region, cache state, median, and p95, however, "under 200 ms" is not a generally verifiable performance guarantee.
This distinction is important. In over 20 years of web development, I've often seen SMEs present a single, impressive metric without explaining the measurement or the test conditions. A top score might be accurate, but it still reveals little about the website's everyday responsiveness.
A reliable statement about website speed requires a clear metric, an open measurement protocol, and results that can be reproduced under the same conditions.
What website response time actually measures
According to web.dev, the Time to First Byte (TTFB) measures the time from the start of navigation until the arrival of the first response byte. Several phases are incorporated into the TTFB:
- possible redirects,
- the start of a service worker, if one exists,
- DNS resolution,
- the establishment of the connection and the TLS negotiation,
- the transmission of the request and the processing up to the first response byte.
TTFB is often shortened to the server response time of a website. This term is incomplete because it also includes network phases before the actual processing on the server. Server location, routing, and distance between the test region and the data center affect the website response time, as does the application itself.
In this article, "response time" therefore consistently refers to TTFB (Time To First By). Website response time after a click within an already loaded user interface is a different metric.
Correctly classifying website response times below 200 ms
Web.dev cites a TTFB of no more than 0,8 seconds (800 ms) as a rough guideline for good performance. Values above 1,8 seconds are considered poor; anything in between is considered in need of improvement. However, TTFB is not a Core Web Vital. Therefore, these thresholds serve as a guideline and not as the sole basis for evaluating user experience.
A measured website response time of under 200 ms would be a very fast, standalone result. However, this does not guarantee that every URL, every request, and every region will consistently remain below 200 ms. Dynamic features, personalized content, a cache miss, or high server load can all lead to different results.
For btlabs Core, the provided documentation does not include a complete raw data set with test date, individual measurements, median, and p95. Therefore, "under 200 ms" is presented here as a performance specification to be verified and not as a definitively documented measurement result. A reliable verification requires the publication of a complete measurement series.
TTFB, load time, LCP, and Lighthouse score differentiate
TTFB: When does the response begin?
TTFB ends as soon as the first response byte arrives. At this point, images, fonts, stylesheets, and JavaScript files may still be missing. A low TTFB indicates a good starting point, but it doesn't guarantee that the entire page is already visible or usable.
Total charging time: When does the charging process end?
Total load time is not a single, universally defined performance metric. Depending on the tool, it can refer to the loading event itself or to a later point in time with low network activity. Media, fonts, scripts, and external services can increase the loading time even after the first HTML byte has arrived.
Largest Contentful Paint: When does the largest visible content appear?
According to web.dev, the Largest Contentful Paint (LCP) measures the rendering time of the largest visible image, text block, or video in the display area. The LCP is one of the Core Web Vitals and is calculated relative to the beginning of the navigation.
TTFB and LCP measure different times but are linked: delays until the first byte is reached are part of the overall LCP time. A slow TTFB can degrade the LCP. Conversely, a fast TTFB does not guarantee good LCP if, for example, the central cover image is too large or is requested late.
Lighthouse Score: How is overall performance assessed?
According to Chrome for Developers, the Lighthouse performance score is a weighted average of several metric scores. The documented scoring model incorporates metrics such as First Contentful Paint, Speed Index, Largest Contentful Paint, Total Blocking Time, and Cumulative Layout Shift. The weightings may change with new Lighthouse versions.
The Lighthouse score is therefore not synonymous with a website's server response time. A website can have a fast TTFB (Time To First By) and still a mediocre Lighthouse score. Conversely, a good Lighthouse lab test can mask regional or sporadic weaknesses in the website's response time.
Measurement protocol for a reproducible measurement
A reproducible measurement requires identical conditions. For btlabs Core and any other website, the measurement protocol should contain at least the following information:
- Test object: full domain and specific URL,
- Page type: Homepage, content page, search page or dynamic function,
- Answer: HTTP status and possible redirect chain,
- Time: Date, time and time zone of the measurement series,
- Tool: Name and version of the measuring tool,
- Test region: for example Northern Italy or Central Europe,
- Connection: defined network profile,
- Cache status: Cold cache and warm cache are separate.
- Sample: Number of warm-up runs and evaluated measurements,
- Results: Individual values, median and p95,
- Context: Server location, CDN usage, and dynamic features.
To demonstrate a website response time of under 200 ms, a fixed public btlabs core URL must be defined. Additionally, several typical content pages should be included in the measurement. Publishing only the fastest URL would not provide a representative picture of the system.
Measure cold cache and warm cache separately
A cold cache means that the requested response cannot yet be delivered from a prepared cache. The application may need to read and reprocess content from a data source. This typically results in a cache miss.
With a warm cache, the answer, or a significant part of it, is already in the cache. A cache hit can significantly reduce the TTFB (time to first find). Both states answer different questions:
- The cold cache test shows performance when content needs to be reprocessed.
- The warm cache test shows the delivery of frequently requested content.
- The ratio of cache hit to cache miss shows how often users benefit from the cached response.
Mixing cold cache and warm cache in a single average makes classification difficult. A transparent report presents both measurement series separately and documents how each state was achieved.
Median and p95 instead of individual best values
The median is the middle value of a sorted series of measurements: half the measurements are below it, the other half above it. The median is less sensitive to individual outliers than an arithmetic mean.
The p95 value represents the 95th percentile. 95 percent of measurements are equally fast or faster; five percent are faster. The p95 shows how website response time behaves under less favorable, but regularly occurring, conditions.
For an SME, both metrics are relevant. The median describes the typical case. The p95 indicates whether a system remains stable or if some visitors experience significantly longer wait times. A single value below 200 ms only proves that this speed was achieved once. Only the median and p95 together show how repeatable the performance is.
Which architecture supports a fast TTFB
A fast website isn't created through a single optimization. What's crucial is an architecture that avoids unnecessary processing and transmission.
- Slim frontend: Less unnecessary code reduces data volume and processing in the browser.
- Server-side processing: Pre-prepared content can be delivered earlier than content that is created entirely in the browser.
- Targeted caching: Recurring requests do not need to be processed anew each time.
- Short forwarding chains: Each additional redirect creates another network step.
- Optimized media delivery: Suitable formats and sizes primarily improve LCP and full loading time.
- Few third-party scripts: External services increase dependencies and can delay rendering and interactivity.
btlabs Core is designed as a central digital foundation from which websites and other output channels access a common content base. I explain the technical background in the article about the architecture of btlabs Core . A suitable architecture creates good conditions, but it doesn't replace measurements under real-world conditions.
What influences website response time
Even with unchanged code, a website's server response time can fluctuate. Typical causes include:
- the distance between the test region and the server location,
- the network operator's routing,
- the current utilization of hosting, database or application,
- a cache hit or cache miss
- personalized content and registered users,
- dynamic search, booking or shop functions,
- external interfaces and third-party scripts,
- an unstable local network connection.
For companies in South Tyrol, measurements from a relevant Central European test region are advisable. If a website targets people in Italy and the DACH region (Germany, Austria, and Switzerland), additional measurement series should be conducted from both target areas. A test from a data center close to the server does not reliably reflect the experience of users located further away.
Here's how to check website response time
For a reliable comparison, you primarily need a standardized approach:
- Choose three to five representative public URLs.
- Note the HTTP status and redirects of each URL.
- Define a measuring tool and a fixed test region.
- Perform several warm-up runs that are not included in the evaluation.
- Then, record at least 20 measurements per URL and cache state.
- Keep cold cache and warm cache strictly separate.
- Store the individual values and calculate the median and p95.
- Repeat the measurement at a second time.
- Compare systems only under the same test conditions.
Next, check not only the TTFB (Time To First By) but also the overall website performance . Perceived quality also includes visible content, visual stability, interactivity, and clear user navigation.
After the launch, a Performance Budget for SME websites Limits are set for images, scripts, and key performance indicators. This ensures that speed remains an ongoing quality requirement.
Why this post does not contain a before-and-after comparison
A before-and-after comparison is only meaningful if both systems are measured with comparable content and functions, the same test region, the same tool, and separate cache states. Such uniformly collected comparative data is not available in the provided documentation.
Therefore, I avoid using constructed or methodologically inconsistent comparative values. When working with SMEs, a clearly identified missing data point is more helpful than an impressive figure without a verifiable basis.
What data must a btlabs Core measurement report contain?
For "under 200 ms" to be considered a documented website response time, the measurement report must disclose the following data:
- tested domain and specific test URLs,
- Date and time of measurement,
- Tool, version and test region,
- Server location and relevant infrastructure,
- Number of warm-up runs and measurements,
- Cold cache and warm cache results,
- Median and p95 per URL and cache state,
- Raw values or an exportable measurement report,
- Outliers with a plausible classification.
Editorial status: March 25, 2026. Infrastructure, content, and external services are subject to change. Therefore, a published measurement series requires an update date and should be repeated after significant changes.
Questions and answers about website response time
What is a good TTFB value for a website?
Web.dev suggests a maximum of 800 ms as a rough guideline for a good TTFB (Time To First Byte). For a specific SME project, I also consider the median, p95, target region, and page type, because a single threshold doesn't fully represent the user experience.
Does a TTFB of less than 200 ms mean that the website loads in 200 ms?
No. Under 200 ms only means that the first response byte arrived within that timeframe. Images, fonts, JavaScript, and visible content can still be loaded and rendered afterward.
Why is the warm cache faster than the cold cache?
With a warm cache, pre-prepared data or responses can be delivered directly, often resulting in a cache hit. With a cold cache, the system may need to regenerate the content. Therefore, both states must be measured separately.
Why does Lighthouse show a different value than a TTFB test?
Lighthouse evaluates multiple weighted performance metrics under defined laboratory conditions. In contrast, a TTFB test only considers the time until the first response byte. Both measurements answer different questions.
Is TTFB a Core Web Vital?
No, TTFB is not one of the Core Web Vitals. However, this metric influences subsequent loading phases and can therefore delay the Largest Contentful Paint (LCP).
Should I measure the TTFB on my mobile device or on my desktop?
For comparable measurement series, you should use fixed and documented conditions. Supplementary mobile tests are useful because mobile network coverage, less powerful devices, and fluctuating network quality affect the real user experience.
How many measurements do I need?
A single test is insufficient for a reliable conclusion. For a pragmatic SME check, I recommend at least 20 evaluated measurements per URL and cache state after several warm-up runs, as well as the evaluation of the median and p95.
Can I directly compare two website systems?
Yes, provided the content and functions are comparable and the test region, tool, number of measurements, and cache states are the same. Comparing a simple homepage with a personalized shop page would not be methodologically sound.
Does btlabs Core guarantee a website response time of under 200 ms at all times?
No. A single measurement cannot provide a lasting guarantee for every URL, region, and function. Such a statement can only be considered a substantiated result with a complete measurement protocol, raw data, median, and p95 value.
Conclusion: Website response time can be assessed transparently.
A low TTFB (Time To First By) is valuable because subsequent loading phases can only proceed after the response has begun. However, website response time is only one aspect of website quality. For your business, stable delivery, quickly loading content, intuitive user navigation, and a system that is manageable in the long term are also crucial.
Therefore, with btlabs Core, "under 200 ms" should not be presented as an isolated best value. A documented measurement series is necessary, including relevant test regions, separate cold and warm cache, median, p95, and accessible raw data. This transforms a performance specification into a verifiable measurement.
