Website Speed Test Metrics: What the Numbers Actually Mean

Why one load-time number is not enough

Most speed test reports return more numbers than anyone reads. People glance at a single total load time, compare it against a figure they half-remember, and close the tab. That habit throws away the useful part. Individual website speed test metrics tell you where the time went, and that is what decides whether the next investigation belongs in your server configuration, your CDN, your front-end code, or somewhere else entirely.

As part of Latixo's measurement methodology, this page starts with the measurements Latixo V1.10.2 currently reports, then puts them in context alongside standardized browser metrics such as FCP, LCP, CLS and INP. Those standardized metrics are important for web performance analysis, but they should not be confused with fields that the current Latixo public result page does not yet expose.

Lab measurements and field data answer different questions

A Latixo test runs your page in a real Chromium browser on a Browser Node in a region you choose. That is a lab measurement: controlled conditions, one browser profile, one location, one moment in time, repeatable on demand. Latixo currently offers both Desktop and simulated Mobile test profiles; the Mobile profile is browser-based emulation rather than a physical phone.

Field data comes from real visitors on their own devices and networks, aggregated across actual page views. The Chrome User Experience Report (CrUX) and real-user monitoring systems belong in this category.

The distinction matters because the two are used for different jobs. Field data tells you what users actually experienced across real traffic. Lab data gives you a controlled run you can repeat while changing one variable at a time. A clean lab run cannot prove that every visitor is getting a good experience, and field data often needs additional diagnostics before it reveals the resource or stage responsible for a problem.

When field numbers look poor and a lab test looks clean, the gap can come from device class, network quality, geography, page mix, cache state, personalization or third-party behavior. That gap is information, not automatically a contradiction.

What Latixo V1.10.2 currently reports

Time to First Byte (TTFB)

Latixo measures TTFB from the start of the navigation to responseStart in Chromium's Navigation Timing data. In this definition, TTFB is a composite navigation measurement: it can contain redirect delay, connection setup, TLS negotiation, request travel time, server work and the return trip of the first response byte.

That composition is why TTFB gets misread so often. A high TTFB is not proof of a slow application server, and a low TTFB does not certify an efficient backend. It is a useful symptom, but it does not by itself isolate the root cause.

Total load time

The current Latixo public metric called Total load time is based on Chromium's loadEventEnd. It tells you when the document's load event completed in that run. It is not a Core Web Vital and it should not be treated as the moment when every asynchronous task on a modern site has permanently stopped.

After navigation, the Browser Node may continue briefly for network-idle settling and capture finalization so that the screenshot and loading replay represent the loaded state. That settling period is part of the test process, but it is not a separate public “Complete” timing metric in V1.10.2.

Page weight and request count

Page weight is the encoded response data observed by Chromium during the capture window. Request count is the number of browser network requests observed during the run. Together they describe how much traffic the page generated, but neither metric is a quality score on its own. A heavier page can still feel fast when critical content is prioritized well, while a smaller page can feel slow if its critical path is blocked.

HTTP status, protocol and content type

The result also shows the main document's HTTP status, negotiated protocol information and content type. These values are useful sanity checks. A performance report is meaningless if the browser actually received an error document, an unexpected redirect destination or the wrong content type.

Screenshot, loading replay and recommendation checks

The final screenshot and loading replay answer a different question from timing numbers: what did the browser actually see? A consent layer covering the page, a missing font, an empty application shell or a visually broken component can coexist with respectable timing values.

Latixo also uses selected main-document signals — including response compression and caching headers — when generating recommendation checks. The current public result should not be described as a complete raw-header inspector or a full per-request waterfall.

Connection-phase metrics: DNS, TCP and TLS

DNS lookup, TCP connection setup and TLS negotiation all happen before application response bytes can arrive. They are especially sensitive to network path, connection reuse and the distance between the client, edge network and origin.

Latixo V1.10.2 does not currently expose these three phases as separate public result values. They are still useful concepts when you investigate a high TTFB with another tool or with lower-level browser/network instrumentation.

DNS lookup time

DNS lookup time is the interval spent resolving a hostname to an address. Resolver behavior, authoritative DNS placement, TTLs, caching and network conditions can all affect it. A fresh browser context does not guarantee that every DNS layer is cold, so one synthetic lookup should not be described as a universal “cold-cache upper bound.”

Also count how many distinct hostnames the page depends on. Fonts, analytics, tag managers, image hosts and APIs may require additional DNS work and connections unless caching, connection reuse or protocol-level coalescing avoids it.

TCP connection and TLS negotiation

New connections incur network round trips. Physical distance and routing therefore matter, although modern connection reuse, HTTP/2 or HTTP/3, TLS session resumption and edge termination can change the cost substantially. TLS 1.3 reduces handshake latency compared with a full TLS 1.2 handshake, and resumption can reduce repeat-connection cost further.

If the same origin behaves differently from Tokyo and Nuremberg, the difference may come from distance, routing, edge selection, cache state or region-specific infrastructure. You cannot assume the application server itself changed simply because the total waiting time changed.

Rendering metrics: FCP, LCP and CLS

FCP, LCP and CLS are standardized browser performance metrics used widely in performance tooling. They are important for understanding what users see during rendering. They are included here for interpretation, but they are not public result fields in Latixo V1.10.2.

First Contentful Paint (FCP)

FCP marks the first time the browser renders page content such as text, an image, an SVG element or a non-white canvas. It inherits everything upstream of rendering: redirects, connection setup and TTFB can all push FCP later. After the response begins, render-blocking CSS, synchronous scripts, font behavior and client-side rendering work can add further delay.

Largest Contentful Paint (LCP)

LCP reports when the largest qualifying image, text block or video element visible in the viewport is rendered. It is a Core Web Vital and is intended to approximate when the page's main visible content has appeared.

A large gap between FCP and LCP often points toward delayed discovery or low priority of the LCP resource, a lazily loaded above-the-fold image, JavaScript-inserted content, web-font delay, main-thread work or other element-render delay. It does not prove that the LCP element alone is the root cause, so the resource timeline and rendering work still matter.

Cumulative Layout Shift (CLS)

CLS measures visual stability by scoring unexpected layout shifts. Common causes include images or embeds without reserved dimensions, dynamically injected content, ads or widgets that resize, and font changes that alter text geometry.

Lab tools that only load a page typically observe only load-time shifts. Field CLS can include unexpected shifts later in the page lifecycle, such as lazy content that moves the layout during scrolling. Layout changes that follow a qualifying user input closely are generally excluded from CLS because they are expected responses to that interaction.

Interaction to Next Paint (INP)

INP is the Core Web Vital for interaction responsiveness. It depends on actual interactions such as clicks, taps and key presses. Field data is the best source because real users choose when and where to interact. Lab investigation can reproduce slow interactions when a test includes realistic interaction flows, but a load-only synthetic run cannot meaningfully assess INP.

For Core Web Vitals, the commonly referenced “good” field thresholds are LCP at 2.5 seconds or less, CLS at 0.1 or less and INP at 200 milliseconds or less, assessed at the 75th percentile of page visits. TTFB is not a Core Web Vital; web.dev gives 0.8 seconds or less as a rough target rather than an official Core Web Vitals pass/fail threshold. See Core Web Vitals threshold guidance and TTFB guidance.

Document lifecycle: DOMContentLoaded, load and post-load activity

DOMContentLoaded fires after the HTML document has been parsed and deferred/module scripts that participate in that phase have executed. It does not wait for every image, iframe or asynchronously loaded resource, and it does not mean the page is visually complete or fully usable.

The window load event occurs later, after the document and its load-blocking dependent resources have completed. Chromium's Navigation Timing API exposes timestamps for both lifecycle points. Latixo V1.10.2 uses loadEventEnd for its visible Total load time metric.

Modern pages frequently continue doing work after load: analytics beacons, polling, lazy modules, API calls and third-party widgets can all remain active. That is why “finished loading” is a fuzzy concept and why a long technical load time does not automatically mean the page felt slow above the fold. For a standards-oriented view of these timestamps, see MDN's navigation and resource timing guide.

Why the same page reports different results from different regions

Latixo currently runs LIVE Browser Nodes in Virginia, Seattle, Nuremberg, Tokyo, Singapore, São Paulo and Beijing. Testing one URL from several of them changes the browser's network vantage point while keeping the selected Latixo test profile controlled.

Multi-region testing is useful because network-dependent delay changes with geography, but the interpretation must stay cautious. A CDN can route different regions to different edges, cache state can differ, DNS can resolve differently, and some applications use geo-distributed backends. That means you cannot reliably calculate “server processing time” by subtracting one region from another using TTFB alone.

What repeated regional tests can do is reveal a pattern. If nearby regions are consistently faster than distant ones, network distance or edge placement becomes more plausible. If one region is unexpectedly different from others at similar distances, investigate routing, cache behavior, DNS answers or region-specific services. Repeat the comparison before treating a small difference as meaningful.

A node is one vantage point with one network path, not a representative sample of every visitor in that country. A test from Tokyo describes what that Latixo Browser Node encountered during that run. It does not describe every mobile user in Japan.

Read the metrics as a set, not as isolated scores

Individual numbers rarely identify a cause. Relationships between them are more useful.

If TTFB is high, investigate redirects, geography, connection setup, edge/cache behavior and backend generation before blaming one layer. If TTFB is healthy but the browser still takes a long time to reach loadEventEnd, the remaining work is in resource loading and page execution rather than the initial response. If page weight and request count rise sharply after a deployment, compare the screenshot and replay to see whether the added transfer created visible value or simply added background work.

When you also have FCP and LCP from another standards-based tool, a large TTFB-to-FCP gap points toward render-path work after the first byte, while a large FCP-to-LCP gap points toward main-content discovery, loading, priority or render delay. High CLS is a layout-stability problem, not simply a “speed” problem.

Mistakes that make performance numbers misleading

Treating a single run as truth is the most frequent one. Cache state, node load, upstream routing and third-party variability can move results between runs. A change smaller than the natural spread of repeated tests is not strong evidence that a deployment helped or hurt.

Mixing test profiles causes similar confusion. Desktop and simulated Mobile profiles use different viewport and execution conditions, so comparing across them measures both the page and the profile difference. The same applies to comparing your result from one city with a competitor's result from another.

The broader trap is optimizing a reported number instead of the experience. Metrics are proxies. Before acting on a report, check the screenshot and loading replay to confirm that the number corresponds to something a visitor would actually notice.