November 1, 2026 · Muhammad Umar · More by Muhammad Umar
Shopify's Automatic Early Hints Explained
Shopify now scans generated HTML to auto-detect render-blocking files and preload them via Early Hints, beating hand-authored preload hints at scale.
On August 28, 2026, Shopify's performance engineering team published a detailed account of how it rebuilt Early Hints delivery for storefronts, and the backstory is as instructive as the result. An HTTP 103 Early Hints response lets a server tell the browser, before the final HTML arrives, which connections to open or which files to start fetching. Done well, it uses otherwise-idle waiting time. Done poorly, it competes with the real document for bandwidth and slows things down.
Why Hand-Authored Hints Fell Short
Shopify's earlier attempt, relying on hand-authored preload hints from theme code, had shown exactly that downside: modest gains on desktop with small preload sets, but pages with larger preload sets often received the main HTML document later, and on mobile, pageviews without Early Hints frequently outperformed ones with them. The team lacked the visibility to know which hints browsers were actually using, until Chrome's experimental Speculative Load Measurement API gave them exactly that: which resources were preloaded, whether each came from an Early Hints response, and whether the page used it.
Automatic Detection, Not Manual Tuning
With that visibility, Shopify replaced hand-authored hints with automatic detection. It reuses an existing HTML-transformation scan to identify resources that genuinely block rendering in the generated document: normal blocking stylesheets, skipping non-blocking media like print, and classic blocking scripts, skipping async, defer, or module scripts. It then serves hints for them via a cached 103 response at the CDN edge, adding no measurable processing overhead.
The Measured Impact
The rollout shipped in two steps, each measured separately. Automatic third-party preconnects alone, up to three per response, improved First Contentful Paint by 28ms and Largest Contentful Paint by 36ms at p75 across buyer traffic (56ms and 64ms at p90). A specific edge case paid off further: a common Adobe Fonts integration loads CSS from use.typekit.net, which itself imports a second stylesheet from p.typekit.net that the browser can't discover until it parses the first file. Preconnecting to both Typekit domains improved FCP by another 31ms at p75 on affected pageviews.
Adding automatic preloading of the blocking files themselves, on top of the preconnects, produced the larger gains: on pageviews where the browser reported actually using the preload, FCP improved by 76ms and LCP by 100ms at p75 (104ms and 145ms at p90; 44ms and 68ms at p50). Final-response timing didn't regress, meaning the browser started useful work earlier without the real document arriving any later.
Browser Support Still Varies
One caveat worth knowing if you're auditing performance across browsers: Chromium and Firefox act on preload links in a 103 response, but Safari currently only uses its preconnect hints and ignores the preloads, with WebKit support for that part still underway. None of this required any change from merchants or theme developers; it's a shift in what Shopify's CDN and rendering pipeline do automatically, and a useful case study in why sending more hints was never the right instinct in the first place.