Website Speed Test

Check load time, TTFB, DNS, connect time, and performance rating for any URL

Try:

Frequently Asked Questions

TTFB (Time to First Byte) is the time from when a client sends an HTTP request to when it receives the first byte of the response. It includes DNS lookup, TCP connection, TLS handshake, server processing, and the start of the response transfer. A good TTFB is under 200ms. TTFB is one of the most important indicators of server performance and is used as a Core Web Vital signal by Google.
Google recommends a total load time under 2.5 seconds (LCP). For server response (TTFB), under 200ms is excellent. For most websites: under 500ms total is excellent, 500ms–1.5s is good, 1.5s–3s is average, 3s–5s is slow, and over 5s is very slow. Faster pages have lower bounce rates and better SEO rankings.
DNS lookup time is how long it takes to resolve the domain name to an IP address. This usually takes 10–100ms. A slow DNS (over 200ms) can be improved by switching to a faster DNS provider (e.g. Cloudflare 1.1.1.1, Google 8.8.8.8) or using DNS caching / CDN services.
This tool measures server-side TTFB and response time using a direct HTTP request — it does not render JavaScript, CSS, or images. Tools like GTmetrix and Google PageSpeed Insights measure full browser rendering (including all assets). Use this tool to check raw server performance and TTFB, and browser-based tools for full page render metrics.
Key improvements: use a CDN (Cloudflare, BunnyCDN), upgrade your hosting plan, enable gzip/brotli compression, use HTTP/2 or HTTP/3, enable server-side caching, reduce TTFB by optimising database queries, minimise redirect chains, and keep your DNS TTL low. For front-end speed, minify JS/CSS, optimise images, and use lazy loading.
Website load speed is influenced by many factors: server response time (TTFB) — slow databases, unoptimised server-side code, or under-powered hosting; image sizes — uncompressed or oversized images are the most common bottleneck; JavaScript — large JS bundles block rendering; CSS — render-blocking stylesheets delay the first paint; number of HTTP requests; hosting quality; and geographic distance — a server in the US will respond slowly to users in Asia without a CDN.
Google's Core Web Vitals target an LCP under 2.5 seconds for a "good" rating. Research from Google shows that 53% of mobile users abandon a page that takes more than 3 seconds to load. As a benchmark: under 1 second is excellent, 1–2.5 seconds is good, 2.5–4 seconds needs improvement, over 4 seconds is poor. For e-commerce, every 100ms of improvement can increase conversion rates by up to 1%.
Core Web Vitals are Google's real-world performance metrics used as a ranking signal. Three metrics: LCP (Largest Contentful Paint) — loading performance; target under 2.5s. INP (Interaction to Next Paint) — responsiveness; target under 200ms. CLS (Cumulative Layout Shift) — visual stability; how much the layout unexpectedly shifts; target under 0.1. Failing Core Web Vitals can hurt your Google search rankings.
Server response time (TTFB) is a server-side metric — the time from when the browser sends a request to when it receives the first byte. It reflects server performance: hosting speed, database query time, and CDN caching. Total page load time is a browser-side metric — the full time until all resources have loaded and rendered. A server can have a 100ms TTFB but a 5-second total load time due to unoptimised images. This tool measures TTFB only.
Reducing page size delivers faster downloads: compress images — convert to WebP or AVIF; minify CSS and JavaScript; enable gzip or Brotli compression on the server — Brotli achieves 20–26% better compression than gzip; use a CDN to serve assets from edge locations; lazy-load images with loading="lazy"; and remove unused dependencies from JavaScript bundles.

About This Website Speed Test

This free Website Speed Test sends a real HTTP request from our server to any URL and measures every phase of the connection — DNS resolution, TCP handshake, TLS negotiation, Time to First Byte (TTFB), and total response time. Results also include response size, HTTP status code, server headers, and an overall performance rating.

When to use this tool

  • Check how fast a website responds from a data-centre connection
  • Diagnose high TTFB caused by slow server-side processing
  • Compare hosting providers or CDN configurations objectively
  • Verify that caching headers or a CDN are reducing response time

Timing Metrics Reference

MetricExcellentGoodPoor
TTFB< 200 ms200–800 ms> 800 ms
Total Load Time< 1 s1–3 s> 3 s
DNS Lookup< 100 ms100–300 ms> 300 ms
TLS Handshake< 100 ms100–300 ms> 300 ms

Related Internet Tools

Ping Traceroute HTTP Headers Port Scanner

Related Articles

In-depth guides and technical articles.

View all →
Internet Aug 7, 2026
Your Lighthouse Score Is 95 and Your Users Still Complain the Site Is Slow — Lab Data, Field Data, and Why They Diverge
A Lighthouse score of 95 and a poor real-user experience aren't contradictory — Lighthouse simulates a clean browser state on standardised throttled conditions, while CrUX captures real users with extensions, background tabs, budget Android devices, and variable networks. Here's why INP (which replaced FID in March 2024) is now the most-failed Core Web Vital on JavaScript-heavy apps, how CDN geographic coverage creates lab vs field score divergence, and why the LCP image needs fetchpriority="high" to download as early as possible.
Internet Jun 22, 2026
What a Website Speed Test Actually Measures — and Why Two Tools Testing the Same URL Give Different Scores
Running the same URL through PageSpeed Insights and GTmetrix can produce completely different scores — not because one is wrong, but because they measure different things from different locations using different methodologies. Here's what website speed tests actually measure (TTFB, FCP, LCP, TBT, CLS), the lab vs field data distinction, why scores vary between tools, and which metrics actually correlate with rankings and user experience.
Internet Jun 17, 2026
Why a 95 Website Speed Score Doesn't Mean Real Users Experience It as Fast — Lab Data vs Field Data
A website scoring 95 in a lab speed test can still feel slow to real users — lab tests run on powerful servers with fast connections and empty caches, while real users are on phones, on 4G, seeing your site for the first time. Here's the lab vs field data distinction, what LCP/INP/CLS actually measure, why slow TTFB sets a floor no client-side fix can overcome, and the specific changes that move each Core Web Vital the most.
Internet Jun 17, 2026
Bufferbloat: Why a 300 Mbps Speed Test Result Can Coexist With Terrible Video Call Quality
A speed test showing 300 Mbps can coexist with terrible video call quality — because throughput and latency-under-load are different things, and bufferbloat is specifically a latency problem that high throughput doesn't fix. Here's how oversized buffers interact with TCP to cause latency spikes under load, why AQM algorithms like CoDel and CAKE fix this, and how to actually test for it.
Internet Jun 9, 2026
How Much Internet Speed Do You Actually Need? What Streaming, Video Calls, and Remote Work Require
Gigabit broadband is overkill for most households — a family of four watching 4K and video calling needs about 150 Mbps download. Here's what different activities actually require, why upload speed matters more for remote work than download, and how to run a speed test that reveals actual performance.