Shopify Critical Request Chains: Fix the PageSpeed Warning (2026)

Quick Fix with Thunder

What PageSpeed Means by Critical Request Chains

A critical request is a resource the browser treats as important for rendering the current page. A chain appears when one critical resource delays another: the HTML discovers the CSS, the CSS discovers a font, a blocking script delays the image markup, or a script loads another script before the page can become useful.

Newer Lighthouse reports call this the Network Dependency Tree. Older reports and many Shopify Community threads still call it avoid chaining critical requests. Either way, the practical question is the same: what resource is making the first viewport wait?

This diagnostic is not a Core Web Vitals field metric, but it often explains a weak Core Web Vitals report. Long chains increase load delay for LCP, delay First Contentful Paint, and make mobile scores swing wildly because slow phones feel each dependency more sharply.

The Shopify-Specific Chain You Usually See

A clean Shopify theme can still create a critical chain like this:

document
  -> theme.css
    -> storefront font file
  -> theme.js
    -> app embed script
      -> widget script
  -> hero image discovered late

The browser cannot paint the visible page until enough CSS is available. It cannot prioritize an image it has not discovered. It cannot respond quickly if app JavaScript grabs the main thread while the page is still loading. That is why request-chain work overlaps with render-blocking resources, main-thread work, and JavaScript optimization.

Step 1: Identify the Actual Critical Path

Run PageSpeed Insights, open the Network Dependency Tree or critical request chain section, and write down the deepest chain. Then open Chrome DevTools -> Network, disable cache, reload on mobile throttling, and sort by start time.

Do not fix every file in the waterfall. Look for high-priority resources that block the first viewport: global CSS, fonts, hero images, theme scripts in the head, app scripts, and third-party requests that start before the page is useful. If the warning points to 30 files but only one is above the fold, fix that one first.

For a broader workflow, use our Shopify speed audit guide before touching code. It keeps you from spending an hour on request chains when the bigger problem is oversized images or an app stack.

Step 2: Defer Non-Critical Theme and App Scripts

Scripts in the head can block parsing and create new critical requests. If a script is not needed to render the first viewport, defer it:

<script src="{{ 'theme.js' | asset_url }}" defer></script>

Use defer for scripts that need document order. Use async only for independent scripts such as simple analytics beacons. For app scripts you do not control, Thunder is safer because dependency-aware deferral prevents common breakage from blindly moving files.

Step 3: Preload Only the Real Above-the-Fold Asset

Preload is powerful because it changes discovery order. It is also easy to abuse. Preload the hero image only if it is the actual LCP element, or preload the critical font only if text rendering is blocked by a late font request.

{%- if template.name == 'index' and settings.hero_image != blank -%}
  <link
    rel="preload"
    as="image"
    href="{{ settings.hero_image | image_url: width: 1600 }}"
    imagesrcset="{{ settings.hero_image | image_url: width: 800 }} 800w, {{ settings.hero_image | image_url: width: 1600 }} 1600w"
    imagesizes="100vw"
    fetchpriority="high"
  >
{%- endif -%}

Never preload every carousel slide. Never preload a desktop image that mobile visitors will not use. The goal is one shorter chain, not a louder queue. If your LCP image is lazy-loaded, fix that too with loading="eager" and fetchpriority="high".

Step 4: Reduce Render-Blocking CSS

Shopify themes often ship one large CSS file for every template. That creates a simple but expensive chain: HTML waits for CSS before render, even if most of the CSS belongs to sections below the fold.

The safe manual path is to keep global layout CSS in the main file, then move heavy section CSS closer to the section that needs it. If your theme supports section-specific assets, use them for sliders, lookbooks, video sections, and complex product galleries.

{%- comment -%}Load section CSS only where the section appears{%- endcomment -%}
{{ 'featured-collection.css' | asset_url | stylesheet_tag }}

For deeper cleanup, follow our Shopify CSS optimization guide and unused CSS and JavaScript cleanup.

Step 5: Move App Embeds Out of the First Viewport

Reviews, bundles, subscriptions, chat, popups, and analytics tools often create extra dependency chains. They load a small boot script, then another script, then CSS, then an API call, then a widget. That chain can be fine below the fold but painful in the head.

In Shopify Admin, open Online Store -> Themes -> Customize -> App embeds. Disable anything that does not need every page. Then check product, collection, and cart templates for old app snippets. If an app is needed only on product pages, do not load it globally from theme.liquid.

This is also a good time to compare your stack against our app speed impact research and apps that slow down Shopify stores.

Manual Fix vs Thunder Fix

Retest the Request Chain

After each change, run the same URL again on mobile. Check whether the deepest chain is shorter, whether the LCP request starts earlier, and whether Total Blocking Time drops. If one number improves and another gets worse, inspect the waterfall before keeping the change.

For a complete plan, use the Shopify speed optimization guide. If you want automation instead of hand-editing theme code, compare Thunder’s optimization features or check current pricing.

References and Validation

For the underlying diagnostic, compare your report with Chrome's critical request chain guidance and the newer Lighthouse Network Dependency Tree language. For preloading, use web.dev's responsive image preload guidance.

Shopify Community examples usually show the same pattern: merchants chase the warning after adding apps, page builders, sliders, or heavy hero media. The winning fix is not more preload tags. It is removing unneeded dependencies, deferring scripts, and making the first visible resource obvious to the browser.