🖼️ Free · no signup · no app install · read-only
Which image is holding your first paint hostage?
We read your homepage and one product page exactly as your server sends them, take apart every <img> and every <link rel=preload>, and then measure the real byte size of up to six key images by requesting them directly. No guessing about seconds — just the structural reasons your images are slow.
Based on publicly available data only. Informational, not legal advice.
What this checks
- Whether the first content image in the page source carries loading="lazy" — a common, one-line way a theme delays its own opening image
- Whether that image gets a priority hint at all: <link rel=preload as=image> or fetchpriority="high"
- Missing srcset/sizes, which leaves the browser one candidate for every screen size
- Missing width/height or aspect-ratio, the usual source of layout shift
- Shopify CDN URLs served with no ?width= parameter, or asking for a file far wider than the width the tag itself declares
- The real byte size and content type of up to 6 key images — quoted only where the response really came back as an image
- How many content images after the first three still load eagerly
FAQ
Why don't you give me an LCP number in seconds?
Because we do not run a browser. A real LCP figure depends on the visitor's device, network and viewport, and a number we made up would be worse than none. We report the causes we can verify in the HTML — the lazy hero, the missing preload, the megabyte JPEG — and we quote the bytes we actually measured. Core Web Vitals rates an LCP of 2.5 s or less as "good"; fixing the items below is how you get there.
What can this tool not see?
We read the HTML as served and never execute JavaScript. Images injected by a slideshow script, a lazy-load library that swaps data-src at runtime, or an app block rendered client-side are invisible to us — and so are images referenced only from your stylesheet, because we do not fetch theme.css. We also ignore <img> tags sitting inside HTML comments and <noscript> blocks, since a browser with JavaScript on never loads those. Anything that needs a rendered page is marked "could not tell" with the reason attached, never guessed. Also: "first image" here means "first content <img> in the HTML source" — usually the hero on a Shopify theme, but a proxy for what renders first, not a measurement of it.
Do you need access to my store?
No. Everything comes from public URLs any visitor can request: your homepage, one product page, and direct requests to the image files themselves. No app to install, no access token, no login. One product page is also all we look at — the report is about the pages we read, not about your whole catalogue.
Want someone to fix the image pipeline properly?
We are a Shopify studio. The audit is free; the fix is yours to make — or ours to ship.
Other free tools
- ReviewGuard — Do your product reviews say where they came from?
- SpiderCheck — Is your robots.txt telling AI shopping agents to go away?
- HreflangAudit — Are your language versions helping each other, or competing in the same search results?
- LiquidSweep — Is your storefront printing a Liquid error at a customer right now?
- See all 29 free tools