CiteSite AIFree tool
Website speed checker
How long a page takes to answer, how much of it is readable without running JavaScript, and what a crawler working to a time budget comes away with. One request, no browser — the way an AI answer engine reads your site.
One request, no browser, no JavaScript — the same way an AI crawler reads a page. This is not a Core Web Vitals score and will not match one.
This is not a Core Web Vitals score
Saying so first, because the number above will not match the one Google gives you and it would be easy to conclude that one of the two is broken. Neither is. PageSpeed Insights runs your page in a browser and reports what a person experiences. This makes a single request and reports what arrived.
The reason to measure it that way is that a growing share of the traffic that decides whether you get cited is not a person. An answer engine fetching your page does not wait for fonts, does not decode your hero image, and in most cases does not execute a line of your JavaScript. It reads the markup it was handed and moves on. So the honest way to ask “what does a crawler get from this page” is to do what the crawler does.
The number most speed tools do not report
Readable content: how much of the document is text a machine can read without executing anything. A modern framework can serialise its entire data payload into the page and still ship a beautiful result to a browser. For a reader that is fine. For a crawler that does not hydrate, a page which is four percent text is a page with almost nothing to quote.
This is the failure that hides best, because every human test of it passes. The page looks right, the content is there, your colleagues confirm it. The only way to see it is to look at what arrives before anything runs.
Why response time carries the most weight
A crawler works to a budget. A page that takes three seconds to answer risks being abandoned before it is read, and no amount of careful image sizing helps a page that was never fetched. That is also why a bad response time caps the score here rather than being averaged away: a page a crawler may give up on cannot honestly be reported as healthy.
Time to first byte and total time are separated for the same reason. The first is your server thinking — an uncached template, a query on the page, a cold function. The second adds the body coming down the wire. They have completely different fixes and a single number hides which one you have.
What this does not check
- Anything that happens after load. No rendering, no layout, no interaction. A page whose content is injected by JavaScript will look sparse here, and that is a finding rather than a false negative.
- The weight of your images, scripts and stylesheets. It counts what the document references but does not fetch them, so “document size” is the HTML alone.
- Real-world conditions. One request from one server on a good connection. Your readers are on trains.
And if an answer engine cannot fetch the page at all, none of this matters yet. Check which crawlers your robots.txt allows first, then come back to how fast it answers them.
Questions
- Why does this not match my PageSpeed Insights score?
- Because it is measuring something else. PageSpeed loads your page in a real browser, runs the JavaScript, paints it and reports what a person waiting on a phone experiences. This issues one HTTP request and reads the HTML that comes back. There is no Largest Contentful Paint here and there cannot be, because nothing was painted. Both numbers are real; they answer different questions.
- Then why would I use this instead?
- Because an answer engine is not a person. OAI-SearchBot, PerplexityBot and the rest do exactly what this does: one request, read the markup, leave. They do not wait for your hero image to decode and most of them do not run your JavaScript. If you want to know what a crawler comes away with, measuring a browser tells you the wrong thing.
- What is the readable content percentage?
- How much of the document is text a machine can read without executing anything. A page that is 2% text and 98% script tags looks perfect to a reader and gives a crawler almost nothing to quote. It is the most useful number here for AI search, and the one no conventional speed tool reports, because for a browser it does not matter.
- Is server response time really worth 30% of the score?
- For this purpose, yes. A crawler works to a request budget, and a page that takes three seconds to answer risks being abandoned before it is read at all. Tidy images do not help a page that never gets fetched. A bad response time also caps the overall score, because reporting such a page as healthy would be misleading.
- It says my caching is missing but my CDN definitely caches.
- This reads the Cache-Control header on the HTML document itself. Plenty of setups cache assets aggressively and send the document with no directive at all, which leaves every crawler and intermediary to guess. That is the specific thing being reported, and it is worth a header even when everything else is already cached.
Related
Check whether a page is quotable once it is fast enough to be read, and read what each crawler is for.
A fast page that no engine cites is still invisible. Speed decides whether a crawler finishes reading you; what it finds when it gets there decides whether you are named. CiteSite asks the engines directly, on a schedule, and records the provenance of every answer.