Website speed check
Enter a URL and get a 12-metric report in 10–30 seconds — not a score for engineers, but a plain answer to what is slow and what to fix first.
The 12 metrics we check
Grouped into four areas: perceived speed, visual stability, resources and loading, and page structure. Each one comes with a measured value, a rating and a fix.
Perceived speed
Main content appears
LCP (Largest Contentful Paint)
How long a visitor waits before the main content shows up. This is the single biggest driver of perceived speed.
Server response
TTFB (Time To First Byte)
How long your server itself takes to handle a request, with network time excluded (so the number is usually small). If this is slow, every other optimisation gets dragged down with it.
First content shown
FCP (First Contentful Paint)
When anything first appears on the page. Past three seconds, visitors start to wonder if the site is broken.
Click responsiveness
TBT (Total Blocking Time)
How long the main thread is blocked during load, when clicks feel dead. A high number here reads as a laggy site.
Visual stability
Content stability
CLS (Cumulative Layout Shift)
How much elements shift around while the page loads. Jumping content causes misclicks and is the most overlooked UX killer.
Resources & loading
Total page weight
Total byte weight
How much data this single page makes visitors download. On mobile connections, weight decides how long they keep waiting.
Image weight & headroom
Image formats / compression / responsive sizes
How much of your page weight is images, and how many of them could still shrink into a more efficient format. Usually the heaviest part of a page, and the fastest win.
Unused code
Unused JavaScript / CSS
JavaScript and CSS that gets downloaded but never used. It costs bandwidth and browser parse time for nothing.
Render-blocking requests
Render-blocking resources
CSS and JS that must finish downloading before the page can render at all. These directly delay first paint.
Compression & caching
Text compression / cache TTL
Whether static assets are compressed and cached by the browser. For returning visitors, this decides what they re-download.
Page structure
Third-party load
Third-party script cost
Main-thread time consumed by analytics, chat widgets and ad scripts. Not your code, but your page pays for it.
Page structure size
DOM size / redirect chain
DOM node count and redirect chain length. Bloated structure slows rendering and style calculation, while extra hops make visitors wait for nothing.
How it works
Enter a URL
Any publicly reachable page works. Internal addresses and pages behind a login cannot be tested.
Pick a device
Mobile simulates a 4G connection, so results are stricter and closer to a real first impression.
Read the verdict
You do not need to fix all twelve at once. The report names the one to start with — then re-run to compare.
Frequently asked
Is it free? Do I need an account?
Free, with no signup or login. Results come from a public performance-testing service and are re-calculated and interpreted against our own scoring.
Why is mobile worse than desktop?
Mobile simulates a 4G connection and a mid-range device, which is standard practice. Compare mobile with mobile, not mobile with desktop.
Does this affect my search rankings?
Performance matters indirectly: it affects how long visitors stay and how Google judges page experience. These are technical metrics, not a ranking or traffic promise.
Can I fix the issues myself?
Mostly yes: compressing images and switching formats, enabling caching and compression, and trimming unused scripts resolve the biggest bottlenecks on most sites. For anything touching application architecture or servers, talk to us.
Want to know how to fix these — and what it would change?
Send us your report and we will come back with a fix list ordered by business priority.