Page Load Timings
Statalog automatically captures detailed page load timing data for every visitor session using the browser's Navigation Timing API. Rather than showing a single "load time" number, it breaks the load process into seven distinct phases — giving you the specificity needed to diagnose slowness accurately and fix it efficiently.
Why phases matter
A total load time of 3.2 seconds tells you that your page is slow. It does not tell you why. The difference between a page that is slow because of a distant DNS server and one that is slow because of a bloated JavaScript bundle is the difference between a CDN change and a refactoring effort. Phase-level data points you directly at the cause.
The seven timing phases
1. Network time
What it measures: The time spent establishing the network connection to your server before any data transfer begins. This encompasses DNS lookup (converting the domain name to an IP address), TCP handshake (establishing the connection), and SSL/TLS negotiation (for HTTPS connections).
What causes slowness: A slow DNS provider adds latency before anything else can happen. TCP round-trip time is largely a function of physical distance between the visitor and your server — a visitor in Sydney connecting to a server in New York will have a higher network time than one in New Jersey. SSL negotiation adds one or more additional round trips.
How to improve it: Use a fast DNS provider (Cloudflare, AWS Route 53). Move your server or use a CDN with edge nodes geographically close to your visitors. Enable TLS 1.3 and session resumption to reduce SSL handshake overhead.
2. Server time (TTFB)
What it measures: Time to First Byte — the time from the connection being established to the first byte of the HTML response arriving in the browser. This is your server's response time: the time spent executing application logic, querying databases, rendering templates, and assembling the HTTP response.
What causes slowness: Slow database queries, unoptimised application code, cold function starts in serverless environments, or simply underpowered hosting. TTFB is the most direct measure of your back-end performance.
How to improve it: Implement server-side response caching (full-page cache for static or semi-static pages, fragment caching for dynamic sections). Optimise slow database queries. Use a CDN that caches HTML at the edge for eligible pages. Consider upgrading hosting if baseline TTFB is consistently above 200–300ms.
3. Transfer time
What it measures: The time taken to download the HTML document from the first byte to the last byte. This begins where TTFB ends and ends when the full HTML response is received.
What causes slowness: Large HTML documents take longer to transfer. Slow network connections between visitor and server amplify this. Transfer time is usually small for typical HTML pages but can become significant for very large server-rendered HTML payloads or on slow mobile connections.
How to improve it: Enable gzip or Brotli compression on your server (typically reduces HTML size by 70–80%). Minimise HTML payload by removing unnecessary markup, comments, and inline content that could be loaded separately. A CDN improves transfer time by moving the serving point closer to the visitor.
4. DOM processing
What it measures: The time the browser spends parsing the received HTML and constructing the Document Object Model (DOM) tree. This phase begins after the HTML is fully received and ends when the DOM is built.
What causes slowness: Deeply nested HTML structures slow parsing. Synchronous <script> tags in the <head> block DOM construction while the script downloads and executes. Very large HTML documents with thousands of elements take longer to parse.
How to improve it: Move scripts to the bottom of <body>, or use async and defer attributes on script tags so they do not block HTML parsing. Reduce DOM complexity — large numbers of DOM nodes slow both parsing and subsequent rendering.
5. DOM completion (DOMContentLoaded)
What it measures: The time from navigation start to the DOMContentLoaded event, which fires when the initial HTML has been fully parsed and all synchronous scripts have executed, but before stylesheets, images, and other sub-resources have finished loading.
What causes slowness: Render-blocking CSS in the <head> (the browser waits for stylesheets before considering the DOM ready). Synchronous JavaScript that takes a long time to execute. Large numbers of synchronous resources.
How to improve it: Inline critical CSS and defer the loading of non-critical stylesheets. Minimise synchronous JavaScript execution in the critical path. Use rel="preload" for critical resources so they start downloading earlier.
6. On-load event
What it measures: The time from navigation start to the load event, which fires when the page and all dependent resources — images, stylesheets, scripts, fonts, iframes — have fully loaded.
What causes slowness: Large uncompressed images are the most common cause of slow load events. Many third-party scripts (chat widgets, analytics, ad tags, social embeds) each add network requests that must complete before load fires. Web fonts that are not preloaded add additional blocking time.
How to improve it: Compress and resize images appropriately (WebP/AVIF format, serve at display size rather than oversized). Lazy-load images below the fold. Audit third-party scripts and remove non-essential ones. Preload critical web fonts.
7. Total load time
What it measures: The total elapsed time from navigation start to the load event — the sum of all preceding phases. This is the headline performance number and the figure most commonly cited when discussing page speed.
This is the aggregate metric, but the individual phases above tell you which part of the total to address. Optimising total load time without phase data is guesswork; optimising with phase data is targeted.
How data is captured
The Statalog tracker reads timing data from window.performance.timing (Navigation Timing API Level 1) or PerformanceNavigationTiming (Level 2) after the page load event fires. This data is collected automatically for every pageview — no configuration is required.
The timing data is sent alongside the first pageview beacon of each session. It is not sampled — every session with a supported browser contributes timing data.
The UI — per-page averages
The Performance section shows timing data in two views:
Site-level averages — aggregate timing across all pages and sessions in the selected date range, giving you a baseline for your overall site performance.
Per-page breakdown — filtering by a specific page (either by clicking the page in the Pages report or using the page filter) scopes all timing data to that page. This lets you identify which specific pages are dragging down your averages.
Comparison with GA4
Google Analytics 4 does not include detailed page load timing data. GA4 removed the timing metrics that were present in Universal Analytics (where gtag could capture performance.timing data). In GA4, you would need to implement custom events and custom dimensions to capture any load timing data, which requires significant configuration and tag manager expertise.
Statalog captures all seven phases automatically with no configuration, for every session, on every page.
FAQ
What browsers support the Navigation Timing API? The Navigation Timing API is supported in all modern browsers including Chrome, Firefox, Safari, Edge, and their mobile counterparts. For the very small percentage of visitors on browsers without this API, timing data is simply not captured — the pageview is still recorded normally.
Why do I see different timing numbers from tools like Lighthouse or PageSpeed Insights? Lighthouse and PageSpeed Insights run tests from controlled lab environments — a specific machine, a specific network speed, a specific geographic location. Statalog's timing data comes from real visitors on their real devices and real network connections. Lab data is useful for identifying optimisation opportunities; real user data (as Statalog provides) tells you the actual experience your visitors are having.
My TTFB looks fine but total load time is high — what should I check? If your server is responding quickly (low TTFB) but total load time is high, the bottleneck is on the client side. Check the On-load phase — large images and third-party scripts are the most common cause. Check the DOM processing and DOM completion phases for render-blocking resources.