You test your store's speed from your office in London, Amsterdam, or Berlin.
PageSpeed Insights gives you a score of 45. Load time is 7 seconds. Your European customers are waiting almost 10 seconds for your store to become usable on mobile.
Meanwhile, someone testing the same store from New York sees it load in 2.8 seconds.
Same store. Completely different experience.
This happens because web performance is not a single thing — it's a relationship between where your store's data lives, where your customer is, and how efficiently information travels between those two points.
Most Shopify performance guides focus on image optimization and app cleanup. Those matter. But for stores experiencing significantly worse performance in European markets specifically, the problem is often more fundamental — and the fixes are different.
This guide explains why European visitors experience slower load times, how to diagnose whether this is your specific problem, and what can actually be done about it.
Why Distance Matters More Than You Think
When a customer in Amsterdam visits your Shopify store, their browser sends a request to a server. That server sends back your store's content. The customer's browser assembles that content and displays your store.
The time between sending the request and receiving the first response is called Time to First Byte (TTFB). It's the foundation everything else is built on. If TTFB is slow, everything else is slow — no matter how well optimized your images are or how few apps you have installed.
TTFB is directly affected by physical distance. Data travels fast — close to the speed of light through fiber optic cables — but it doesn't travel instantly. The round trip between Amsterdam and a server in Virginia adds real, measurable latency. Add in routing hops, network congestion, and server processing time, and a request from Europe to a US-based server can add 100 to 200 milliseconds of unavoidable latency to every single request.
That doesn't sound like much. But on a page that makes 50 to 100 requests — fonts, scripts, images, stylesheets — that latency compounds. A 150ms penalty per request across 60 requests adds 9 full seconds to your load time.
Shopify's CDN — What It Covers and What It Doesn't
Shopify uses a global CDN (Content Delivery Network) powered by Fastly. This CDN caches and serves static assets — images, CSS files, JavaScript files — from edge servers distributed around the world, including in Europe.
This is good news. Your product images and theme assets should load quickly for European visitors because they're served from nearby CDN edge nodes.
But the CDN doesn't solve everything.
Dynamic content is not cached. Your store's HTML — the actual page structure — is generated dynamically by Shopify's servers for each visitor. That dynamic content is not served from CDN edge nodes. It has to travel from Shopify's origin servers to your customer's browser for every page load.
Third-party scripts are not on Shopify's CDN. Every external script your store loads — Google Analytics, Facebook Pixel, review app widgets, chat tools — is served from wherever that third party's servers are. If those servers are US-based and your customer is in Europe, each of those scripts adds cross-Atlantic latency.
DNS resolution adds time. Before any request can happen, your customer's browser has to resolve your domain name to an IP address. Your DNS provider's response time affects how quickly this happens — and not all DNS providers have fast European infrastructure.
How to Diagnose Your EU Speed Problem
Before making any changes, establish exactly what's happening.
Test from European locations specifically
Go to WebPageTest at webpagetest.org. This tool lets you run performance tests from specific locations around the world.
Run your store from:
- London, UK
- Frankfurt, Germany
- Amsterdam, Netherlands
Then run the same test from New York or Virginia.
Compare the results. Specifically look at:
Time to First Byte (TTFB) — The time until the first byte of your HTML arrives. If this is above 600ms from European locations but under 200ms from US locations, your origin server latency is the problem.
Start Render — When does the customer first see anything on screen? If this is above 3 seconds for European visitors, the page feels broken before it even loads.
Fully Loaded Time — When is every resource on the page finished loading? Compare EU vs US. A gap of more than 2 seconds indicates geography-related performance problems.
Waterfall Chart — Look at which resources are slow specifically for European visitors. Are third-party scripts taking twice as long? Is the initial HTML slow? This tells you where to focus.
Check your TTFB specifically
A good TTFB for any location is under 200ms. For EU visitors to a store with US-based infrastructure, 400 to 800ms is common. Above 1000ms is a serious problem.
If your TTFB from Europe is consistently above 400ms, geography is a significant factor in your performance problem.
Fix 1 — Optimize Your DNS for European Visitors
Your DNS provider is the first thing that happens when someone visits your store. If your DNS is slow to respond for European queries, it adds latency before any content even starts loading.
Many store owners use the default DNS that came with their domain registrar. These default DNS services vary widely in performance — particularly for European locations.
Cloudflare DNS (1.1.1.1) is consistently one of the fastest DNS providers globally, with strong European infrastructure. Switching to Cloudflare's DNS is free and typically takes under an hour.
If you're using Shopify's default subdomain (yourstore.myshopify.com), DNS is managed by Shopify. But if you have a custom domain, your DNS is managed by whoever you've set as your DNS provider — and this is worth optimizing.
Fix 2 — Move Third-Party Scripts to Load from European-Friendly CDNs
Every third-party script your store loads adds its own latency. For European visitors, scripts hosted on US servers add cross-Atlantic round trips.
Audit your third-party scripts
Open your store in Chrome, go to DevTools → Network tab, and filter by JS. Look at the domains each script is loading from. For the slower ones, check where those servers are located — you can use a tool like ping.pe to test response times from multiple global locations.
Load scripts asynchronously and defer non-critical ones
Scripts that load synchronously block your page from rendering until they finish loading. Converting tracking scripts and non-critical third-party scripts to load asynchronously (using the async or defer attribute) means your page can start rendering while those scripts load in the background.
For EU visitors where cross-Atlantic latency adds extra time to each script load, this difference is especially significant. A marketing pixel that takes 800ms to load from Amsterdam adds 800ms to your visible render time if it loads synchronously — and adds nothing if it loads asynchronously after the page is already visible.
This requires editing your theme code — specifically how scripts are added to your theme.liquid file. Done correctly, it can cut seconds from your perceived load time for EU visitors without affecting any functionality.
Consider self-hosting critical fonts
Google Fonts are served from Google's CDN, which has good global coverage. But for maximum performance, self-hosting your fonts on Shopify's CDN (which is optimized for your store's visitors) can reduce font loading time for EU visitors.
Self-hosting fonts requires downloading the font files, adding them to your theme assets, and updating your CSS. It's a developer task but a straightforward one.
Fix 3 — Implement Resource Hints for EU Visitors
Resource hints tell the browser to start fetching resources before it knows it needs them — reducing the latency impact of sequential resource loading.
Preconnect tells the browser to establish connections to third-party domains early, before the resources are actually requested. If your store loads scripts from Google, Facebook, and your review app — adding preconnect hints for those domains means the connection overhead is paid upfront, in parallel, rather than sequentially as each resource is encountered.
For EU visitors where each new connection to a US server has higher latency, preconnect is particularly valuable.
Preload tells the browser to fetch critical resources — your hero image, your main CSS, your key fonts — as early as possible. For your LCP (Largest Contentful Paint) element, which Google uses as a core metric, preloading the resource means it's available sooner and your LCP score improves.
Both of these are implemented in your theme's <head> section. Getting them right requires understanding which resources are actually critical for each page type — what to preload on a product page is different from what to preload on the homepage.
Fix 4 — Optimize Your Core Web Vitals for EU Conditions
Google measures Core Web Vitals from real user data in each geographic market. Your Core Web Vitals scores in the EU may be significantly worse than your global scores — affecting your search rankings specifically in European Google search results.
LCP (Largest Contentful Paint) for EU visitors
Your hero image is almost always your LCP element. For EU visitors, the image has to travel from Shopify's CDN edge node nearest to them. Shopify's CDN generally has good European coverage, but image optimization still matters — a smaller image loads faster from any distance.
Make sure your hero image is:
- Served in WebP format (Shopify does this automatically for supported browsers)
- Properly sized for the actual display dimensions (not a 2400px image displayed at 400px)
- Preloaded in your theme's head so it starts loading before the browser encounters it in the HTML
INP (Interaction to Next Paint) for EU visitors
INP measures how quickly your store responds to user interactions. For EU visitors with higher latency, JavaScript that makes network requests in response to interactions — adding to cart, opening menus, filtering products — feels slower because each request has more travel time.
Minimizing the number of network requests triggered by user interactions, and optimizing the JavaScript that handles those interactions, improves INP specifically for higher-latency visitors.
CLS (Cumulative Layout Shift)
Layout shift is caused by resources loading and pushing content around on the page. This affects EU and US visitors equally — but it's worth auditing alongside your other EU-specific fixes.
Fix 5 — Consider a Headless Architecture for EU Performance
If you're doing significant volume in European markets and performance is a meaningful competitive issue, a headless Shopify setup is worth serious consideration.
Headless means your storefront is built as a separate application — typically using Next.js — deployed on edge infrastructure that puts your store's HTML generation physically close to your customers. Instead of dynamic HTML being generated by Shopify's origin servers and traveling to your European customers, it's generated by servers in Frankfurt or Amsterdam and delivered instantly.
The performance difference is significant. A well-implemented headless Shopify store typically achieves:
- TTFB under 100ms from any location
- PageSpeed scores of 90+ consistently
- LCP under 1.5 seconds even from high-latency locations
This is a substantial technical project — not an afternoon of configuration. It requires rebuilding your storefront, ongoing maintenance, and meaningful initial investment. But for stores where performance directly translates to conversion rate and revenue, the math often works out clearly in favor of the investment.
The EU Performance Diagnostic Checklist
Step 1 — Measure Baseline ────────────────────────────────────────────── □ Run WebPageTest from Frankfurt, Amsterdam, and London □ Record TTFB, Start Render, Fully Loaded □ Run same test from New York — compare □ Note gap between EU and US performance □ Check Core Web Vitals in Google Search Console — filter by EU countries
Step 2 — Identify the Specific Problem ────────────────────────────────────────────── □ TTFB above 400ms from EU? → Origin server latency problem □ Third-party scripts taking 2x longer from EU? → Script loading optimization needed □ Fonts or CSS slow from EU? → Resource hint implementation needed □ EU Core Web Vitals significantly worse than global? → EU-specific optimization needed
Step 3 — Implement Fixes in Order ────────────────────────────────────────────── □ Optimize DNS for EU □ Convert blocking scripts to async/defer □ Add preconnect hints for third-party domains □ Preload LCP image □ Self-host fonts if beneficial □ Implement lazy loading for below-fold images
Step 4 — Measure Again ────────────────────────────────────────────── □ Run same WebPageTest from EU locations □ Compare before and after metrics □ Check if EU Core Web Vitals improve in Search Console (takes 4-6 weeks) □ Monitor EU conversion rate for improvement
text
What to Expect After Fixing EU Performance
The impact of EU performance fixes varies depending on how bad the baseline is. For stores with significant EU-US performance gaps: Typical improvements after optimization: TTFB: 600-800ms → 200-300ms Start Render: 4-6s → 1.5-2.5s Fully Loaded: 8-12s → 3-5s PageSpeed: 35-50 → 60-75
Conversion rate impact: EU conversion rates typically improve 15-35% after significant performance improvements for high-latency markets
text
When This Requires a Developer
The diagnostic steps in this guide — running WebPageTest, checking TTFB, reading waterfall charts — can be done by anyone. The fixes are a different matter.
Converting scripts to load asynchronously, implementing resource hints correctly, self-hosting fonts, optimizing theme code for performance — these require editing your Shopify theme files in ways that can break your store if done incorrectly.
More significantly, if your EU-US performance gap is large enough that a headless architecture is worth considering, that's a substantial technical project that requires experienced Shopify and Next.js development.
If you're seeing a significant performance gap between your EU and US markets and you're not sure what's causing it or how to fix it — I'm happy to run a diagnostic on your store and tell you exactly what's happening and what the realistic fix looks like.
