Measure your real time to first byte, the wait before your server sends anything back, and find out whether the problem is your hosting or your page. Free, no signup, and we tell you when your host is fine.
Takes about 10 seconds. We measure your site from our server in New York.
Disclosure: if this test finds your server is genuinely slow, we suggest managed hosting and earn a commission if you sign up. We only suggest it on that verdict. Most sites we test get told to fix something else, or nothing at all.
Looking up your site…
When someone opens your site, their browser sends a request and then waits. The length of that wait, before a single byte of your page comes back, is your time to first byte. Most people call it TTFB; plenty of tools call the same thing your server response time. It is one number made of three separate things:
That matters because only the middle one is your host's fault, and it is the only one changing hosts can fix. Most TTFB checkers hand you the total and let you guess. This test takes the other two apart.
Google treats 800ms as the boundary for a good server response, and that is where our "your host is slow" verdict sits too. Under 200ms is genuinely fast. Above 1.5 seconds, visitors feel it and it starts costing you traffic and sales.
| Grade | Visitor-facing TTFB | What it means |
|---|---|---|
| A | Under 200ms | Excellent. Nothing to fix here. |
| B | 200 to 500ms | Good. Comfortably above average. |
| C | 500 to 800ms | Acceptable, with room to improve. |
| D | 800ms to 1.5s | Below Google's bar. Visitors feel this. |
| F | Over 1.5s | Slow enough to cost you traffic and sales. |
For context, we measured 300 real WordPress sites picked at random from our own scan log. Half came in under 452ms, and one in ten was over 2.2 seconds. A "good" TTFB is rarer in the wild than the advice articles suggest.
We time your site three ways, because one measurement on its own lies:
Subtracting the first from the third leaves the part that is genuinely your server thinking. That is why a site in Australia and a site in Germany can get the same grade from us: we take the distance out.
Plenty of large, well-run WordPress sites take two or three seconds to build a page from scratch and nobody ever notices, because a cache sits in front and no visitor ever waits for it. A tool that grades the uncached number alone will tell those sites to move hosts. We tested that rule against real sites and it told Kinsta's own customers to leave Kinsta.
So we only say your host is the problem when both things are true: visitors are genuinely reaching your server, and your server is genuinely slow. If a CDN answered everything we sent, we say we can't tell you rather than grading Cloudflare and calling it your hosting.
Measured from a single location, so treat the absolute number as indicative and the comparison between the three requests as the real signal. Cross-check against WebPageTest or GTmetrix if you want a second opinion. We expect you to.
Run the test above first, because the answer splits cleanly in two and the fixes have nothing in common. If your TTFB is fine and the site still feels slow, the delay is happening after your server has done its job: images, fonts, scripts, and the theme's own rendering. No amount of hosting money fixes that.
If your TTFB is genuinely slow, it is almost always one of four things. Shared hosting where other sites on the same box are eating the CPU. An old PHP version. A database that has quietly grown a few hundred thousand rows of post revisions, orphaned metadata and expired transients. Or plugins that run a query on every single request, which is what related-posts widgets, live-stats dashboards and most security plugins do.
This one confuses people, and it is the clearest signal there is. Your front end can be cached; wp-admin never is. Every click in the dashboard is your server building a page from scratch, so a slow WordPress admin with a fast public site means the cache is doing the work and your server underneath it is struggling.
That is exactly what the third measurement in this test looks at. If you came here because your backend crawls, the "building from scratch" number on your results is the one to read. WooCommerce sites feel this worst, because carts, checkouts and account pages are uncacheable for the same reason wp-admin is.
In the order worth trying, cheapest first:
If you want the background on how hosting types differ before you spend anything, we have written up shared hosting, managed WordPress hosting, VPS hosting and cloud hosting separately.
Migrating a WordPress site to a new host is worth doing when the uncached number stays bad after you have done the free things above, or when your response times fall apart every time you get traffic. It is not worth doing because a review site said so, and it is definitely not worth doing if this test graded your server an A.
When it is warranted, the practical points are that most managed hosts will migrate the site for you at no cost, the move happens on their servers before DNS changes, and there is no downtime if it is done in that order. We only show a hosting recommendation on the one verdict that earns it, which is roughly one site in three of the ones we have tested.
No. TTFB is the wait before the first byte arrives. Page load time is everything after that: images, CSS, fonts, scripts, rendering. A site can have a 100ms TTFB and still take eight seconds to become usable. TTFB is the part your host controls, which is why it is the one we test.
Treat 800ms as the line you do not want to be on the wrong side of, and 200ms as the target if you are paying for good hosting. Across 300 real WordPress sites we sampled, half came in under 452ms and one in ten was over 2.2 seconds, so a mid-hundreds figure is normal rather than good.
Because a CDN answered every request we made, including the one built to bypass the cache. We never reached your actual server, so anything we printed would have been a measurement of the CDN. Try a URL that is never cached, like a cart or an account page.
Then the delay is on the page, not the server. Your server answered quickly; what comes after, meaning images, fonts, scripts and the theme's own rendering, is where the time is going. Changing hosts will not help with that.
Your front end can be cached; wp-admin never is. Every click in the dashboard is your server building a page from scratch, so a slow backend with a fast public site means the cache is carrying you and the server underneath is struggling. Read the "building from scratch" figure on your results.
The timing does, and the grade is meaningful for any site. The diagnosis is tuned for WordPress, so the advice is most reliable there. We tell you on the results panel whether we detected WordPress.
We fetch a handful of pages from it to time the responses. We do not publish it, and there is no signup or email required to use this.
Server response times vary with load, and a first request can be slower than the ones after it. We take the median of several samples for exactly that reason, but a site under heavy traffic will still bounce around. Run it a few times.
From our server in New York. That is a single location, so if your visitors and your server are both somewhere else the raw number will read a little high. The figure we subtract the network trip out of is not affected, and that is the one the verdict uses.
