Start here
Before you fix it: what this check means
Scavo measures the time to receive the page HTML. This does not include downloading images, running JavaScript, or drawing the finished page. Scavo reads the captured `load_time` for the HTML document request and classifies it against simple thresholds.
Why this matters in practice: reducing unnecessary waiting makes the page more comfortable to use, especially on slower connections.
Use this as evidence, not a final verdict. Visitors using different devices, locations, and connections may see different speeds. Check the live site first. Open the published page and ask your developer to inspect the reported request or setting Make one controlled change. Profile backend render path and remove slow blocking calls. Re-scan the same URL and compare the finding; check the feature yourself as well.
This check measures how long the initial HTML document request takes. It is your baseline "first response" signal before all scripts, images, and secondary resources finish loading.
What Scavo checks (quick version)
Scavo reads the captured load_time for the HTML document request and classifies it against simple thresholds:
- Pass:
< 1.0s - Warning:
>= 1.0sand< 3.0s - Fail:
>= 3.0s - Info: timing unavailable in this scan
How Scavo scores this check
Scavo assigns one result state for this check on the tested page:
- Pass: baseline signals for this check were found.
- Warning: partial coverage or risk signals were found and should be reviewed.
- Fail: required signals were missing or risky behavior was confirmed.
- Info: Scavo could not gather enough reliable evidence on this run to score pass/fail confidently.
In your scan report, this appears under What failed / What needs attention / What is working for html_document_load_time, followed by Recommended next steps and Technical evidence (for developers) when needed.
- Scan key:
html_document_load_time - Category:
PERFORMANCE
Why fixing this matters
Slow initial document response hurts every downstream metric: render start, interaction readiness, and user confidence. If the first HTML is late, the entire page lifecycle starts behind.
It is also one of the clearest operational health indicators for origin performance, caching effectiveness, and network path quality.
Common reasons this check fails
- High backend processing time (DB/API latency).
- Cache miss rates or weak edge caching.
- Redirect chains before document fetch.
- Server overload or regional latency issues.
If you are not technical
- Ask for first-byte and backend timing split on affected pages.
- Prioritize high-traffic and conversion-critical routes.
- Confirm if cache strategy is in place for public pages.
- Re-run Scavo and track median trend, not one isolated scan.
Technical handoff message
Copy and share this with your developer.
Scavo flagged HTML Document Load Time (html_document_load_time). Please reduce initial document response latency (origin/caching/redirect path), provide timing breakdown, and share before/after results on affected templates.If you are technical
- Profile backend render path and remove slow blocking calls.
- Improve cache hit rates (edge + application cache).
- Remove unnecessary redirects before final HTML response.
- Tune connection reuse, TLS, and server resource limits.
- Monitor p50/p95 document response over time.
How to verify
- Measure document request timing in browser network panel.
- Compare server timing/TTFB before and after changes.
- Validate no extra redirects for canonical routes.
- Re-run Scavo and confirm threshold class improves.
What this scan cannot confirm
- It does not include full asset waterfall completion.
- It does not directly diagnose root cause inside backend code.
- A single pass does not prove sustained performance under load.
Owner checklist
- [ ] Assign owner for document-response performance baseline.
- [ ] Track p50/p95 response timing weekly.
- [ ] Alert on sustained regressions (not one-off spikes).
- [ ] Re-evaluate after infrastructure or routing changes.
FAQ
Is this the same as full page load time?
No. It measures the initial HTML document only.
Is under 1 second always realistic?
It is a strong baseline target for many public pages, but architecture and region mix can affect feasibility.
Can a page still feel slow with good document time?
Yes. Heavy client assets or render-blocking scripts can still degrade full experience.
What should we fix first?
Start with cacheability and backend bottlenecks on top business pages.
Sources
Need a response-time triage worksheet (cache/origin/network split) for your team? Send support your slowest routes.