Quick Fix with Thunder
Thunder improves common Shopify resource loading patterns automatically, including Core Web Vitals pressure from images, scripts, fonts, and render-blocking assets. Use it for the baseline, then reserve manual preload tags for the few assets that are truly critical on a specific template.
What PageSpeed Means by Preload Key Requests
A preload tells the browser: this resource matters soon, start fetching it early. PageSpeed surfaces preload opportunities when the browser discovers an important request late in the waterfall. On Shopify, the usual candidates are a self-hosted font, a hero image referenced from Liquid or CSS, or a CSS file required to paint the first view.
This warning overlaps with Core Web Vitals because late discovery can delay Largest Contentful Paint. Google’s LCP guidance says good LCP is 2.5 seconds or faster for at least 75% of visits, and one major LCP subpart is resource load delay. Preloading can reduce that delay if the resource is truly critical.
It can also backfire. If you preload five fonts, three images, app CSS, reviews, and a slider script, you have not prioritized. You have made a louder queue. For broader context, read the Shopify resource hints guide and the critical request chains guide.
Good and Bad Shopify Preload Candidates
| Asset | Preload? | Reason |
|---|---|---|
| Homepage hero image | Often yes | Likely LCP image and needed in the first viewport. |
| Main product image | Sometimes | Useful when it is the LCP element and discovered late. |
| Primary above-the-fold font | Sometimes | Useful for self-hosted fonts that affect visible text. |
| Below-the-fold collection images | No | These should usually be lazy-loaded, not preloaded. |
| Review widget script | No | Usually not needed before the first render. |
Manual Step-by-Step: Fix Preload Key Requests on Shopify
1. Confirm the resource is used above the fold
Open PageSpeed Insights, identify the suggested resource, and ask whether shoppers need it in the first viewport. If the answer is no, do not preload it. Consider lazy loading or delaying it instead. If the resource is the hero image or primary font, keep going.
2. Preload the likely hero image
For a Liquid-controlled hero image, place the preload in the document head or section logic only when that section appears above the fold. Also render the actual image with eager loading and high priority.
<!-- In theme.liquid or a hero section rendered first -->
<link
rel="preload"
as="image"
href="{{ section.settings.hero_image | image_url: width: 1600 }}"
imagesrcset="
{{ section.settings.hero_image | image_url: width: 750 }} 750w,
{{ section.settings.hero_image | image_url: width: 1100 }} 1100w,
{{ section.settings.hero_image | image_url: width: 1600 }} 1600w"
imagesizes="100vw"
fetchpriority="high"
>If this is your LCP problem, the hero image preload guide and LCP request discovery guide go deeper.
3. Preload only critical self-hosted fonts
Font preloads are useful only when the font file is used immediately and the URL matches the font requested by CSS. Use crossorigin for font files. Pair this with font-display: swap so text does not stay invisible while the font loads.
<link
rel="preload"
href="{{ 'brand-regular.woff2' | asset_url }}"
as="font"
type="font/woff2"
crossorigin
>
@font-face {
font-family: 'Brand';
src: url('{{ 'brand-regular.woff2' | asset_url }}') format('woff2');
font-display: swap;
}For more detail, see Shopify font optimization, reducing font load, and font-display swap.
4. Do not preload non-critical app assets
App assets often look important because they appear in the waterfall, but reviews, chat, recommendations, popups, personalization, and heatmaps are rarely needed before the first paint. Preloading them can make the score worse by stealing bandwidth and CPU from LCP. Use the third-party JavaScript guide to delay non-critical app work instead.
5. Watch for unused preload warnings
Browsers warn when a preloaded resource is not used shortly after load. That means the preload is probably too broad, conditional logic is wrong, the URL does not match, or the asset is not actually critical. Remove preloads that do not prove value in testing.
Manual Fix vs Thunder Fix
| Preload problem | Manual fix | Thunder fix |
|---|---|---|
| Hero image discovered late | Add conditional preload, eager loading, and fetchpriority high. | Improves common LCP and image-priority patterns automatically. |
| Font discovered late | Preload the exact WOFF2 file and use font-display swap. | Helps reduce font-loading pressure as part of the storefront baseline. |
| Too many preloads | Remove broad preloads and keep only first-viewport resources. | Avoids treating every asset as critical. |
| App resource waterfall is noisy | Delay non-critical app scripts instead of preloading them. | Optimizes app-resource timing for common Shopify performance issues. |
How Preload Connects to LCP, CSS, and Scripts
Preload is not a standalone speed strategy. It works when it shortens the critical path. If your LCP image starts late because it is hidden in CSS, injected by JavaScript, or lazy-loaded, a preload can help. If LCP is slow because the image file is huge, you also need modern image formats and right-sized sources. If render-blocking CSS delays paint, read fixing render-blocking CSS.
If scripts are the bottleneck, preloading a script is usually the wrong move. You may need to reduce execution time, defer non-critical scripts, or remove unused app code. The reduce JavaScript execution time guide is the better next step.
How to Confirm the Fix Worked
Test with PageSpeed Insights and the free Shopify speed test. In the waterfall, the preloaded asset should start earlier. In metrics, LCP should improve or at least stay stable. In warnings, you should not see “preloaded but not used” messages. Also test on mobile, because preload mistakes are most visible when bandwidth is tight.
For the full storewide approach, use the complete Shopify speed optimization guide and compare automation options in the best Shopify speed optimization apps guide.
FAQ
What does preload key requests mean on Shopify?
It means a critical asset is discovered later than it should be. On Shopify, that asset is often a font, hero image, critical CSS file, or script dependency that affects the first render.
Should I preload every important Shopify asset?
No. Preload only the assets needed for the initial viewport. Too many preload tags can crowd out the actual LCP image, CSS, and fonts, making performance worse.
Which Shopify assets are good preload candidates?
Good candidates include the likely LCP hero image, a self-hosted above-the-fold font file, and occasionally a critical CSS file. Below-the-fold images, app widgets, review scripts, and general theme JavaScript are usually poor candidates.
Can Thunder help with preload key requests?
Thunder can improve storefront resource priority and common Core Web Vitals loading patterns automatically. Manual preloads may still be useful for highly custom hero images or font setups.
How do I know if a preload worked?
Retest the same URL and check whether the critical resource is discovered earlier, LCP improves or stays stable, and no warning appears about preloaded resources not being used soon after load.
Fix Resource Priority the Practical Way
Preload key requests on Shopify only when the asset is critical to the first viewport. Thunder handles the common automated baseline, and manual preloads can fine-tune custom hero and font cases.
Install Thunder