Free Website Speed Test Online

Website Speed Test: Real Page-Load Timing From an Actual Browser

A website speed test answers a more involved question than a simple up/down check: not just whether it loads, but how long it actually takes, and where that time goes. This tool answers that by launching a real, headless instance of Chrome on the server, navigating it to the URL you provide exactly as an ordinary browser would, and reading the browser's own Navigation Timing and Resource Timing measurements once the page finishes loading. The result covers time to first byte, when the DOM became ready, when the full page finished loading, how many bytes were transferred, how many separate requests fired, and a breakdown of those requests by type.

It's worth being precise about what this tool is not, since the name invites a natural assumption: this is not Google Lighthouse, and it does not produce a 0-100 performance score, an accessibility score, an SEO score, or Core Web Vitals figures like Largest Contentful Paint, Cumulative Layout Shift, or Interaction to Next Paint. Those come from a different, much larger category of audit built around simulated conditions and a weighted scoring rubric. What this tool gives you instead is the raw, real timing data a browser collects while loading a page — genuinely useful on its own, just not the same measurement a Lighthouse report produces.

How to Run a Speed Test

1. Enter a domain or full URL — a bare domain such as example.com is automatically expanded to https://example.com if you don't include a protocol.
2. Click Test. Because this test drives an actual browser through a full page load instead of making a single lightweight request, it can take up to about twenty seconds for a slow or heavy page — a loading message says as much while it runs.
3. Behind the scenes, the target address is validated first, headless Chrome is launched, its DNS resolution for that one hostname is locked to the address already confirmed safe (so the browser can't be redirected somewhere else mid-test), and the page is loaded while the browser waits for its own load event to fire.
4. Once the page finishes loading, the tool reads the browser's Navigation Timing entry and every Resource Timing entry recorded during the load, then reports the aggregated figures.
5. Five headline numbers appear first — Time to First Byte, DOM Ready, Full Load, Page Weight, and Requests — followed by a breakdown of how many of those requests were scripts, stylesheets, images, fonts, or something else.

Why People Test Page-Load Speed

• Confirming an optimization actually helped. After compressing images, deferring a script, or switching CDNs, a before-and-after comparison of load time and page weight is the most direct way to confirm the change made a measurable difference rather than just feeling faster.
• Investigating a slow-loading complaint. When a visitor or a colleague reports that a page feels sluggish, a real-browser timing run separates a genuinely slow server or heavy page from a one-off network hiccup on their end.
• Sizing up how much a page actually weighs. The transferred-bytes figure and the per-type request breakdown show at a glance whether a page is bloated by oversized images, an unusually large number of script files, or heavy font loading — often the first clue about where to focus optimization effort.
• Comparing a staging environment against production. Running the same address against a staging domain and the live domain highlights whether a pending change — a new build, a different asset pipeline, an added third-party script — shifts load time before it ships.
• Getting a second, independent measurement. Because the test runs from FreeConvertingTools' own infrastructure, it isn't affected by your personal connection speed, browser cache, or ad-blocker configuration — useful as a second data point alongside your own local testing.

What Each Measurement Means

Field	What it measures
ttfbMs	Time to First Byte — how long the browser waited between sending the request and receiving the first byte of the response
domContentLoadedMs	Time until the DOM finished parsing and was ready for scripts to run, without necessarily waiting on every image or stylesheet
loadMs	Time until the browser's load event fired — every resource on the initial page, including images and stylesheets, had finished loading
transferredBytes	Total bytes transferred across the main document plus every sub-resource the page requested
requestCount	The total number of separate network requests the page made while loading
resourceBreakdown	How those requests split across scripts, CSS, images, fonts, and an "other" catch-all category

These figures come directly from the browser's own PerformanceNavigationTiming and PerformanceResourceTiming entries — the same underlying data a browser's own DevTools Network and Performance panels are built on — rather than from an external estimate or a modeled approximation of network conditions.

Why This Isn't a Lighthouse Score

Lighthouse and similar full audits combine dozens of signals — simulated throttled network and CPU conditions, layout-shift tracking, accessibility tree inspection, best-practices checks, and more — into a single weighted number per category, plus a prioritized list of recommendations for improving it. That's a genuinely different kind of tool, built to approximate a "typical user" experience and grade against it. This speed test does something narrower and more literal: it loads the real page, once, on the server's own network connection, and reports exactly what the browser measured during that one load — no throttling simulation, no scoring rubric, no layout-shift tracking, and no ranked list of fixes. A dedicated Lighthouse run, available free in Chrome DevTools or through Google's PageSpeed Insights, is the right choice when you need a graded audit with Core Web Vitals and specific recommendations; this tool is the right choice when you need a quick, honest timing snapshot of how long a real page load takes right now.

How Resources Get Categorized

Behind the "Resource Breakdown" figures, each request the page made while loading gets sorted into one of five buckets. The classification first checks the browser's own reported initiator type — a request the browser tagged as originating from a script tag or a stylesheet link element is counted as a script or CSS request accordingly. For anything the initiator type doesn't clearly settle, the tool falls back to the file extension in the request's address: .js and .mjs read as scripts, .css as stylesheets, common image extensions such as .png, .jpg, .webp, and .svg as images, and font formats like .woff2 or .ttf as fonts. Anything left over — an XHR call, a beacon, a document fetched through the page's own script, or a resource type the classifier doesn't specifically recognize — lands in the "Other" bucket. This is a simple, transparent categorization rather than a deep content-inspection process, so an unusual asset served under a misleading file extension can occasionally land somewhere you wouldn't expect.

Factors That Can Make One Run Differ From the Next

A single test run is a snapshot, not a guaranteed baseline, and a few ordinary factors can shift the numbers between one run and the next: server-side caching that makes a second request to the same address faster than the first cold load; a CDN edge node that happens to sit closer or farther from the testing server depending on routing at that moment; third-party scripts — analytics, ads, embedded widgets — whose own response time varies independently of your own site; and general network conditions along the path between the testing server and the target, which aren't fully within either party's control. Running the test two or three times and looking at the general range, rather than treating any single number as gospel, gives a more reliable picture than a lone pass does.

Manual Testing vs. Using This Tool

• Your own browser's DevTools. Opening the Network panel and reloading a page gives a similarly detailed timeline, with the advantage of testing under your own actual visitor conditions — which is also the drawback if what you want instead is a network-neutral, third-party measurement.
• Google PageSpeed Insights or Lighthouse. The right choice when you specifically want a Core Web Vitals-based score, an accessibility and SEO audit, and prioritized fix suggestions — a heavier, more opinionated tool than this one.
• Dedicated synthetic-monitoring services. Built for scheduled, repeated testing from multiple global locations over time, which is the right fit if you need a historical trend rather than a single on-demand reading.
• This tool's API. For working a real-browser timing measurement into an automated build check or an internal dashboard, the same browser-driven test is reachable through a metered API route, with parameters and pricing covered in the API documentation.

Does this tool give me a performance score out of 100?

No. It reports raw timing and byte figures — Time to First Byte, DOM Ready, Full Load, page weight, and request count — measured from one real page load. It does not calculate a Lighthouse-style score, and it does not report Core Web Vitals metrics like Largest Contentful Paint or Cumulative Layout Shift.

Why did my test take up to twenty seconds to finish?

Unlike a simple status check, this test launches an actual browser and waits for the entire page — every script, stylesheet, image, and font — to finish loading, the same way a real visitor's browser would. Heavier pages with more resources naturally take longer to fully settle, and the test waits for that full completion rather than cutting off early.

Can I test a page that sits behind a login or requires a password?

No. The test navigates as an anonymous visitor with no stored cookies or credentials, so it only sees what a first-time, logged-out visitor would see. A page that redirects unauthenticated visitors to a login screen gets measured as that login screen's load time, not the content sitting behind it.

Can this be used to test a site on my company's internal network?

No. The address is validated before headless Chrome ever launches, and any private, internal, loopback, or link-local target is refused outright — the browser is also locked to resolving only the one already-approved public address for the page's main hostname, and any sub-resource request the page tries to make to a different host during the load gets blocked. Only publicly reachable addresses can be tested.

Does the request count include the main page document itself?

Yes. The requestCount figure counts the initial HTML document plus every sub-resource — scripts, stylesheets, images, fonts, and anything else — the page pulled in while loading, so it lines up with the total row count you'd see across a browser's own Network panel for the same page.

Related Network Tools

Speed is only one dimension of a site's health. Run the same address through the website status checker first to confirm the basic up/down status and HTTP status code, or the HTTP headers viewer to inspect caching directives and security headers that can affect repeat-visit performance. For certificate-related issues on an HTTPS site, the SSL certificate checker reports on expiry and chain details separately from load timing.