Critical rendering path minimized
Why it matters
The critical rendering path (ISO-25010 time-behaviour) is the chain of resources the browser must fetch and process before it can paint the first pixel. Each extra hop — a synchronous script in <head>, a monolithic render-blocking stylesheet, a sequential font request — adds a full network round-trip of latency. On mobile networks with 100–200ms RTT, three sequential blocking resources add 300–600ms of blank-screen time regardless of how fast your server is. This directly worsens FCP, LCP, and the user's first impression.
Severity rationale
Critical because every render-blocking resource in the critical path is a mandatory delay before any visual content appears, compounding latency on every page load.
Remediation
Shorten the critical path by eliminating render-blocking resources. Apply these three changes in src/app/layout.tsx or your root HTML:
- Inline critical above-fold CSS (under 14 KB) and defer everything else:
<style>{criticalCSS}</style>
<link rel="preload" as="style" href="/styles/main.css" onload="this.onload=null;this.rel='stylesheet'">
- Mark non-critical scripts as
deferorasync:
<script defer src="/js/app.js"></script>
<script async src="/js/analytics.js"></script>
- Verify the fix in DevTools Network: the critical path waterfall should show parallel fetches with at most 2 sequential hops before first paint.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Performance Core Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- iso-25010:2011 · performance-efficiency.time-behaviour — Time Behaviour
Taxons
History
- 2026-04-18·v1.0.0·Initial import from performance-core·automated