Skip to main content
Beta: Front-End Checklist is currently in beta. Some issues are still being fixed. Thanks for your patience.

Minimize critical request chains

Reduce the number and depth of dependent resource requests that block the initial rendering of the page.

Utilities
Quick take
Typical fix time 20 min
  • Reduce the depth of dependent resource requests
  • Inline critical CSS to avoid extra network roundtrips
  • Use `preload` hints for essential assets found deep in the chain
Why it matters: Long chains of dependent requests delay the initial rendering of the page, as each resource must wait for its parent to be fetched and processed.

Rule Details

A critical request chain is a series of dependent network requests that are required for the browser to start rendering the page. For example, an HTML file loads a CSS file, which in turn loads a web font.

Code Examples

The Problem: A Long Chain

  1. index.html
  2. └── styles.css (discovered in HTML)
  3. └── font.woff2 (discovered in CSS via @font-face)

The Solution: Preloading and Inlining

1. Preload Deep Resources

Tell the browser about the font early in the index.html.

<head>
  <link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>
</head>

2. Inline Critical CSS

Avoid the first network request for CSS by inlining the styles needed for the above-the-fold content.

<head>
  <style>
    /* Critical CSS here */
    body { font-family: 'Inter', sans-serif; }
    .hero { height: 100vh; background: #000; }
  </style>
</head>

3. Avoid CSS @import

Never use @import inside CSS files, as it creates another level of dependency. Use <link> tags in HTML instead.

/* Bad: styles.css */
@import url("reset.css"); /* This creates a chain */

Why It Matters

  • Rendering Delay: Each "link" in the chain adds a network roundtrip, delaying the First Contentful Paint.
  • Network Bottlenecks: Multiple dependent requests can saturate the browser's request limit for a single domain.
  • Increased Latency: On mobile networks with high latency, each additional request in a chain significantly compounds the delay.
  • Resource Priority: Deeply nested resources are often discovered late by the browser, missing out on early download opportunities.

Best Practices

Use a real request waterfall in Lighthouse (opens in new tab) or WebPageTest to verify that critical assets are discovered earlier after the change, because this rule is about dependency order, not just total byte count.

Limit Chain Depth: Aim for a maximum depth of 2 or 3 for critical resources. ✅ Inline Small Assets: If a script or stylesheet is very small (e.g., < 2KB), consider inlining it directly in the HTML. ✅ Use HTTP/2 or HTTP/3: These protocols allow for better multiplexing, but minimizing dependencies is still crucial. ✅ Audit Third-Party Scripts: Third-party libraries often introduce long, hidden request chains.

Don't Use @import: It's one of the most common causes of deep request chains. ❌ Avoid Chained Redirects: Ensure that critical resources don't involve multiple server-side redirects.

Tools & Validation

  • Lighthouse (opens in new tab): Specifically lists "Critical Request Chains" in the Performance report.
  • WebPageTest (opens in new tab): Use the "Request Waterfall" to visually identify chains.
  • Chrome DevTools: The "Network" tab shows the initiator for each request, helping you trace the chain.

Support Notes

  • Network waterfalls differ by browser and connection profile, so evaluate critical request chains on throttled target browsers, not only on local desktop.
  • Framework preloading and CDN behavior can reduce or hide chains in some environments; verify the live path before treating a static dependency graph as final.

Verification

Automated Checks

  • Measure the affected page or flow in Lighthouse, PageSpeed Insights, or DevTools and confirm the targeted metric improves.
  • Inspect the network waterfall or performance timeline to confirm the intended resource or execution change actually took effect.

Manual Checks

  • Verify the change on a throttled mobile profile, not just local desktop.
  • If this rule maps to a budget or Web Vital, confirm the page now stays within that threshold.

Use with AI

Copy these prompts to use with your AI assistant, or install the MCP server to use directly from Claude, Cursor, or Windsurf.

Check

Verify implementation

Identify long chains of dependent requests that block the critical rendering path using Lighthouse or WebPageTest.

Fix

Auto-fix issues

Flatten the request chain by inlining critical resources or using preload hints for essential assets.

Explain

Learn more

Explain how critical request chains impact the Time to First Paint and how to optimize the rendering path.

Review

Code review

Review the routes, assets, and loading behavior that affect Minimize critical request chains. Flag exact files, requests, or rendering steps that add unnecessary network, CPU, or layout cost, and describe the measurement method used to confirm the issue.

Sources

References used to support the guidance in this rule.

Further Reading

Tools and supplementary material for exploring the topic in more depth.

PageSpeed Insights
pagespeed.web.devTool

Rules that often go hand-in-hand with this one.

Eliminate render-blocking resources

Checks for render-blocking CSS and JavaScript that prevent the initial page render

Performance
Reduce DOM size and complexity

Keep the DOM tree small and shallow to improve memory usage and rendering performance.

Performance
Enable HTTP/2 or HTTP/3

Use modern HTTP protocols to enable request multiplexing and reduce network latency.

Performance
Enable browser caching

Cache-Control and ETag headers are properly configured for static resources.

Performance

Was this rule helpful?

Your feedback helps improve rule quality. This stays internal for now.

Loading feedback...
0 / 385