Skip to main content

Avoid request proxies

Point your storefront domain straight at Shopify instead of routing requests through a CDN, a web application firewall, or custom middleware. Each layer in front of Shopify's edge is another hop the browser pays for on work that Shopify already does close to the shopper.

Anchor to WhyWhy

A request proxy sits between the browser and Shopify's servers. Every request from the browser goes to the proxy, which makes its own request to Shopify, receives the response, and forwards it back. This extra hop adds latency to every resource on the page, including the HTML document, API calls, and any assets routed through the proxy.

The added latency directly affects TTFB, the time until the browser receives the first byte of HTML, and LCP, because the LCP image or text can't render until the document arrives. If the proxy also handles asset requests, then FCP is delayed as well.

Proxies are sometimes used to cache responses, but this creates its own problems. Cached HTML can show stale product data, incorrect inventory, or outdated prices. Cache invalidation is hard to get right, and failures are often silent. RUM data from cached responses doesn't reflect the performance that customers get when the cache misses.

Shopify already runs a global CDN and edge network that handles caching, compression, TLS termination, and geographic distribution. Adding another proxy layer in front of this duplicates work that Shopify already does.

Anchor to HowHow

Anchor to Identify whether a proxy is in useIdentify whether a proxy is in use

A proxy sits between the browser and Shopify's origin servers. Here's how to detect one.

Check DNS resolution. Run dig or nslookup on your storefront domain. Shopify's documented setup points the apex record at a Shopify IP address and the www record at shops.myshopify.com, so anything else in the chain is a third party. Follow the CNAME chain rather than only reading the final address:

# Show the full CNAME chain and final answer
dig +noall +answer www.example.com

# Check the nameservers, which reveal a CDN managing the zone
dig +short NS example.com

If the nameservers belong to a CDN or the CNAME points at a proxy service's hostname instead of shops.myshopify.com, then requests are passing through that service before they reach Shopify.

Compare response headers between your domain and the origin. Open Chrome DevTools, go to the Network panel, and select the initial document request, or use curl -sSI against both hostnames. Compare the headers on your custom domain against the same page on the .myshopify.com domain, because the difference is the signal, not the presence of any single header:

  • A server header naming a proxy service rather than the value Shopify returns.
  • A via header, which names an intermediary explicitly.
  • x-served-by, x-cache, x-proxy-cache, or age headers that appear only on the custom domain.
  • Two layers of the same header, such as a duplicated x-cache or nested via entries, which means the request traversed two caching layers.

Compare TTFB with and without the proxy. If you can access the store directly through Shopify's URL, which is the .myshopify.com domain, then compare the TTFB of the proxied domain against the direct domain. Request the same path several times from the same network and compare medians rather than single runs, because cold connections and cache state both add noise. A consistent difference in TTFB points to proxy overhead. Measure this yourself for your own store rather than relying on a general figure, because the overhead depends on the proxy's location relative to both the visitor and Shopify's edge.

Anchor to Understand common proxy setupsUnderstand common proxy setups

Proxies appear in several configurations:

  • Custom domain routing through a CDN: the domain points to a CDN service, such as Cloudflare, Fastly, or Akamai, which forwards requests to Shopify. This adds a hop even when the CDN has no cache hit.
  • Security or WAF services: a web application firewall inspects traffic before forwarding it to Shopify. This adds processing time on every request.
  • Custom middleware: a server-side application that intercepts requests to modify headers, inject content, or apply redirects before passing the request to Shopify.

Anchor to Recognize a Cloudflare proxyRecognize a Cloudflare proxy

Cloudflare is the most common proxy placed in front of Shopify, and it's also the hardest to detect by reading headers, because Shopify's own CDN is Cloudflare-backed. A cf-ray, cf-cache-status, or server: cloudflare header is present on a normal Shopify response and proves nothing on its own.

Distinguish the two cases like this:

  • Compare against the origin. Request the same path on the .myshopify.com domain and on your custom domain, then compare headers. A merchant-owned Cloudflare zone in front of Shopify typically produces two cf-ray values, a duplicated cf-cache-status, or an additional age or via entry that the origin response doesn't have.
  • Check who controls the zone. Run dig +short NS on the domain. Cloudflare nameservers mean the zone is managed in a Cloudflare account, which is the prerequisite for proxying.
  • Check whether the record is proxied. In the Cloudflare dashboard, a record routed through Cloudflare's network is marked Proxied, and one that only resolves DNS is marked DNS only. For a Shopify storefront, DNS only is the configuration that sends traffic straight to Shopify's edge.

If the zone is proxied, then also review Cloudflare's content-modification features, which duplicate or conflict with work Shopify already does. Shopify already minifies and compresses theme assets with Brotli and gzip and serves images through its own CDN, so asset minification and image optimization features add processing without a corresponding benefit. Script-rewriting features are the higher risk: they change how and when theme JavaScript executes, which can break module loading and delay interactivity even when every metric on the document request looks unchanged.

Caution

Cache hit rate is usually the wrong thing to optimize here. Improving the hit rate on cacheable pages doesn't help the requests that matter most, because cart, session, and checkout traffic carries cookies and can't be served from a shared cache. Every /cart update, Section Rendering API call, and add-to-cart request bypasses the proxy cache and pays the full extra hop, and these are the interactions where shoppers notice latency. A high hit rate on collection and product HTML can coexist with slow cart interactions, so measure the cart and session paths separately before concluding the proxy is harmless.

Anchor to Remove unnecessary proxiesRemove unnecessary proxies

If the proxy exists only for caching or CDN purposes, then it's redundant. Shopify's edge network already provides these. Remove the proxy by pointing your domain's DNS directly to Shopify.

If the proxy exists for a specific function, such as WAF rules, header manipulation, or A/B testing, then evaluate whether that function is worth the latency cost on every request. In many cases, the same functionality is available through Shopify apps, theme code, or Shopify's built-in features without adding a network hop.

Anchor to If you must keep a proxyIf you must keep a proxy

Some setups require a proxy for compliance or security reasons. If you keep one:

  • Route only HTML document requests through the proxy. Let assets, such as images, CSS, and JavaScript, load directly from Shopify's CDN.
  • Set HTML cache TTL to five minutes or less.
  • Monitor cache hit rates and invalidation failures.
  • Compare RUM metrics for cached and uncached page loads so that you know what real performance looks like.

Anchor to Fix the real performance problemsFix the real performance problems

Proxies are often adopted to mask slow page loads rather than fix them. Address the root causes:

Anchor to ExamplesExamples

Anchor to Confirm a proxy from the command lineConfirm a proxy from the command line

Run the same three checks against your custom domain and against the .myshopify.com origin, and compare the pairs. Start with DNS, which tells you who's in the path before any request is made:

Resolve the chain

Terminal

# The full CNAME chain for the storefront hostname
dig +noall +answer www.example.com

# Who runs the zone
dig +short NS example.com

A CNAME that ends at shops.myshopify.com is the documented Shopify setup. A CNAME into a proxy service's hostname, or nameservers belonging to a CDN, means requests reach that service first.

Next, compare response headers on the same path:

Compare headers

Terminal

curl -sSI https://www.example.com/collections/all > proxied.txt
curl -sSI https://example.myshopify.com/collections/all > origin.txt

diff origin.txt proxied.txt

Read the diff, not either file on its own. A via entry, a second cf-ray, a duplicated x-cache or cf-cache-status, or an age header that appears only in proxied.txt are each a caching layer that the origin response doesn't have.

Finally, measure the latency the extra hop costs. Take several samples from one network and compare medians, because a single request tells you about connection state, not about the proxy:

Sample TTFB

Terminal

for host in www.example.com example.myshopify.com; do
echo "$host"
for i in $(seq 1 10); do
curl -sS -o /dev/null \
-w '%{time_starttransfer}\n' \
"https://$host/collections/all"
done | sort -n | awk 'NR == 5 {print " median", $1}'
done

Anchor to Interpret the resultInterpret the result

The three checks answer different questions, and you need all three before you act:

  • DNS resolves through a third party, headers are identical, and median TTFB matches. The zone is hosted elsewhere but the record isn't proxied, which is the DNS only configuration. Nothing to remove.
  • DNS resolves through a third party, headers show a second caching layer, and median TTFB is consistently higher on the custom domain. The proxy is in the request path and it's costing you that difference on every document request.
  • Headers show a second caching layer, but median TTFB is close. The proxy is still in the path. Measure the cart and Section Rendering API requests before concluding it's harmless, because those can't be served from a shared cache and pay the full hop every time.

Anchor to TestingTesting

  • Open the Network panel in Chrome DevTools and select the document request. Check the Timing tab to see DNS lookup, connection, TLS, and waiting (TTFB) broken out separately. A proxy adds visible time to DNS, connection, or waiting.
  • Compare the Timing breakdown for the same page loaded through the proxy domain and through the .myshopify.com domain. The difference in the Waiting (TTFB) row shows the proxy overhead.
  • Use the Network panel Waterfall column to check whether assets are also routed through the proxy. Assets should load directly from cdn.shopify.com, not through an intermediary.
  • Run a WebPageTest test from a geographic location near your target audience. Compare runs with and without the proxy to measure the latency difference under realistic network conditions.
  • Check the Console panel for mixed-content warnings or CORS errors that proxies sometimes introduce by modifying response headers.
  • Time the cart and session paths, not just the document. Add an item to the cart with the Network panel open and check the Timing breakdown for the /cart requests and any Section Rendering API calls. These bypass the proxy cache, so they show the proxy's uncached overhead.

Anchor to ReferencesReferences

Was this page helpful?