Early Hints at Shopify

What are Early Hints? Jump to heading #

Early Hints is an informational HTTP status code (103 Early Hints) that improves how servers and browsers talk to each other. They allow the server to send the browser a list of important resources (such as stylesheets or scripts) before the main content is ready. This advance notice lets the browser start requesting assets or opening connections while the server finishes its work. By using server think-time to fetch critical resources early, Early Hints can potentially speed up page loads.

As shown above, without Early Hints, the browser must wait for the server to generate the complete response before starting to load any resources. However, with Early Hints, the server can immediately serve partial response while it processes the main request, making better use of this waiting time.

Early Hints types Jump to heading #

There are two types of Early Hints:

• Preconnect Jump to heading #

This option indicates origins that the browser should establish connections to in advance. This can help reduce latency when the browser later needs to fetch resources from those origins.

• Preload Jump to heading #

Indicates resources that the browser should start downloading before the main response is received. This can be useful for critical resources that are needed to render content above the fold.

Browser compatibility Jump to heading #

Early Hints are supported by all major modern browsers. Each browser family handles Early Hints slightly differently:

How Early Hints look like Jump to heading #

When the browser sends a GET request, the 103 Early Hints will be received before the final 200 OK response. The Early Hints include Links to the origins or resources that should be preconnected or preloaded.

GET /main.html

HTTP/2 103 Early Hints
Link: <https://cdn.shopify.com>; rel=preconnect
Link: <https://cdn.shopify.com>; crossorigin; rel=preconnect
Link: <//my-store.myshopify.com/cdn/shop/t/1/assets/app.js>; as=script; rel=preload;
Link: <//my-store.myshopify.com/cdn/shop/t/1/assets/styles.css>; as=style; rel=preload

And after a few moments:

HTTP/2 200 
date: Wed, 28 May 2025 14:19:00 GMT
content-type: text/html; charset=utf-8
[...]

Early Hints and Cloudflare Jump to heading #

Shopify implements Early Hints through Cloudflare's edge infrastructure. This integration enables Cloudflare to cache and serve Early Hints responses closer to users, significantly reducing latency.

The flow shows how Early Hints work through Cloudflare's edge network:

1. Client sends an initial GET request to example.com, which is routed through Cloudflare
2. Cloudflare immediately responds with a 103 Early Hints from its cache and forwards the GET request to the origin server
3. While the origin processes the request:
   • The client begins preloading critical assets based on the Early Hints
   • The main request continues through to the database
4. Database processes the request and sends the response back to the origin server
5. Origin server sends the final 200 OK response to Cloudflare
6. Cloudflare:
   • Validates that the Early Hints are up-to-date
   • Forwards the 200 OK response to the client
   • Updates its cache if needed

How to use Early Hints at Shopify Jump to heading #

By default, Shopify automatically adds two preconnect resource hints:

Link: <https://cdn.shopify.com>; rel=preconnect
Link: <https://cdn.shopify.com>; crossorigin; rel=preconnect

Additionaly, merchants can add preload resource hints through Liquid code. There are two ways to do this:

1. preload_tag filter Jump to heading #

This filter generates two things:

1. An HTML <link> tag with rel="preload"
2. A Link header in the document response

This filter should be used sparingly. For example, consider preloading only resources necessary for rendering above-the-fold content.

The input to this filter must be a URL from one of the following filters:

• asset_url
• global_asset_url
• shopify_asset_url

The preload_tag filter requires an as parameter to specify the resource type:

{{ 'critical.css' | asset_url | preload_tag: as: 'style' }}
{{ 'hero.jpg' | asset_url | preload_tag: as: 'image' }}
{{ 'fonts/shop.woff2' | asset_url | preload_tag: as: 'font' }}

2. preload keyword argument Jump to heading #

The preload keyword argument can only be used with two Liquid filters:

• image_tag
• stylesheet_tag

When set to true, Shopify automatically adds a Link header with rel="preload" for the resource. This is particularly useful when you want to preload assets without adding the corresponding HTML <link> tag to your document.

Example usage:

{{ 'component-localization-form.css' | asset_url | stylesheet_tag: preload: true }}
{{ product.featured_image | image_url: width: 600 | image_tag: preload: true }}

Note that unlike the preload_tag filter, this method only generates the HTTP header and not the HTML tag.

Resource limits at Shopify and best practices Jump to heading #

Shopify allows preloading up to 10 different resources per page. Resources are prioritized in the following order:

1. Stylesheets (CSS files)
2. Critical resources (typically fonts)
3. JavaScript files
4. Images

When implementing Early Hints, focus on preloading above-the-fold content that impacts the user experience. Only preload internal files — Shopify does not allow preloading external files for security and privacy. And avoid preloading too many resources. Overloading the browser with requests can slow down the delivery of critical content.

Case Study: Impact of Early Hints on Shopify stores Jump to heading #

Recently, we analyzed how merchants use Early Hints and their impact on loading performance. Here's what we found:

Methodology Jump to heading #

To measure the effectiveness of Early Hints, we aggregated Real User Monitoring (RUM) data from Shopify stores. Our analysis tracked:

1. firstInterimResponseStart to identify if Early Hints are received
2. finalResponseHeadersStart to identify when the first byte of the document is received
3. The number of resource timing entries that were early-hinted
4. The device type

Based on these measurements, we clustered the pageviews into the following groups, split by device type:

• No Early Hints: pageviews where firstInterimResponseStart is 0 or NULL, and no resource timing entries were early-hinted
• 0 Preload Hints: when firstInterimResponseStart is greater than 0 and no resource timing entries were early-hinted
• 1-3 Preload Hints: when firstInterimResponseStart is greater than 0 and between 1 and 3 resource timing entries were early-hinted
• 4-6 Preload Hints: when firstInterimResponseStart is greater than 0 and between 4 and 6 resource timing entries were early-hinted
• 7+ Preload Hints: when firstInterimResponseStart is greater than 0 and 7 or more resource timing entries were early-hinted

Note: The metrics firstInterimResponseStart and finalResponseHeadersStart are only available in Chromium-based browsers. This means our analysis excludes data from Safari and Firefox users. This limitation is particularly relevant for mobile analysis because it excludes all iOS devices, which typically show better performance. As a result, our findings might be conservative compared to the actual performance improvements across all browsers.

Results on Desktop Devices Jump to heading #

Our analysis examines three key loading metrics across all percentiles (up to the 90th percentile to maintain visual clarity and avoid outlier-skewed distributions).

Time To First Byte (TTFB) Jump to heading #

We analyzed finalResponseHeadersStart to understand how Early Hints affects document delivery time. This metric is crucial because Early Hints introduces additional network operations that could potentially impact when the browser receives the actual document.

Our findings for desktop devices reveal a clear pattern: TTFB increases with the number of preloaded resources. Pages using either no preload hints or 1-3 preload hints consistently show the fastest TTFB values. This suggests that despite robust desktop network capabilities, aggressive preloading introduces overhead that delays document delivery.

Notably, pages with no Early Hints (neither preconnect nor preload hints) show elevated TTFB values. This correlation exists because when Cloudflare's edge nodes lack cached Early Hints for a specific page, they can't serve even the default preconnect hints. This often correlates with other caching layers are also missing on our server side. As a result, generating the document can be slightly slower, impacting when the browser receives it.

First Contentful Paint (FCP) Jump to heading #

The FCP analysis reveals similar patterns to TTFB, but with smaller variations between different preload configurations. While we observe some front-end rendering improvements, these gains don't fully compensate for the TTFB increases seen with more preloaded resources.

Consistent with TTFB findings, pages with 0 or 1-3 preload hints achieve the fastest FCP times, indicating that minimal preloading might be optimal for initial content rendering.

Largest Contentful Paint (LCP) Jump to heading #

LCP measurements show the most compressed distribution among our metrics, though the pattern persists: pages with 0 or 1-3 preload hints maintain the best performance. This suggests that while Early Hints can help with resource loading, preloaded resources wisely is crucial for optimal results.

Front-end improvements (FCP-FE and LCP-FE) Jump to heading #

To isolate the front-end rendering impact of Early Hints from network effects, we calculated two derived metrics:

• FCP-FE: First Contentful Paint - TTFB (finalResponseHeadersStart)
• LCP-FE: Largest Contentful Paint - TTFB (finalResponseHeadersStart)

These metrics help us understand how Early Hints affect the browser's rendering performance after receiving the initial document.

The FCP-FE analysis reveals that front-end rendering times remain relatively consistent across different preload configurations. However, we observe a slight degradation as the number of preloaded resources increases. This suggests that aggressive preloading might create additional browser overhead during the initial rendering phase.

The LCP-FE results show more pronounced benefits from Early Hints. Pages using Early Hints consistently achieve better LCP-FE times compared to those without Early Hints, indicating that preloading critical resources may help optimize the rendering of larger, more significant page elements. Interestingly, the performance difference between various preload configurations (preconnects vs 1-3 vs 4-6 vs 7+) is minimal, suggesting that the key benefit comes from enabling Early Hints rather than the specific number of preloaded resources.

These desktop results demonstrate that Early Hints can provide modest front-end performance improvements, particularly for LCP, in environments with robust network conditions and processing capabilities.

Results on Mobile Devices Jump to heading #

Mobile performance analysis is particularly important given the prevalence of mobile commerce and the challenges of slower networks and limited device capabilities. Our findings reveal some interesting contrasts with desktop performance.

Time To First Byte (TTFB) Jump to heading #

Our mobile TTFB analysis reveals an interesting pattern that differs from desktop results. While pages with Early Hints show slightly better TTFB values in the lower percentiles, pages without Early Hints actually show better TTFB from the 40th percentile onwards. This suggests that on mobile devices, the overhead of processing Early Hints might outweigh its benefits, particularly when network conditions or device capabilities are not optimal.

First Contentful Paint (FCP) Jump to heading #

Mobile FCP measurements align with our TTFB findings: pages without Early Hints consistently outperform those using Early Hints across all percentiles, regardless of the number of preloaded resources. This suggests that the processing overhead of Early Hints on mobile devices impacts not only document delivery but also extends to initial content rendering.

Largest Contentful Paint (LCP) Jump to heading #

The mobile LCP data shows more nuanced results compared to FCP and TTFB. Pages without Early Hints perform similarly to those using only CDN preconnect hints or minimal resource preloading (1-3 resources). However, performance degrades when preloading 4 or more resources, suggesting that aggressive preloading on mobile devices can negatively impact the loading of largest content elements.

Front-end improvements (FCP-FE and LCP-FE) Jump to heading #

The FCP-FE analysis reveals that Early Hints has a consistent negative impact on initial rendering times for mobile devices. The processing and network overhead introduced by Early Hints seems significant enough to slow down the rendering phase, even after accounting for network effects:

The LCP-FE analysis reveals a different pattern: rendering times remain relatively consistent across all configurations, including pages without Early Hints. However, we observe performance degradation in higher percentiles (p70 and above) when Early Hints are present, with the most significant impact happening when preloading 4 or more resources. This suggests that while Early Hints may not affect typical LCP-FE performance, it can negatively impact users with slower devices or more constrained resources.

Data limitations Jump to heading #

While our analysis provides valuable insights into Early Hints performance, it's important to acknowledge a key limitation: our data doesn't distinguish between critical and non-critical preloaded resources. While preloading critical assets might improve loading performance, preloading non-critical assets could introduce unnecessary network overhead and potentially slow down the page loading process. Since our analysis focuses on the quantity rather than the criticality of preloaded resources, these results should be interpreted with caution.

Best Practices for Early Hints Jump to heading #

Given our findings and data limitations, we recommend the following best practices when implementing Early Hints:

1. Focus on Above-the-fold Content

   • Only preload resources that are critical for rendering content visible in the initial viewport
   • Prioritize CSS and web fonts that affect initial rendering
   • Consider preloading hero images if they significantly impact LCP

2. Measure and Validate Impact

   • Before implementing Early Hints, set baseline performance metrics
   • After implementation, closely monitor the impact through the new Shopify's admin web performance reports

Remember that every store's needs and audience are unique, and what works for one may not work for another. The key is to make data-driven decisions based on your specific user experience metrics.

Conclusions Jump to heading #

Our analysis of Early Hints across Shopify stores reveals distinctly different impacts on desktop and mobile performance. On desktop devices, where network conditions and processing capabilities are typically robust, Early Hints can provide modest benefits when used judiciously. Pages using either no preload hints or limiting preloads to 1-3 critical resources consistently showed the best performance across all metrics. While front-end improvements were observed, particularly for LCP, the benefits decrease as the number of preloaded resources increases, suggesting that careful resource selection is crucial for optimal results.

However, mobile performance tells a different story. Our data shows that Early Hints can actually degrade performance on mobile devices, with pages not using Early Hints often outperforming those that do, particularly on high percentiles. This performance impact is evident across all metrics (TTFB, FCP, and LCP) and becomes more pronounced with additional preloaded resources. The processing overhead introduced by Early Hints appears to be particularly challenging for mobile devices, suggesting that for mobile-first experiences, traditional resource loading patterns might be more effective than aggressive preloading through Early Hints.

It's worth noting that when Early Hints was first enabled in 2022, its impact was more consistently positive because most page resources were served from cdn.shopify.com, making the default preconnect hints highly effective. However, with the evolution of Shopify's infrastructure, most resources are now served directly from merchants' domains, reducing the benefits of these preconnect hints and requiring a more targeted approach to resource optimization.

After analyzing this extensive performance data across desktop and mobile devices, we will conduct internal discussions to evaluate our Early Hints implementation strategy. Our focus will be on refining the current configuration options and improving the guidance we provide to merchants. Through these discussions, we aim to evolve our Early Hints implementation to better serve our merchants' needs while keeping Shopify's commitment to exceptional web performance.