Reviewed November 3, 2026

Preload the LCP Image on Collection Pages, and Nothing Else

On most collection templates the Largest Contentful Paint element is the first product image in the grid, and it competes for bandwidth with the logo, the fonts, the other eleven product images, and every script the theme loads. Two levers help: fetchpriority equals high on that first image so the browser schedules it first, and, where the template cannot mark it up, a preload of the exact image file the browser will render. The discipline is singularity. Preload one resource, the LCP candidate, at the size actually served. Every extra preload dilutes the signal and spends bandwidth your shoppers pay for.

Preload has a reputation problem because it was oversold as a seasoning: sprinkle it on everything important. Browsers took the hint literally, fetched the whole sprinkle early, and the genuinely critical image arrived no sooner. Used surgically, on collection pages whose LCP image is predictable, it is still one of the highest return lines of markup a store can add.

Predictable is the key word. A collection page renders the same first slot for every visitor, which makes its LCP element knowable in a way a personalized homepage never is. That predictability is an asset most themes waste by marking every grid image eager and letting the browser sort it out.

Find the actual LCP element before hinting anything

Confirm the element in field attribution or a lab run with throttling: on collection pages it is usually the first grid image, but a large collection title block, a promo banner image, or a hero strip above the grid can hold the title instead. Hinting the wrong resource is worse than hinting none, because you have spent priority on a bystander and delayed the real element behind it.

Check mobile separately. The grid reflows, the first image may render at a different size or be swapped for a mobile crop by the theme's responsive markup. The LCP element at a phone viewport is the one your mobile score is graded on, and mobile is where collection LCP is won or lost for most stores.

fetchpriority first, preload when markup fights you

Where you control the image tag, fetchpriority high on the first image plus loading eager, and lazy loading on everything below the first row, is the clean modern answer, no extra request, no duplicate download risk. Reach for a link preload when the first image is injected by a component you cannot edit, and match the preload to the rendered resource exactly: same URL, same imagesrcset candidates, or the browser downloads the preloaded file, discards it as the wrong size, and downloads again, a double cost wearing a performance costume.

Never preload below the fold images, the cart drawer assets, or next page guesses in the same breath. Priority is a ranking, and a ranking where everything is first is a ranking of nothing. One high priority resource per page is a workable rule; two is an argument you should have to make out loud.

Measure it at the percentile that grades you

LCP is judged at the 75th percentile of real visits, good at 2.5 seconds or less, so evaluate the change on field data across a full window, segmented by collection and device. Lab runs are for confirming the hint is being honored, that the first image now starts earlier in the waterfall, not for declaring victory. A waterfall screenshot is a mechanism check. The percentile is the verdict.

Revisit after catalog changes. A new collection banner, a theme update that restacks the grid, or an app injecting a carousel above the products can quietly change the LCP element and orphan your hint on the wrong file. The hint is a claim about your page; when the page changes, re-derive the claim. It takes ten minutes and it is the difference between a maintained optimization and a superstition.

Frequently asked questions

What is a good LCP for a collection page?

The same threshold as every page: 2.5 seconds or less at the 75th percentile of real visits counts as good, up to 4 seconds needs improvement, beyond that is poor. Collections carry many images, so they need the priority discipline more, not a softer target.

Should I preload the font as well?

Fonts matter, but that is a separate, site wide decision and a different resource type. Do not let it ride along with this change. Ship the image priority fix alone, read its effect, then evaluate fonts with the same singularity rule applied to the one weight your headings actually use.

Does fetchpriority work in all browsers?

Support is broad in Chromium browsers and improving elsewhere, and where unsupported it degrades harmlessly to normal loading. That asymmetry, real gains where supported, no cost where not, is why it is the first lever and preload is the fallback.

Why did preloading make my LCP worse?

The classic causes are preloading the wrong size so the real file downloads twice, preloading several resources that then contend with each other, or preloading an image that is not the LCP element while delaying the one that is. Audit the waterfall for duplicate downloads of the same image at different sizes first.