Website Speed Test

Test URL response time • Audit this page • Estimate load time

Test a URL: measure approximate response time from your browser by loading the page or a resource several times.

Include http:// or https://. The test loads the URL (or its favicon) from your browser and times how long it takes to respond.

Results reflect your connection and location. They are useful for quick checks but not a replacement for full lab tests like Lighthouse or WebPageTest.

Result

Browser-based estimates only. Use as a quick indicator, not a full replacement for lab and field data.

Choose a mode, provide any required inputs, and click Run test to see timings and suggestions here.

Saved Tests

Saved locally in this browser. Handy for comparing before/after optimisations.

    No saved tests yet. Run a speed test and click Save to keep it here.

    Understand Your Website Performance with the Website Speed Test

    Fast websites convert better, rank better, and feel better to use. The Website Speed Test on this page gives you a quick, browser-based view of how fast a URL responds, how your current page behaves, and how long a page is likely to take to load under different network conditions. While it is not a full replacement for tools like Lighthouse, PageSpeed Insights, or WebPageTest, it is ideal for rapid checks and conversations with non-technical stakeholders.

    All measurements are taken from your current browser session. That means results reflect your location, device, and connection. On a site such as seotoolsfix.com, you can use this tool to sanity-check performance changes, benchmark different pages, and give clients a clear explanation of what “fast” or “slow” actually looks like in numbers.

    Mode 1 – Test a URL (Simple Response Time Check)

    In Test a URL mode, you paste any full URL and the tool attempts to load it (or its favicon) multiple times in the background. For each run, it records how long it takes from starting the request until the browser finishes downloading the resource or reports an error. The result is an average, minimum, and maximum response time across all runs.

    Because these measurements are taken from your browser, they are affected by your own network conditions, local caching, and how far you are from the site’s servers. That makes them excellent for quick comparisons and regression checks (for example, whether a change made things slower today than yesterday), but less suitable as a universal “global” benchmark. For serious performance work, you should also examine server logs, CDN analytics, and dedicated lab tests.

    Mode 2 – Audit This Page Using the Performance API

    The Audit this page mode uses the browser’s Performance API to read timing data for the page you are currently viewing. It reports key metrics such as time to first byte (TTFB), DOMContentLoaded time, total load time, the number of resource requests, and (where supported) approximate transfer sizes. These values help you understand how quickly the HTML arrives, how long the browser takes to parse and build the DOM, and how many assets are involved.

    For example, you might discover that TTFB is low (the server responds quickly) but total load time is high because there are too many large JavaScript bundles or unoptimised images. Or you may see that there are hundreds of small requests, suggesting that combining or lazy-loading assets could improve responsiveness. Running the audit before and after performance work – minification, caching, image compression – gives you a concrete, easy-to-share story of how things improved.

    Mode 3 – Load Time Estimator for Page Weight and Connection Speed

    The Load time estimator mode takes a different angle. Instead of measuring a specific page in real time, it lets you enter an estimated page weight (in kilobytes or megabytes), an optional number of requests, and a connection profile such as fast broadband, 4G, or 3G. Using those inputs, the tool approximates how long the full page might take to load under that network, combining transfer time with an assumed latency.

    This is particularly helpful in planning and communication. If you know a page is around 2.5 MB and you are targeting mobile users on congested networks, the estimator will show that load times could easily exceed several seconds on 3G-like connections. That can push you to invest in image compression, critical rendering-path optimisation, or a lighter-weight design before you ship.

    How to Interpret the Results Responsibly

    All results from this Website Speed Test are best treated as indicative rather than absolute. Different users around the world will experience different latencies and throughputs. Content delivery networks, browser caches, and device performance can all change real-world outcomes. A page that feels instant on a high-end desktop with fibre may still struggle on a budget phone in an area with weak coverage.

    For that reason, you should use this tool alongside field data (such as Core Web Vitals from real users) and repeatable lab tests. The value of this plugin is speed and transparency: you can explain to someone, in plain language, why 4–5 seconds is slow for a landing page, why 2 seconds is a common target, and how both server-side and front-end optimisations contribute to getting there.

    Frequently Asked Questions

    Does this tool measure the same things as Lighthouse or PageSpeed Insights?

    No. Lighthouse and PageSpeed Insights run controlled audits with a full simulated device, network, and throttling environment, and they calculate user-centric metrics such as First Contentful Paint (FCP) and Largest Contentful Paint (LCP). This Website Speed Test focuses on simpler numbers like response time, TTFB, and full-load time estimates, using the browser’s Performance API and basic transfer math.

    Are the results the same for every visitor?

    No. Because measurements are taken from your own browser, they are specific to your device, location, and network at the time of the test. Someone on a slower connection or different continent will likely see different numbers. That is why this tool is best for trend analysis and communication rather than as a single source of truth.

    Why do some URL tests fail or return inconsistent times?

    When testing a URL, the plugin loads the resource as an image or via the browser’s fetch mechanisms. Some sites use aggressive security policies, redirects, or caching that can introduce variability or block certain types of requests. Network jitter, DNS resolution, and shared Wi‑Fi conditions can also cause outliers. Running multiple tests and looking at averages can reduce noise.

    Does the Website Speed Test upload my URLs or timing data to a third-party service?

    No. The plugin performs all tests in the browser. It does not send your URLs, performance metrics, or history to remote servers by default. Saved tests are stored using local storage on your device and can be cleared at any time. If you wish to integrate external APIs or dashboards, you would need custom development on top of this plugin.

    How accurate is the load time estimator based on page weight and connection speed?

    The estimator uses straightforward calculations: transfer time = (page weight × 8) ÷ downlink bits per second, plus a latency allowance depending on the chosen profile. It does not account for advanced optimisations such as HTTP/2 multiplexing, caching, compression, or critical resource ordering. Think of it as a ballpark view that helps you reason about “is this design likely to feel fast on 3G?” rather than a millisecond-perfect model.

    Can I use this tool to prove that a hosting provider is slow?

    You can certainly use it to gather anecdotal evidence and support discussions, but it should not be your only input. To evaluate hosting accurately, you should combine multiple tools, run tests from different regions, and ideally look at server-side metrics such as CPU, memory, and request logs. This plugin is best for quick checks and education, not for formal SLAs or contractual disputes.