Understanding exactly how long your website takes to load, and crucially at which stages it stalls along the way, is the first step toward improving it in any meaningful way.
Loading Website Speed Test…
Total load time measurement
Stage-by-stage timing (DNS, TTFB, FCP, LCP)
Waterfall-style breakdown
No sign-up required
Drop the Website Speed Test into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.
Embed code
<iframe
src="https://www.fixtools.io/web-tools/website-speed-test?embed=1"
width="100%"
height="780"
frameborder="0"
style="border:0;border-radius:16px;max-width:900px;"
title="Website Speed Test by FixTools"
loading="lazy"
allow="clipboard-write"
></iframe>Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.
Website load time is not a single number, it is a cascade of sequential phases, each with its own causes and corresponding fixes. DNS resolution converts a domain name to an IP address; this typically takes 20 to 120 milliseconds and is rarely a significant bottleneck unless you are using a poorly performing DNS provider or have configured CNAME chains that add extra lookups. TCP connection and SSL handshake add another 50 to 150 milliseconds for HTTPS sites. Time to First Byte (TTFB) is where most server-side issues manifest: a TTFB over 800ms typically indicates absent page caching, slow database queries, or an underpowered shared hosting plan. From TTFB onwards, the browser downloads HTML, parses it, discovers and fetches CSS and JavaScript, executes JavaScript, and finally renders the visible content. The Largest Contentful Paint marks the end of this chain from the user's perspective.
Industry benchmarks from HTTP Archive's State of the Web report provide useful context for what is achievable and what is merely typical. The median mobile LCP for websites globally sits at approximately 3.5 to 4 seconds, well above Google's 2.5 second good threshold. The top 10% of sites achieve LCP under 1 second on mobile, demonstrating that the technical ceiling is much higher than most operators realise. For TTFB, the median is approximately 1.7 seconds, while the top 10% of sites achieve under 200 milliseconds through aggressive caching and CDN deployment. These benchmarks illustrate that significant headroom exists for most websites. A site achieving top-quartile performance metrics holds a measurable advantage in both user engagement and search ranking over the median site in most competitive categories tracked.
When reviewing load time data, always prioritise mobile measurements over desktop. Google's mobile-first indexing means that your mobile performance data is what Google uses to score your site for rankings, with desktop performance treated as a secondary signal in nearly all cases. Mobile measurements are typically two to four times worse than desktop due to slower CPUs, lower-bandwidth cellular networks, higher latency, and different rendering pipelines that struggle with heavy JavaScript payloads. A desktop load time of 1 second does not imply a mobile load time of anything close to 1 second, so test mobile explicitly rather than assuming desktop results translate. Many sites that look fast on a developer's laptop are genuinely painful on a mid-range Android phone with a typical 4G signal.
A second pattern worth recognising in load time data is the difference between cold and warm cache visits. A first-time visitor without any cached assets downloads everything from origin or CDN, while a returning visitor with a populated browser cache may skip large portions of the resource list entirely. Synthetic speed tests almost always simulate cold cache conditions because that represents the worst case and the experience of new users finding your site through search. If your tool reports a load time of 4 seconds but you personally experience the site loading in 1 second, the difference is almost certainly cache state rather than measurement error. Test cold cache results as the headline number, and treat warm cache speed as a separate metric for returning user experience.
Enter your URL to get a detailed breakdown of every stage of your page load time.
Step-by-step guide to check website load time:
Enter the page URL
Paste the full URL including the https:// prefix of the specific page you want to time. Avoid testing redirect URLs because each redirect hop adds a measurable delay that pollutes the result. Always navigate to the canonical final URL before pasting it into the tester so the numbers reflect actual user experience rather than redirect overhead.
Run the test
Click Test and wait for the tool to fully load your page and record all timing events from the initial DNS lookup through to the moment the page becomes fully idle. Most tests complete in 20 to 40 seconds. Resist the temptation to interrupt the test or run multiple tests in parallel, as concurrent runs can starve the measurement environment of resources and skew the timing data.
Review the timing breakdown
Check DNS time, TTFB, FCP, LCP, and total load time. Identify which single stage consumes the largest share of the total budget and study where the gaps between stages appear. A long delay between TTFB and FCP usually indicates render-blocking resources in the document head, while a long gap between FCP and LCP almost always points to a slow-loading hero image or above-fold media element.
Prioritise the bottleneck
High TTFB means you should investigate hosting, server configuration, database query performance, or absent caching at the origin. Long render time after TTFB means you should investigate large unoptimised images, render-blocking JavaScript in the head, or oversized CSS bundles. Match the fix to the stage where time is actually being spent rather than applying a generic optimisation checklist that may not address your specific bottleneck.
Common situations where this approach makes a real difference:
Hosting provider comparison
A site owner compares load times on their current shared hosting versus a new managed VPS by testing the same page on both environments and observing a TTFB reduction from 1.2 seconds to 180 milliseconds. The numerical evidence transforms a vague hunch about hosting quality into a concrete business case for the upgrade. They also document the comparison to justify the recurring cost difference to other stakeholders, who can now see that the new plan pays for itself through improved conversion rates rather than being a discretionary expense.
CDN effectiveness check
A developer enables a CDN for the first time and re-tests load time from multiple geographic locations to verify the configuration is working as intended. The timing breakdown confirms the CDN is serving assets correctly and reducing download time by approximately 60% for users in regions far from the origin server. They also catch a misconfigured cache rule that was bypassing the CDN for one asset type, fix it during the same session, and document the corrected configuration in their internal runbook for future reference and easier onboarding.
Slow page investigation
A site owner receives multiple support complaints about one specific page being "really slow" while the rest of the site feels fine to users. The load time checker reveals a 4.2 second total load time driven almost entirely by a 2.8MB unoptimised hero image that the marketing team uploaded without realising the impact. The fix is straightforward: compress the image, convert to WebP, and add explicit dimensions, dropping the page weight by 90% and restoring load times in line with the rest of the site.
Use this when investigating why a page feels slow to users, the stage-by-stage breakdown reveals whether the bottleneck is at the server, network, or browser rendering stage.
Get better results with these expert suggestions:
Focus on TTFB before front-end optimisation
If your TTFB sits above 800 milliseconds, front-end optimisations such as image compression will have limited impact because the underlying bottleneck is at the server, not the assets. Tackle server response time first by enabling full-page caching, upgrading to a faster hosting tier, or adding a CDN with edge caching. Front-end work becomes highly effective only once TTFB is under 200 milliseconds and the browser can actually begin its rendering pipeline promptly after the request lands.
Measure load time at the 75th percentile
Average load times are misleading because a small number of extremely slow page loads can skew the median and create false confidence. Google's Core Web Vitals are measured at the 75th percentile of field data, meaning 75% of users must have good experiences for the site to count as passing the threshold. Measure your P75 load time, not just the average, to align with how Google actually scores your site for ranking and to surface the experiences of users on slower devices and networks.
Test on throttled mobile network conditions
Testing on a fast home or office internet connection dramatically understates load time for real users on the move. Use Google PageSpeed Insights' simulated mobile testing, which emulates a mid-tier 4G connection with 150ms latency, as your primary benchmark since this better reflects your median user's actual network conditions. For an even more conservative test, use Chrome DevTools to throttle to Slow 3G and confirm the page remains usable, which is the standard many global audiences experience daily.
Establish a load time budget before building
A performance budget sets maximum acceptable values for total page weight, number of requests, JavaScript bundle size, and load time targets before development begins on a new project. Establishing this budget upfront prevents the gradual accumulation of "just one more script" decisions that collectively add seconds to load time on production. Codify the budget in your build pipeline so deploys that breach the limit fail automatically, giving every developer immediate feedback rather than letting regressions accumulate quietly over months.
Identify which stage is the bottleneck
High TTFB (>600ms) points to slow server or hosting. Long render time after TTFB points to large or render-blocking resources. The timing breakdown helps you focus fixes on the right layer.
Under 3 seconds total load time is the target
Google research shows 53% of mobile visitors abandon a page that takes more than 3 seconds to load. A sub-2-second load time is excellent. Sub-1-second is exceptional and achievable with aggressive optimisation.
Compare before and after optimisation
Benchmark load time before making any changes. After each optimisation (compressing images, adding caching, enabling CDN), re-test to measure the exact improvement.
More use-case guides for the same tool:
Other tools you might find useful:
Open the full Website Speed Test — free, no account needed, works on any device.
Open Website Speed Test →Free · No account needed · Works on any device