Key takeaways
- Multi currency Shopify speed comes down to one choice: convert prices on Shopify’s servers with native Markets, or convert them in the browser with a third-party app.
- Native Shopify Markets with Shopify Payments displays prices in the shopper’s presentment currency server-side, so there is no extra script and no price flicker.
- Most currency-converter apps inject render-blocking JavaScript and a geolocation call on every page, then rewrite prices client-side, which is a common source of layout shift.
- Rounding rules, the currency selector, geolocation redirects, and caching all affect Shopify multi-currency performance more than merchants expect.
- Fudge builds the selector and price formatting as native theme code, so your currency UI adds no widget weight and stays when you uninstall.
Selling in several currencies is one of the fastest ways to grow a Shopify store, but it is also one of the easiest ways to wreck your page speed. The problem is rarely the currencies themselves. It is how the prices get converted and where that work happens.
Getting multi currency shopify speed right is a matter of keeping conversion on Shopify’s servers and off the shopper’s device. Do that, and running ten currencies costs you almost nothing. Get it wrong with a heavy converter app, and every product page carries an extra script that rewrites prices after the page has already painted.
This guide explains why multi-currency setups hurt performance, how native Shopify Markets avoids the damage, and what to check to keep Shopify multi-currency performance in the green.
Why you can trust us
Jacques has 15+ years of development experience and has built international storefronts across hundreds of Shopify stores. We build Fudge, an AI storefront editor with a 5.0 rating on the Shopify App Store, so we work directly on the theme layer where currency selectors and price formatting live, and we see what a badly built one does to Core Web Vitals.
Why multi-currency setups hurt speed
A price on a product page looks trivial. Converting that price into the right currency for each visitor is not.
There are two places the conversion can happen. On the server, before Shopify sends the HTML to the browser. Or in the browser, after the page has loaded, using JavaScript that reads the shopper’s location and rewrites every price on the page.
The second approach is where the damage starts. A client-side converter has to do three expensive things on every page:
- Load its own JavaScript, often render-blocking, before prices are correct.
- Make a geolocation lookup to guess the visitor’s country, usually a network request to a third-party endpoint.
- Rewrite the DOM, finding every price element and swapping the text after the fact.
Each step costs time, and the third step costs stability. When prices are rewritten after the initial paint, the numbers change width, elements reflow, and you get Cumulative Layout Shift (CLS). Google measures CLS as a Core Web Vital, and the “good” threshold is 0.1 or less.1 A price that jumps from “$49” to “1,299 kr” after load is exactly the kind of shift that pushes you over that line.
Page speed maps directly to conversion, and it maps to rankings. For the wider picture on where stores lose time, see our state of Shopify performance report.
Native Shopify Markets vs currency-converter apps
Shopify has a native answer to this, and it removes the client-side work entirely.
Shopify Markets lets you sell into different countries and regions with local currencies. When a market uses a local currency, Shopify converts your store prices into the shopper’s presentment currency and renders them server-side, so the browser receives correct prices in the initial HTML.2 Combined with Shopify Payments, the shopper also pays in that presentment currency at checkout, with conversion handled by the platform.3
That is the key difference. Native Markets does the conversion before the page is sent. A converter app does it after the page arrives.
Here is how the two approaches compare on the things that decide speed.
| Factor | Native Shopify Markets | Currency-converter app |
|---|---|---|
| Where conversion happens | Shopify’s servers | The shopper’s browser |
| Extra JavaScript per page | None | Its own script, often render-blocking |
| Geolocation lookup | Handled by the platform | Usually a client-side network call |
| Price in initial HTML | Correct on first paint | Rewritten after load |
| Layout shift risk | Minimal | High, prices change after render |
| Checkout currency | Native, via Shopify Payments | Often reverts to store currency |
| Cost | Included in your plan | Monthly app fee |
The app route can look convenient because you install it and it “just works.” The hidden cost is a script on every page and a price flicker that hurts both CLS and shopper trust. For the full setup walkthrough, see our Shopify multi-currency setup guide.
How native Markets keeps prices fast
The reason native Markets is faster is not a trick. It is that the expensive work never reaches the browser.
Prices arrive already converted and already formatted in the HTML, so there is no render-blocking script waiting to correct them and no client-side price rewriting to cause a shift. The browser paints the right number once and never touches it again.
In your theme, prices still flow through Liquid’s money filters. The difference is that Shopify resolves the presentment currency on the server and the filter outputs the local value:
{% comment %} Renders in the shopper's presentment currency, server-side {% endcomment %}
<span class="price">{{ product.price | money }}</span>
No wrapper element, no data attribute for a script to find later, no “loading” state on the price. This is the shape you want every price on the page to take.
Rounding and price formatting
Converted prices are rarely clean. A $49.00 product at a live exchange rate might land on 1,287.43 in another currency, which looks broken next to a catalogue of round numbers.
Shopify Markets lets you set rounding rules per market, so converted prices resolve to sensible endings like .00 or .99 for each currency.3 This is a display and pricing decision, not a performance one, but it matters: rounding is applied server-side, so it costs nothing at render time and keeps your prices looking deliberate rather than machine-generated.
Formatting is the same story. The thousands separators, decimal marks, and currency symbol all come from Shopify’s currency format settings and render in the HTML. A converter app that reformats numbers in JavaScript is redoing work the platform already does for free.
The currency selector and its cost
Shoppers need a way to change currency or country, and this is where a native setup can still go wrong.
The selector itself should be a plain server-rendered form, not a JavaScript widget that fetches options on load. Shopify’s localization form gives you exactly that:
{% form 'localization' %}
{{ localization.available_countries | ... }}
<button type="submit">Update</button>
{% endform %}
A native selector like this adds a few elements of markup and no extra script. A third-party currency-switcher widget, by contrast, is often the single heaviest thing on the page: its own bundle, its own styles, and its own geolocation call. If you only take one thing from this guide, it is that the selector is where the weight hides.
Geolocation, caching, and duplicate content
Beyond the price on the page, three platform-level details shape multi-currency performance and SEO.
Geolocation redirects. Many stores auto-redirect visitors to a country-specific URL based on IP. Done client-side, this adds a lookup and a redirect before the shopper sees anything. Shopify Markets can suggest the right market with a lightweight recommendation instead of forcing a hard redirect, which avoids the round trip. Prefer a suggestion the shopper can dismiss over an automatic redirect that blocks the first paint.
Caching and the CDN. Server-rendered prices are cacheable, which is part of why native conversion is fast. Client-side converters undercut this by making the “correct” version of the page depend on JavaScript that runs after the cached HTML is served. Keeping conversion server-side keeps the CDN doing its job.
Duplicate content. Running the same catalogue across several markets can create near-identical pages that compete in search. Shopify’s Markets setup handles the URL structure and localized routing so each market resolves cleanly. The performance link here is indirect but real: fewer redirect chains and cleaner routing mean fewer wasted requests.
hreflang and locale considerations
Currency and language are separate axes, but they travel together in international stores.
At a high level, hreflang tags tell Google which URL serves which language and region, so the right version ranks for the right audience. Shopify Markets emits these for your configured markets when you use its localized URLs. You do not need to hand-build the tags, but you should confirm they are present, because a missing or wrong hreflang set sends search engines to the wrong regional page. For the strategic view of how markets, languages, and currencies fit together, see our Shopify Markets guide.
A checklist to keep Core Web Vitals green with multiple currencies
Use this to audit an existing multi-currency store or to plan a new one. The goal is the three Core Web Vitals thresholds: LCP within 2.5 seconds, CLS at 0.1 or less, and INP at 200 milliseconds or less.1
- Convert on the server, not the browser. Use native Shopify Markets with Shopify Payments so prices arrive correct in the HTML.
- Remove any client-side currency-converter app if native Markets covers your currencies. It is usually redundant weight.
- Render the currency selector as a server-side form, not a JavaScript widget.
- Set rounding rules per market so prices look intentional and are resolved server-side.
- Avoid hard geolocation redirects. Prefer a dismissible market recommendation over a blocking redirect.
- Check for layout shift on price elements. If a price changes after load, something is rewriting it client-side.
- Confirm
hreflangtags exist for each market so regional pages rank correctly. - Fix the theme’s baseline speed first. Multi-currency will not save a slow theme.
That last point matters. If your store is already slow, currency handling is not your first problem. Start with how to speed up a Shopify theme, and if large media is the culprit, lazy loading images is often the biggest single win.
Where Fudge fits
Native Markets handles the conversion. What it does not do is build the storefront UI around it: the currency selector, the price formatting, the way the whole thing looks in your theme. That work still lands on someone.
Fudge is an AI storefront editor that writes native theme code. You describe what you want, “add a currency and country selector to my header that matches my brand, and format prices for each market,” and it writes the Liquid, CSS, and JavaScript straight into your theme.
Because the output is native, there is no third-party currency widget loading on every page, no extra render-blocking script, and no geolocation call bolted on by an app. The selector is markup your store already understands, so it adds effectively no weight.
And because it is theme code, it survives uninstall. Cancel Fudge and the selector and formatting stay exactly where they are, the opposite of an app-rendered element that disappears when you remove the app. The same holds for anything else you build with the Fudge page builder.
FAQ
It only slows the store when conversion happens in the browser. Native Shopify Markets converts prices on Shopify's servers and sends them already formatted in the HTML, so there is no extra script and no page speed cost. Third-party converter apps are what add JavaScript and layout shift on every page.
Yes. Native Markets renders converted prices server-side, so the browser paints the correct number once with no client-side rewriting. A converter app loads its own JavaScript, makes a geolocation call, and rewrites prices after the page has painted, which is a common cause of Cumulative Layout Shift.
With Shopify Markets and Shopify Payments, store prices are converted into the shopper's presentment currency automatically using the current exchange rate, and the shopper pays in that currency at checkout. You can set rounding rules per market so converted prices resolve to clean endings rather than awkward decimals.
Usually not. If native Markets with Shopify Payments already covers your currencies, a converter app is redundant weight that duplicates work the platform does server-side. Removing it often improves Core Web Vitals with no loss of functionality.
A native selector rendered as a server-side localization form adds only a little markup and no extra script. The speed cost comes from third-party currency-switcher widgets that ship their own bundle and a client-side geolocation lookup. Build the selector as native theme code and its cost is negligible.
It can if regional pages are near-identical and lack correct signals. Shopify Markets handles localized URL routing and emits hreflang tags for your configured markets, which tells search engines which page serves which region. Confirm the hreflang tags are present so the right regional page ranks for the right audience.
Footnotes
-
web.dev, “Web Vitals” - the “good” thresholds are LCP within 2.5 seconds, CLS of 0.1 or less, and INP of 200 milliseconds or less, measured at the 75th percentile. https://web.dev/articles/vitals ↩ ↩2
-
Shopify Dev, “About Shopify Markets” - the presentment (customer) currency is what displays and what the customer pays in, while the store currency is used in the admin; with local currencies enabled, online store prices are converted to the customer’s currency automatically with market exchange rates. https://shopify.dev/docs/apps/build/markets ↩
-
Shopify Help Center, “Setting up currencies for markets” and “Currency conversions and exchange rates” - Shopify Payments converts prices to a customer’s local currency, merchants can customise rounding per market, and a country or currency selector lets customers choose their region. https://help.shopify.com/en/manual/markets/customizations/local-currencies ↩ ↩2