Knowledge Mark G
Hire Me

100% free speed tool

Website Speed Test

Measure a page's server response time, page weight, compression, caching and render-blocking files - real timings, not estimates.

  • No sign-up required
  • Instant results
  • Only the address is sent
  • Works on any device

What to test

How much of the site?

Start with server response time: nothing on the page can appear before the first byte. Then look at what blocks rendering.

Three real requests from our server on fresh connections - the headline is the median. A domain on its own tests the home page.

Pick why you are checking, enter an address, and choose one page or the whole site. The report puts what matters for your reason first.

Private by design. Only the web address you enter is sent - to fetch the page. Nothing is stored.

  • 100% freeNo hidden charges, no watermark
  • Instant resultsDone in seconds, no queue
  • Secure & privateOnly the address is sent
  • Works on all devicesDesktop, tablet and mobile

How to use the Website Speed Test

  1. 1Pick why you are checking, then enter the address.
  2. 2Test the home page, or choose All pages and pick which pages to test.
  3. 3Work through the fixes for your reason first, then copy or download the report.

What is measured

Every test is real requests from our server, timed part by part: the DNS lookup, the TCP connection, the TLS handshake plus the server’s own processing, and the download. That gives the time to first byte (TTFB) - the point before which nothing on the page can appear. A single-page test repeats the request three times on fresh connections and reports the median, because one request can be unusually lucky or unlucky. The HTML is then checked for what slows rendering: scripts and stylesheets that block it, images without dimensions, missing compression, oversized pages and third-party domains.

One page or the whole site

By default only the page you enter is tested - the home page if you type just the domain. Choose All pages and the site's pages are listed from its XML sitemap (or from the links on its home page when there is no sitemap). Pick the ones you want - up to 200 - and they are tested three at a time, with a summary of the median and slowest pages and the issues that appear on most of them. An issue on every page is almost always a template or server setting, so fixing it once fixes the whole site.

Why the reason matters

The same report means different things depending on why you are looking. If the site feels slow, server response time comes first; for Google rankings, it is Core Web Vitals and what blocks rendering; after a hosting move, TTFB, HTTP version, compression and caching. The reason you pick puts those findings at the top and changes the advice.

Core Web Vitals

LCP, INP and CLS come from real browsers, so they are not computed from the HTML. Tick Include Core Web Vitals and the report adds Google's own data from PageSpeed Insights: real-visitor figures from the Chrome UX Report where the site has enough traffic, and a Lighthouse lab test on a simulated phone.

What good looks like

Google’s guidance is a TTFB of 0.8 seconds or less; over 1.8 seconds is poor. The fastest sites serve cached HTML from a CDN close to the visitor. If your TTFB is slow, the usual fixes are page caching (so the server does not rebuild the page on every request), a CDN, and a faster database query or host. Remember that one test from one location is a sample - run it a few times.

Quick wins

  • Turn on Brotli or gzip compression for HTML, CSS and JavaScript.
  • Add defer to scripts in the head.
  • Set width and height on every image, and lazy-load those below the fold.
  • Serve images as WebP or AVIF - the image compressor converts them.
  • Use HTTP/2 or HTTP/3 - usually a single setting on the host or CDN.

Checking on-page SEO as well? Run the SEO checker, and the security headers checker for the server side.

Frequently asked questions

What is a good TTFB (time to first byte)?+

Under 200 ms is good, up to about 600 ms is acceptable, and anything slower holds back the whole page - nothing can render before the first byte arrives. This test takes the median of three requests, so one slow response does not skew the result.

What is TTFB?+

Time to first byte: how long from starting the request until the first byte of the response arrives. It includes DNS, connection, TLS and the server's processing time, and nothing on the page can render before it.

What is a good TTFB?+

0.8 seconds or less, by Google's guidance. Between 0.8 and 1.8 seconds needs improvement; over 1.8 seconds is poor.

Why is this different from PageSpeed Insights?+

PageSpeed Insights renders the page in a browser and reports Core Web Vitals. This test measures the server and the HTML directly, with real timings, and points out the causes - the two complement each other.

Where is the test run from?+

From our server, on fresh connections with nothing cached, so it reflects a first visit. A single-page test makes three requests and reports the median. Results vary with distance to your server - a CDN reduces that.

Can I test every page of my website?+

Yes. Choose All pages: the pages are read from your XML sitemap, or from the links on your home page if there is no sitemap. Pick up to 200 and they are tested together, with the slowest pages and the most common issues summarised.

Why does it ask why I am checking?+

Because the right first fix depends on the problem. The reason you choose decides which findings are shown first and what advice you get - server response for a slow site, render-blocking files and Core Web Vitals for rankings, caching and compression after a hosting move.

Does it show Core Web Vitals?+

Yes, if you tick Include Core Web Vitals. They come from Google PageSpeed Insights: real-visitor data from the Chrome UX Report when your site has enough traffic, plus a Lighthouse lab score.

Why are render-blocking scripts bad?+

A script in the head without async or defer stops the browser building the page until the script has downloaded and run. Adding defer lets the page render while it loads.

Is there a limit?+

About ten single-page tests every five minutes from one address, and a few whole-site scans every ten minutes of up to 200 pages each, so the tester cannot be used to flood a site.

Worth reading

All articles →
Core Web Vitals guide - how to fix LCP, INP and CLSCore Web Vitals in 2026: How to Fix LCP, INP and CLS (Developer's Guide)Failing Core Web Vitals? The 2026 thresholds for LCP, INP and CLS, why most sites fail them, and the fixes a developer applies first - in the order that moves the numbers most.10 min readPageSpeed score rising from 62 to 90 after fixing unused JavaScript and LCP render delay in Next.jsHow We Fixed Unused JavaScript and LCP Render Delay in Next.jsEach issue in our own PageSpeed report and exactly what we changed - code splitting, the fade-in that hid our headline, analytics on interaction, two fixes that backfired - plus e-commerce speed and security headers.9 min readCloudflare speed settings and a benchmark comparing gzip, Brotli and zstd compressionCloudflare Speed Settings That Help, and Brotli vs Zstd vs Gzip MeasuredOur own benchmark of gzip, Brotli and zstd (body size, requests per second, CPU), and the Cloudflare settings this site runs: what is on, what is off, and what a shop must never cache.7 min read

More Website Speed Tools

View all →
Core Web Vitals CheckerCheck LCP, INP and CLS with Google's real-user data and a lab test - and see the exact element behind each problem.TTFB TestMeasure time to first byte from 10 cities worldwide - DNS, connect, TLS and server time per location, with CDN cache status.HTTP/3 & Brotli CheckerSee whether a site serves Brotli, Zstandard and gzip, how much each saves, and whether HTTP/2 and HTTP/3 are on.