Slow first byte, but only on the first request — the fix
The first request to this page was slow and an immediate second request was fast. That is the signature of a cold start, not of a slow server.
Where this fits: performance in SEO
Performance is both a ranking signal (Core Web Vitals) and a conversion multiplier. Google measures real-user loading (LCP), interactivity (INP), and visual stability (CLS) — and slow sites lose visitors before analytics even registers them. Most performance issues concentrate in a few repeat offenders: unoptimised images, render-blocking resources, and third-party scripts. Fixing the top three usually moves the needle more than fixing the next thirty.
Why slow first byte, but only on the first request hurts your rankings
A real visitor arriving at a scaled-to-zero instance pays this cost once, and search engine crawlers hit cold instances disproportionately because they arrive at quiet times. It is worth knowing about — but it is not the problem 'optimise your server' describes, and acting on that advice would cost money without changing anything.
This is a low-severity issue: a polish item. Fix it in batches during scheduled maintenance; the win is cumulative quality, not a step change.
How to fix it
If the delay matters for this page, keep an instance warm — `min-instances: 1` on Cloud Run, provisioned concurrency on Lambda, or an always-on dyno. If it does not, this is safe to ignore: the server is not slow, it was asleep.
Performance best practices
- Serve images in modern formats (WebP/AVIF), sized to their container, with explicit dimensions.
- Inline critical CSS and defer everything else; eliminate render-blocking third parties.
- Set far-future cache headers on static assets and an ETag on everything.
- Preload the fonts and hero image; font-display: swap to avoid invisible text.
- Measure with real-user Core Web Vitals, not just lab scores — Google ranks on field data.
The full library: SEO best practices, by category.
Frequently asked questions
What does "Slow first byte, but only on the first request" mean?
The first request to this page was slow and an immediate second request was fast. That is the signature of a cold start, not of a slow server.
Why does slow first byte, but only on the first request matter for SEO?
A real visitor arriving at a scaled-to-zero instance pays this cost once, and search engine crawlers hit cold instances disproportionately because they arrive at quiet times. It is worth knowing about — but it is not the problem 'optimise your server' describes, and acting on that advice would cost money without changing anything.
How do I fix slow first byte, but only on the first request?
If the delay matters for this page, keep an instance warm — `min-instances: 1` on Cloud Run, provisioned concurrency on Lambda, or an always-on dyno. If it does not, this is safe to ignore: the server is not slow, it was asleep.
How serious is this issue?
This is a low-severity issue: a polish item. Fix it in batches during scheduled maintenance; the win is cumulative quality, not a step change. It belongs to the performance family of checks.
How do I find every page affected by this on my site?
Run a free Dr Urls audit: it crawls your site, detects slow first byte, but only on the first request on every affected page, shows example URLs, and generates a ready-to-use fix task. Re-scan after fixing to verify the issue is gone.
Does your site have this issue?
A free Dr Urls audit crawls your site, finds every page affected by slow first byte, but only on the first request, and hands you a ready-made fix task.
Check my site free