Start here
Before You Fix It: What This Check Means
Estimated full load prefers real browser load timing plus observed same-site resource completions, with header-based sampling as a fallback. In plain terms, this tells you whether users are likely to feel this page as fast, stable, and usable. Scavo builds a first-party asset sample from page HTML and runs HEAD probes with a strict time budget.
Why this matters in practice: degraded speed here often compounds into lower conversion and weaker user trust.
How to use this result: treat this as directional evidence, not final truth. Synthetic sampling may not fully match real-user device/network variability. First, confirm the issue in live output: verify directly in live production output with browser/network tools Then ship one controlled change: Shrink first-party JS/CSS/image payloads on critical pages. Finally, re-scan the same URL to confirm the result improves.
Background sources
TL;DR: Your page weight is too high, causing slow load times that drive users away and hurt search rankings.
Bounce probability increases 32% when page load time goes from 1 to 3 seconds, and 123% at 10 seconds (Google/Huckabuy). Conversion rates drop by 4.42% for each additional second of load time (WP Rocket). The average page loads in 2.5s on desktop but 8.6s on mobile (ToolTester, 2026) — meaning mobile users are already at the edge of abandonment before your page finishes.
What Scavo checks (plain English)
Scavo builds a first-party asset sample from page HTML and runs HEAD probes with a strict time budget.
Current model assumptions in this check:
- Up to 30 first-party asset candidates
- Up to 12 probes
- Probe budget ~6 seconds
- Throughput assumption: 10 Mbps (
1,250,000 bytes/sec) - Parallel request assumption: 6
Estimate combines:
- Initial document response time (
load_time) - Slowest sampled asset header latency
- Estimated transfer time from known
Content-Length - Uncertainty penalty when header coverage is incomplete
How Scavo scores this check
Result behavior:
- Pass: estimated full load
<= 2.5s - Warning:
> 2.5sand<= 5.0s - Fail:
> 5.0s - Info: low-confidence sampling (for example too few probes/sizes)
In your scan report, this appears under What failed / What needs attention / What is working for estimated_full_page_load, followed by Recommended next steps and Technical evidence (for developers) when needed.
- Scan key:
estimated_full_page_load - Category:
PERFORMANCE
Why fixing this matters
Users experience full pages, not just first-byte. Heavy first-party assets and slow request chains can quietly drag conversion and perceived quality even when basic uptime looks healthy.
This check is useful for prioritization: it points to routes where payload and request strategy likely need cleanup.
Common reasons this check flags
- Large unoptimized first-party assets.
- Too many critical-path requests.
- Missing
Content-Lengthon sampled assets (low confidence). - Slow origin/CDN response times amplifying total load estimate.
If you are not technical
- Prioritize pages with highest traffic or revenue impact.
- Ask for one-page summary: payload size, request count, largest first-party assets.
- Request staged improvements (quick wins first).
- Re-run scans and track estimate trend over time.
Technical handoff message
Copy and share this with your developer.
Scavo flagged Estimated Full Load Time (estimated_full_page_load). Please reduce first-party payload and critical request overhead, improve cache/compression where relevant, and share before/after waterfall + header evidence.If you are technical
- Shrink first-party JS/CSS/image payloads on critical pages.
- Reduce critical-path request count and chain depth.
- Ensure static assets expose reliable
Content-Lengthheaders. - Improve document response latency (backend + edge cache path).
- Recheck with synthetic/lab waterfall for exact route-level bottlenecks.
How to verify
- Compare known first-party bytes and sampled coverage before/after.
- Validate request waterfall in browser devtools or Lighthouse.
- Confirm estimate confidence improves (more valid header coverage).
- Re-run Scavo and verify estimated full-load class improves.
What this scan cannot confirm
- It does not download all assets or emulate every browser behavior.
- It is an estimate, not a complete RUM measurement.
- Third-party asset effects can be underrepresented in this model.
Owner checklist
- [ ] Assign owner for first-party payload governance.
- [ ] Track request count and bytes on core templates per release.
- [ ] Add budget alerts for bundle and media growth.
- [ ] Recheck after build-pipeline, CDN, or framework changes.
FAQ
Why is this different from HTML document load time?
HTML document timing measures initial response only. This check estimates broader page load pressure including sampled assets.
Why can confidence be low?
When probes fail or Content-Length coverage is weak, Scavo can only provide directional estimates.
Is this a replacement for Lighthouse?
No. Use both: this gives fast, recurring directional monitoring; Lighthouse gives deeper diagnostics.
What should we fix first?
Largest first-party assets and critical-path request bottlenecks on high-value templates.
Sources
- MDN: PerformanceNavigationTiming
- web.dev: Learn performance
- Google Lighthouse overview
- RFC 9110: HTTP semantics
Need a prioritized payload-reduction backlog from your top pages? Send support your largest first-party asset list.
