Crystal Ball checks covered

RESPONSE_TIME_SLOW, server timing, hosting, caching

Guide detail

Choose Your Technical Level

This setting applies to the meaning, causes, and fix sections. Your choice carries to other Fix Library guides on this device.

Practical explanations and page-specific steps. Recommended for most readers.

What the flag means

Crystal Ball flags slow initial response time when the server is slow to begin sending the page. This is often called TTFB, or time to first byte.

This is a problem because every later part of the page waits behind that first response. Images, scripts, and design polish cannot move quickly if the castle gate opens slowly.

Common causes

Common causes include slow origin hosting, cache misses, redirect chains, expensive CMS work, overloaded databases, security filters, cold application starts, or server-side requests to outside systems. Scripts that run only after HTML arrives can slow rendering, but they do not directly explain a slow first byte.

What to check next

Check whether the issue appears on one page or every page using the same template. Review recent content, theme, plugin, deployment, and server changes, then compare the live output with a known-good page.

How to fix it

Confirm the warning first and make a backup before editing the live site. If the change involves templates, code, DNS, redirects, or server settings, switch to Intermediate or ask for help before proceeding.

  • Custom HTML/static: Check hosting response time, HTTPS redirects, cache headers, and server logs. Use lightweight pages, static caching, and a CDN where appropriate. Google's TTFB guidance explains the response-time signal.
  • WordPress: Enable page caching, remove heavy plugins, check slow hosting, and test with the theme temporarily simplified. Start with your host's cache tools and plugin audit before blaming the grimoire.
  • Shopify: Shopify handles the hosting layer, so compare routes and repeated tests before assuming the theme caused TTFB. Apps or integrations can matter when they affect server-side storefront work; product media and browser scripts usually affect later rendering instead.
  • Wix: Wix handles the hosting layer, so compare several pages and runs before escalating a response-time issue. Heavy apps, embeds, animations, and oversized sections may still slow later rendering even when the first response is healthy.
  • Webflow: Check redirects, the published host, and repeated public responses first. Third-party scripts can slow rendering after the HTML arrives, so diagnose them separately from a genuinely slow initial response.

Need help?

If the fix gets murky, visit Support and send the details. Bug reports and Crystal Ball questions are free support. Implementation and development work may be paid support, but we will tell you clearly before anything becomes paid. No surprise invoices from the tower.