Response time

It is a measure of server responsiveness, and consistently slow pages point to a hosting or backend problem worth fixing.

What this check measures

For each page, the crawler records the time to first byte: the delay between requesting the page and receiving the first byte of the response. This is the server's response time, not the full page load. It captures how quickly your server reacts, before any images, scripts, or styles are downloaded.

TTFB is not the whole loading picture

It helps to be precise about what this does and does not measure:

• TTFB is server responsiveness, one part of how fast a page feels.
• Full page load and the Core Web Vitals (like Largest Contentful Paint) measure the complete rendering experience in a real browser, which is a separate, more involved measurement.

This check focuses on TTFB because it is a clean, reliable signal of server health that the crawler can measure on every page during a normal crawl. Treat it as a server-speed indicator, not a full performance audit.

Why response time matters for SEO

• User experience. A slow first byte delays everything that follows, and slow pages lose users. Search engines watch those signals.
• Crawl efficiency. A slow server means search engines crawl fewer of your pages in the time they allot, which matters on larger sites.
• Page speed is a factor. Speed contributes to rankings, and TTFB is the foundation the rest of load time is built on.

Good TTFB targets

These are general guidelines. Real values vary by page type, hosting, and where the request comes from.

As a rough rule, keeping TTFB under about 800 ms is widely considered good.

What affects TTFB

• Hosting quality and server resources.
• Dynamic versus cached pages. A page built fresh on every request is slower than a cached or static one.
• Backend work, like heavy database queries on each request.
• Distance, since a server far from the requester adds latency. A CDN helps.

How to improve response time

• Add caching so pages are not rebuilt on every request.
• Use a CDN to serve content closer to users.
• Improve hosting if the server is underpowered.
• Optimize the backend, especially slow database queries on key templates.

What the crawler can and cannot tell you

The crawler measures the response time it gets from where you run the crawl, on your Mac. That is an excellent way to spot pages that are consistently slow relative to the rest of your site. It is not the same as what a specific user across the world experiences, and it is not a lab Core Web Vitals report. Use it to find the slow pages and the patterns; use dedicated field data for a full performance study.

How Crawlpit Monster reports it

Response time appears per page in the report, and the page table can be sorted by it to bring the slowest pages to the top. That makes it easy to find the handful of pages or templates dragging your server speed down.

Common mistakes

• Confusing TTFB with full page load. A fast first byte does not guarantee a fast full load, and the reverse.
• Reacting to one-off network variance. Look for pages that are consistently slow, not a single blip.
• Ignoring a slow template. If one template is slow, every page using it is slow, so fixing the template fixes many pages at once.

Frequently asked questions

Related