Free tool · Web performance

Find out what your page really costs to load.

Enter a URL and we’ll fetch it the way a browser does — the document and everything it pulls in — then report what actually crossed the wire: response time, transfer size, compression, caching, what blocks the first paint, and which files are to blame.

Public pages only. No sign-up. We measure the page once and keep nothing but an anonymous aggregate.
Grade — · Performance

Test complete

Where the weight is

Heaviest resources

Hand it to ChatGPT or Claude and ask it to fix the issues for you.

Want the fixes done for you?

Troiana builds sites that are fast because of how they’re made, not because someone bolted a caching plugin on afterwards.

Talk to us
Under the hood

What WebSpeed actually measures.

Twenty-two checks in five categories. Every number below is measured, not modelled — bytes that crossed the wire, milliseconds the server took, headers exactly as they were sent.

Server & delivery

Time to first byte, whether text is compressed, whether the origin speaks HTTP/2, how many redirects stand between the URL you typed and the page you got, and whether static assets carry a cache lifetime worth having. This category is first because it is upstream of everything: no amount of front-end work shows up while the server is taking a second to answer.

Page weight

Total transfer size, request count, the size of the HTML document itself, and how much of the page belongs to somebody else. Weight is the most honest performance metric there is, because it is the one thing that does not improve when you happen to be testing from a fast connection near your own server.

Render path

How many stylesheets and scripts stand between the HTML arriving and the first pixel appearing, whether your fonts are allowed to hide your text while they load, whether third-party origins get a connection hint, and how large the DOM is. This is where a page that is technically light still manages to feel slow.

Images & media

Total image weight and its share of the page, how much of it is still JPEG or PNG where a modern format would be smaller, whether images declare their dimensions — the cheapest fix for a page that jumps while it loads — and whether the ones below the fold wait their turn.

Front-end hygiene

Whether CSS and JavaScript are minified, how much uncacheable code is inlined into the document, and whether the same file is being requested twice under different query strings. Individually small; collectively the difference between a page that was built and a page that accumulated.

What it doesn’t do

No Core Web Vitals, and here’s why.

WebSpeed does not report LCP, CLS or INP, and it never will without a real browser behind it. Those metrics are the outcome of an actual render — pixels painted, layout shifted, input handled — on actual hardware. Any tool that produces them from a server-side fetch is guessing and hoping you do not check.

What it measures instead are the causes sitting underneath them. A slow time to first byte is most of a bad LCP. Uncompressed text and render-blocking stylesheets are most of the rest. Images without declared dimensions are almost the entire story of CLS. Fix what WebSpeed finds and the vitals move, because you will have removed the thing that was making them bad — which is more than a number on a dial ever told you.

The two load-time figures are the one place we estimate, and they are labelled as estimates. The model is stated plainly: your measured time to first byte, plus your measured bytes at the profile’s throughput, plus one round trip per batch of parallel requests. It is arithmetic on real inputs. Use it to compare two versions of the same page, not as a promise about any particular visitor.

For rendered metrics and real field data from Chrome users, use PageSpeed Insights — it is free, it is good, and it is doing something we cannot. Use this when you want to know which specific bytes, headers and tags to go and change.

Questions

Common questions about WebSpeed.

How is this different from Google PageSpeed Insights?
PageSpeed Insights renders your page in a real headless Chrome, which is how it can report Core Web Vitals like LCP and CLS. WebSpeed does not render — it measures the network. It fetches your page and its resources the way a browser would and reports what actually crossed the wire: response time, transfer sizes, compression, cache headers, how many things block the first paint, and where the weight is concentrated. That covers most of what makes a page slow, it finishes in seconds instead of half a minute, and it never returns a different score for the same page twice.
Why doesn’t WebSpeed report LCP, CLS or INP?
Because we cannot measure them honestly without rendering the page, and we would rather report fewer numbers than invented ones. Core Web Vitals are the outcome of a real browser painting real pixels on real hardware. What WebSpeed measures are the causes underneath them — a slow server, uncompressed text, render-blocking stylesheets, oversized images, images with no declared dimensions. Fix those and the vitals move. The one place we do estimate is the two load-time figures, and they are labelled as estimates with the model stated on this page.
What do the load time estimates actually mean?
They project your measured numbers onto two connection profiles: Slow 4G at 1.6 Mbps with 150 ms latency, and cable at 20 Mbps with 28 ms latency. The model is your real time to first byte, plus the total bytes at that throughput, plus one round trip per batch of parallel requests — six at a time on HTTP/1.1, effectively unlimited on HTTP/2. It is arithmetic on measured inputs, not a simulation, and it is useful for comparing two versions of a page rather than as an absolute promise.
Does it test the whole site or one page?
One page — the exact URL you give it. Speed is a per-page property far more than a per-site one, and a homepage that loads fast tells you very little about the product page carrying twelve tracking scripts and a hero video. Run it on your homepage, your heaviest template and your most important landing page, and you will usually find they are three different stories.
Why is the score different from my PageSpeed Insights score?
Because it is measuring different things, from a different place, with different weights. Our server has its own connection and location, your CDN may serve it differently, and we weight causes rather than rendered outcomes. Do not try to reconcile the two numbers. Use PageSpeed Insights for Core Web Vitals and field data, and use WebSpeed to find out which specific bytes, headers and tags are responsible — then watch both numbers improve as you fix them.
Does the test store my URL or my data?
Only in aggregate, and never tied to you. We keep the hostname, the score, the page weight and the response time so we can publish research on how heavy the web has become. We do not store your identity, we set no cookie for it, and we never publish a named site’s result. The page we fetch is one you have already made public.
Can it test a staging site or a page behind a login?
No. WebSpeed fetches your page from our server exactly as a crawler would, so it can only reach URLs that are publicly available. Pages behind a login, an IP allowlist or a private network are unreachable by design — the same protection stops the tool being pointed at internal addresses.
It says my page is heavy but it feels fast to me. Who’s right?
Both, and that gap is the point. You are on a fast connection, near your server, with every asset already cached from the last time you looked. Your visitors are on mobile, further away, arriving cold. The measured transfer size is the number that does not care about any of that — it is what a first-time visitor on a bad connection has to download before they see anything.
Keep going

Speed is half the job.

A fast page that nothing can quote is still invisible. Once the numbers here look healthy, run the Troiana AI Readiness Audit to see whether AI search engines can actually understand and cite the page, and the SEO Recovery Engine if traffic is falling for reasons speed does not explain.

All of them live on the tools page. The work behind this one is our performance & infrastructure practice, and the sites it produces come out of web development.