Load Summary
A quick summary of the page load, including TTFB, Fully Loaded time, and total transferred size.
Documentation
This page explains the terms used in reports, performance metrics, browser timings, waterfall charts, nodes, and test settings.
Performance cards use four rating levels: Good, OK, Long, and Poor. Administrators can change the three numeric boundaries for each visible metric from Admin Settings.
A quick summary of the page load, including TTFB, Fully Loaded time, and total transferred size.
A quick resource summary for the report, showing FCP, the number of recorded page elements, and the slowest loaded element.
Measured values come from Lighthouse, Navigation Timing, HAR page timings, or observed long-task/layout-shift entries. When Lighthouse fields are missing, SpeedCheck uses HAR request timing to estimate render readiness, early visual completion, interactivity, and blocking windows; these values are marked as Estimated.
The node location used for the test. Location codes use the cc-datacenter format, such as ir-asiatech, and the country code controls the flag.
The total transferred size for all recorded requests in the test. It helps compare page weight across test runs.
The total number of recorded requests and resources in the waterfall, including HTML, CSS, JavaScript, images, fonts, API calls, and other assets.
The longest single request duration found in the waterfall. It helps identify the resource that took the most time to load.
These metrics primarily come from Lighthouse performance data. HAR page timings, waterfall request timing, browser paint entries, long tasks, and layout-shift entries are used as fallbacks when direct Lighthouse values are not present.
How quickly the browser paints the first text, image, SVG, or canvas content. If no browser paint timing is present, SpeedCheck estimates it from the final HTML response, render-blocking CSS, and a small render allowance.
How long it takes for the page to become reliably interactive. Direct Lighthouse TTI is preferred; if HAR does not include long-task data, SpeedCheck extends FCP by the largest estimated JavaScript task.
How quickly visible content appears during load. Lighthouse calculates this from visual frames; when frames are not available, SpeedCheck estimates it from the FCP-to-LCP visual window.
The total time where long JavaScript tasks block the main thread after FCP. Direct Lighthouse or long-task data is preferred; otherwise SpeedCheck estimates JavaScript task cost from HAR script payloads and sums only the part above 50ms per task.
How long it takes for the largest visible content element, often a hero image or main heading, to render. Lower is better.
How much visible layout moves unexpectedly while the page loads. Lower is better; without browser layout-shift entries, SpeedCheck displays an Estimated zero from the HAR-only fallback.
Browser Timings are read from Navigation Timing data and HAR page/request timings. The main document request is used for connection, backend, and TTFB values.
The time spent following redirects before the final page request starts.
The time spent establishing the network connection, including TCP and sometimes TLS setup.
The time from sending the request until the server begins sending the response. This helps reveal slow server processing.
The time until the first byte of the main document response is received. It includes network and server response time.
The first moment the browser paints anything that is visually different from the default background.
The point where the browser has parsed the document enough for scripts to begin interacting with the DOM.
The time when the initial HTML is parsed and deferred scripts have run, without waiting for images and every subresource.
The browser load event timing. It usually fires after the document and dependent resources have loaded.
The final observed page load milestone in the report, based on browser timing and waterfall activity.
A request-by-request view of the page load. It shows when each request started, how long it took, and which phase consumed time.
The requested resource path or URL, such as the main document, CSS file, JavaScript file, image, font, video, or API call.
The HTTP status code returned by the server. Failed requests are highlighted because they can affect page behavior.
The request method and resource category, for example GET HTML, GET CSS, GET JS, image, font, video, or XHR.
The hostname that served the request. This helps identify third-party services and external dependencies.
The transferred or encoded response size when available. Smaller assets usually load faster and consume less bandwidth.
The visual timing bar for each request. Colored segments show the different network phases of that request.
Time spent before the browser can start the request. It can include queueing and connection slot delays.
Time spent resolving a domain name to an IP address.
Time spent opening the network connection to the server.
Time spent negotiating TLS for HTTPS requests.
Time spent sending the HTTP request to the server.
Time spent waiting for the server to start responding after the request is sent.
Time spent downloading the response from the server.
Downloads the HTTP Archive file for deeper debugging in tools that support HAR inspection.
Request and response metadata, such as content type, cache headers, server headers, cookies, and browser request headers.
Query string values included in the URL.
Data sent in the request body for POST or similar requests, when available in the captured data.
Information about the server response, such as status, type, size, redirect target, and body preview if available.
A preview of an image request directly from its URL, when the resource type is image.
A preview player for a video request, when the resource type is video.
The script, parser, or browser action that caused a request to start. This helps trace why a resource was loaded.
The browser engine used to run the test, such as Chromium, Firefox, or WebKit when supported by the plan and node.
The simulated connection settings used during the test, such as download speed, upload speed, and latency.
The browser event used to decide when the page load step is complete, such as DOMContentLoaded, load, or network idle.
The number of tests a guest or user can run per day. Admin settings and user plans can change this limit.
A remote worker server that runs browser tests and sends screenshots, HAR data, waterfall data, and result JSON back to the master app.
The node location format is cc-datacenter. For example, ir-asiatech means country Iran and datacenter Asiatech.
The latest health check result from the node. OK means the node responded to health and status endpoints.
The current running and queued job counts for a node. The master uses this to avoid overloading nodes.
A user package that can define daily limits, retention days, allowed browsers, and allowed node tags.