Slow Pages and Response Time

The Slow Pages filter identifies URLs whose crawl response time is greater than 1,000 ms. This threshold is a Screpy investigation signal, not a Google ranking boundary and not a Core Web Vitals measurement.

Know what the metric represents

Screpy records how long its request took to receive the page response. The value can reveal slow application work, database queries, remote dependencies, cold caches, overloaded infrastructure, or network variability. It does not measure how quickly a real visitor sees or interacts with the rendered page.

Core Web Vitals use field-oriented metrics such as LCP, INP, and CLS. Review Google's Core Web Vitals guide before treating crawl response time as user-experience evidence.

Analyze slow pages step by step

1. Sort by response time and inspect several slow and fast examples.
2. Group URLs by template, route, content type, language, and parameter pattern.
3. Compare response time across repeated crawls to separate persistent slowness from a temporary spike.
4. Check status codes and response sizes; retries and large output can distort the pattern.
5. Compare crawler data with server timing, application monitoring, and real-user performance data.

If every product page is slow but articles are fast, investigate the product template and its data dependencies. If unrelated pages became slow in one crawl, first check infrastructure or crawl-time conditions.

Prioritize the right pages

Start with indexable landing pages that receive traffic, drive conversions, or represent a large template. A slow administrative or intentionally private URL does not deserve the same priority. Use the Quick Wins performance reports when business and visitor data are available.

Typical improvements include reducing server work, eliminating repeated queries, caching safe output, optimizing remote calls, compressing responses, and reviewing expensive middleware. Diagnose before optimizing; a crawler number alone cannot identify the bottleneck.

Example decision

Two hundred category pages exceed one second, while product and article pages remain fast. Samples show the same category template and successful 200 responses. Treat this as one template-level investigation, measure its backend operations, apply one controlled change, and compare equivalent URLs before and after.

Verify the improvement

Measure representative URLs multiple times, publish the change, and run another crawl under comparable conditions. Confirm the distribution improved, not only the single slowest row. Then check real-user metrics separately to determine whether visitors benefited.

Understand what response time measures

Crawler response time describes how long the server takes to answer Screpy's request. It is useful for finding slow routes and backend patterns, but it is not the same as Largest Contentful Paint, full page-load time, or a Core Web Vitals assessment.

Compare similar page types. A dynamic search page, cached article, and API-backed dashboard have different workloads. Review median behavior and repeated samples rather than treating one request as a permanent label.

Investigate slow groups

Group slow pages by template, host, query pattern, response size, and cache behavior. Then check:

• server processing and database queries;
• cache misses or cold starts;
• redirect and origin latency;
• third-party calls made before HTML is returned;
• unusually large server-rendered HTML;
• geographic differences between users and infrastructure.

If many pages became slow at the same time, look for a shared deployment or infrastructure event. If one template is consistently slower, inspect its application path.

What improvement should look like

After a backend fix, Slow Pages should fall across several crawls and representative URLs. Browser LCP may also improve when server response was the bottleneck, but it may remain unchanged if image discovery, client rendering, or third-party scripts dominate.

A faster crawler response with worse user metrics can happen when HTML arrives quickly but critical content renders late. Pair Screpy data with real-user or lab performance evidence. Web.dev's LCP optimization guide breaks the metric into server response, resource delay, download, and render delay.