Slow server response (TTFB > 800 ms)
ttfb_slowShort answer
Time to First Byte is how long the browser waits before the first byte of HTML arrives. Glimana's crawler measured more than 800 ms on this page. TTFB is not a Core Web Vital and web.dev calls 0.8 s "a rough guide", but every other metric (LCP in particular) is stacked on top of it, so a slow server response is the first thing to look at when a page is slow. The usual causes are missing page cache, slow database queries, an overloaded PHP pool or a CDN that is not caching HTML.
Why it matters
TTFB is not a Core Web Vital; web.dev gives 0.8 s as "a rough guide". It's a clue for finding the source of slowness. Nothing can render before the HTML arrives, so a page with a 1.5 s TTFB cannot have a good LCP no matter how optimised its images are. Crawlers also budget time per site: a slow server means fewer pages crawled per day.
How Glimana detects it
During the crawl Glimana records the time between sending the request and receiving the first byte. The rule fires when the measured ttfb_ms is above 800 and the page returned 200. The evidence shows the measured value. One slow measurement can be noise (a cold cache, a backup running); the Keywords and Speed pages show whether the field data agrees.
Note
Glimana crawls from a European data centre. A server in Asia or South America will show a higher TTFB than your local users experience; compare with the CrUX TTFB on the Speed page before investing in server work.
How to fix it
- Find the affected pages in Glimana. Open Issues › Slow server response (TTFB > 800 ms). Every affected page is a row; open one to see the evidence Glimana recorded for it (the measured value, the offending element or the target URL). The same list sits on the task card under Tasks, and the page's own detail view under Pages shows its full signals.
-
Apply the fix on your platform.
Work through the chain in this order; each step is cheaper than the next.
- Page cache. The cheapest win: serve HTML from cache (WordPress cache plugin, Nginx FastCGI cache, Varnish, or the CDN's HTML caching). A cached page should respond in under 200 ms.
- Opcode cache and PHP-FPM. Make sure OPcache is on and PHP-FPM has enough workers (
pm.max_children); a saturated pool queues requests. - Database. Enable the slow-query log and look at the queries behind this page. Missing indexes and
SELECT *on large tables are the usual suspects. - CDN. If you use Cloudflare or another CDN, check that HTML is actually cached (
cf-cache-status: HIT) and that the origin is not behind a slow region. - Hosting. If everything above is in place and TTFB is still above 800 ms, the server itself is undersized.
Install a page-cache plugin (WP Rocket, LiteSpeed Cache, W3 Total Cache) and confirm it is caching this URL (look for the plugin's HTML comment at the end of the source). Use Query Monitor to find slow queries; plugins such as WooCommerce filters and related-post widgets are common causes. On shared hosting, consider a managed host or object cache (Redis).
Shopify controls the server; a slow TTFB on Shopify usually comes from theme Liquid that loops over large collections or many
{% render %}calls in a loop. Simplify the template, paginate collections and remove apps that inject server-side blocks.Add response caching (Laravel
Cache::remember, Symfony HTTP cache, Rails fragment caching) for anything that does not change per user. Profile the request (Blackfire, Xdebug, New Relic) and fix the slowest span first. Enable HTTP/2 or HTTP/3 and keep-alive on the edge. -
Publish and clear caches. Deploy, purge the CDN, then run Lighthouse again from the Speed page (or PageSpeed Insights) to confirm the lab number moved. Field data lags: CrUX reflects the change over the following 28 days.
- Verify in Glimana. Open the task under Tasks and click Mark as done. The affected pages are queued for a verification crawl within a few hours, and the task closes when the measured TTFB drops below 800 ms. If the check still fails, the task returns to New with a note; when it passes, the task is listed under Resolved technical issues on Impact reports. To check sooner, use Re-crawl affected pages on the issue.
How the fix is verified
Re-crawl; the task closes when the measured TTFB drops below 800 ms. Because TTFB varies, Glimana checks the next crawl rather than a single retry.
FAQ
Does TTFB affect rankings?
Not directly. Google uses Core Web Vitals (LCP, INP, CLS) in its page-experience signal; TTFB is one of the inputs to LCP, so a slow server pushes LCP over the threshold.