Website Speed Test.

This test is accurate for what it measures, which is one real network fetch of your page from our India edge server, capturing the time to first byte and the total download time of the HTML for that single request. Those numbers are genuine and useful for spotting a slow server or a sluggish origin. What it deliberately does not measure is the full rendered experience: it does not run your JavaScript, render the page in a browser, or track layout shifts and interactivity, so it is not a complete Core Web Vitals score. For that fuller picture, including LCP, CLS and INP, use Google PageSpeed Insights, which we link from the results for exactly this reason. The right way to think about it is that this tool is a fast, India-based first check on server responsiveness, ideal before and after a hosting change, while PageSpeed Insights is the deeper diagnostic for how the page actually feels to load and use.

Some variation between runs is completely normal, because real-world performance is never perfectly constant. Each test depends on live network conditions between our server and yours, the current load on your hosting at that moment, caching state, and routing, all of which fluctuate second to second, so two back-to-back tests can legitimately differ. The way to get a trustworthy reading is to run the test three times and take the average rather than trusting a single number, which smooths out one-off blips. A little spread around the average is fine. What is worth investigating is wide, erratic swings, say one test at 200 ms and the next at 1.5 seconds, because that points to genuine inconsistency in your server or hosting, perhaps an overloaded shared host or a backend that occasionally stalls, rather than a flaw in the test. A server that responds unpredictably frustrates real visitors too, so jumpy results are a signal to look at your hosting.

A timeout means our test sent a request and waited the full 15 seconds without receiving a usable response, so it gave up. There are a few common causes worth checking in order. Your origin server may simply be down or unresponsive at that moment, so try the test again after a short while. Your DNS may be misconfigured or pointing to the wrong place, so the request never reaches a live server. Or your site or its firewall may be blocking requests from our server IP, which some security setups do for unfamiliar sources. To narrow it down, open the same URL directly in a browser: if it loads fine for you but times out here, the issue is likely a block on our IP or a region-specific routing problem; if it is also slow or broken in your own browser, the problem is your server or DNS itself. Either way, a timeout is a meaningful red flag, since real visitors would experience the same failure.

No, this tool does not run JavaScript. It performs a raw HTTP fetch of your page and measures the network response, the time to first byte and the total time to download the HTML, without spinning up a browser, executing scripts, or rendering anything visually. That keeps the test fast and lightweight and makes it a clean measure of how quickly your server delivers the page, but it means it cannot tell you anything about client-side behaviour: how long your JavaScript takes to execute, whether the layout jumps around as it loads, or how responsive the page feels once interactive. For those rendered-performance questions, you need a tool that actually loads the page in a real browser, which is precisely what Google PageSpeed Insights does, running the full Chrome rendering pipeline including JavaScript and reporting the Core Web Vitals. So use this tool for a quick, server-focused speed check, and reach for PageSpeed Insights, linked from the results, for the complete experience.

Time to first byte, the delay before your server starts sending the page, is a key indicator of backend health, and there are clear benchmarks. Under 200 milliseconds is excellent and signals a fast, well-configured server. Under 600 milliseconds is good and perfectly acceptable for most small business sites. A TTFB between roughly 600 milliseconds and 1 second is workable but worth optimising, since the delay is becoming noticeable. Anything over 1 second is a genuine problem that points to a hosting or backend bottleneck, an overloaded shared host, an inefficient database query, a missing cache, or a server located far from your visitors, and it should be your first priority to fix. The important principle is that TTFB sits before any frontend work matters: there is little point optimising images and scripts if the server itself takes a second to respond. So fix a slow TTFB at the hosting level first, then move on to frontend optimisation.

Total load time here means the time from the moment the request starts to the moment the full HTTP response body, your page HTML, has finished downloading. It bundles together several stages: the initial connection setup, the time to first byte while the server prepares its response, and the actual transfer of the HTML document over the network. It is a clean measure of how quickly your server delivers the core page. What this figure does not include is everything the browser fetches afterwards: your images, CSS files, fonts and JavaScript are requested and downloaded separately by a real browser once it has the HTML, and those are not part of this number. That is why a page can show a fast total load time here yet still feel slow if it is heavy with large images or scripts. So treat this as a measure of server and HTML delivery speed, and use PageSpeed Insights for the complete weight of the page.

We keep only a minimal, short-term record. The URL you test and the timing data are written to our server logs for a limited time, purely to prevent abuse of the tool, such as someone hammering it to overload a third-party site, and to keep the service running reliably. We do not associate the tested URL with you as an individual, we do not build a profile from it, and we do not share it with anyone or use it for marketing. These logs are operational and short-lived rather than a permanent database of what people checked. In practice, the URLs you test are public web addresses anyway, the same pages anyone can visit, so there is nothing sensitive recorded the way there would be with a password or personal data. If you are testing internal or pre-launch URLs you would rather not have logged, test them from your own browser tools instead.

For most small businesses, a routine monthly check is plenty to keep an eye on your site speed and catch gradual slowdowns before they hurt visitors or rankings. Speed does not usually change on its own from day to day, so testing more often than that rarely tells you anything new. The times it is genuinely worth running an immediate, same-day test are right after any meaningful change to your site: a hosting migration or plan change, a redesign, adding heavy new plugins, scripts or tracking tags, swapping your theme, or loading a batch of large images, since each of those can quietly slow things down and you want to know straight away rather than weeks later. A good habit is to test once before such a change and once after, so you can see the impact directly. Outside those events, fold the monthly check into your regular maintenance, and investigate promptly if a test ever comes back noticeably slower than usual.