VPS latency: Sweden vs Germany for Nordic users

You are choosing where to host, the shortlist is Stockholm or Frankfurt, and someone in the room has said "Stockholm will be faster for our Nordic users." They might be right. But that is an assertion, and you are spending real money, so here is how to turn it into a number you can defend, plus the part that decides whether the number matters at all: how many round trips your users actually pay for on a cold page load.

The physics floor: what distance alone forces

Light in single-mode fiber travels at roughly 200,000 km/s, a refractive index of about 1.5, which works out to close to 5 microseconds per kilometre one way. Round it and you get a rule you can do in your head: a link of D kilometres costs about D/100 milliseconds of round-trip time (RTT), because the packet makes the trip twice. This is the floor. No amount of money buys below it.

Take great-circle distances between the cities and divide by 100. That gives the best case a link could ever hit if fiber ran dead straight (it never does):

Two things stand out before you measure anything. Copenhagen is nearly a tie on distance — it sits between the two hubs. And for everyone else the floor favours Stockholm, but by single-digit-to-low-teens milliseconds, not the 50 ms gap people sometimes imagine.

Real RTT runs higher than the floor. Fiber follows rights-of-way, not straight lines, and every switch and router on the path adds a little. As a working assumption, observed RTT is commonly 1.4 to 2 times the great-circle floor. That is exactly why you measure instead of trusting the table.

How to measure it yourself (so you can repeat this)

Don't take a hosting company's word for latency, including ours. Two public tools give you reproducible numbers.

RIPE Atlas

RIPE Atlas is a global measurement network of probes hosted by volunteers and organisations. You can schedule a ping or traceroute from probes selected by country and have it hit your candidate endpoints. The results report minimum, median and maximum RTT — use the minimum, because that is the value least polluted by transient congestion and closest to the true path cost.

A one-off ping measurement from Swedish, Norwegian, Danish and Finnish probes to a target IP, using the command-line tools:

1. ripe-atlas measure ping --target stockholm.example.net --from-country se --probes 20
2. Repeat with --from-country no, dk, fi, and again against your Frankfurt target.

Set up one endpoint in each city you are comparing, run the same probe set against both, and compare the minimums side by side. That controls for the probe population, so the only variable left is the destination.

Looking glasses

Most carriers and internet exchanges run a looking glass — a web page that runs ping and traceroute from their routers. Point one hosted near your users at each candidate. It is less rigorous than a controlled Atlas run (you don't choose the source precisely), but it is instant and needs no account, which makes it a good sanity check.

Whatever you use, run it at several times of day. A path that is 12 ms at 03:00 and 30 ms at 20:00 is telling you something a single sample would hide.

Turning ping into milliseconds on screen

Here is the step most latency arguments skip. A user does not experience one RTT. They experience however many round trips it takes to open a connection and get an answer, and that multiplies your ping.

For a fresh HTTPS request to an origin, uncached:

1. TCP handshake — 1 RTT before you can send anything.
2. TLS handshake — TLS 1.3 completes the key exchange in 1 RTT (RFC 8446). TLS 1.2 needs 2. A returning visitor using TLS 1.3 session resumption can send data with the first packet (0-RTT), so the handshake cost disappears.
3. The request itself — 1 RTT to send the GET and get the first byte back, longer if the server has to build the page.

So a cold load over TLS 1.3 is roughly 3 RTT to first byte: TCP + TLS + request. Multiply your latency difference by that.

That is the honest shape of it. A 12 ms ping difference is 36 ms of extra wait on a cold page, and closer to 48 ms if you are still on TLS 1.2. Enough clicks and it is felt. For a Copenhagen user, where the floor gap is ~2 ms, the same maths gives 6–12 ms — below the threshold where anyone notices.

Where 20 ms is simply irrelevant

Before you optimise for RTT, check whether your workload pays for it at all. Plenty don't.

1. Anything behind a CDN. Static assets, images and cached pages are served from an edge node near the user. The origin's location stops mattering for those bytes, whether the origin is in Stockholm or Frankfurt. Latency only bites on requests that reach the origin.
2. Async and background jobs. Queued email, report generation, batch imports, cron work, webhook processing — nobody is watching a spinner, so 20 ms of network is noise against seconds of processing.
3. Server-to-server APIs your users never wait on synchronously. If a request fans out to a payment provider that takes 300 ms, your 20 ms is 6% of that call and shrinking.
4. Bulk transfer. Backups, replication, large downloads — these are bandwidth-bound. Latency affects how fast a single TCP flow ramps up, not the steady-state throughput once it has.

The workloads where RTT is worth paying for are the synchronous, chatty, interactive ones: a dashboard that makes a dozen sequential API calls, a login flow, an SSR page that hits the database several times per request. If that is what your users touch, the round-trip multiplier is real. If it isn't, spend your attention elsewhere.

Where Frankfurt wins — and it does, for some of you

The distance table favours Stockholm for Nordic users. Two things push the other way, and if they describe your traffic, Frankfurt is the right choice.

Peering and routing. Frankfurt hosts DE-CIX, the world's largest internet exchange by peak traffic (DE-CIX reports a Frankfurt throughput peak of 18.73 Tbit/s in December 2025). An enormous number of networks meet there. That means a packet's shortest path is sometimes through Frankfurt even when the endpoints are elsewhere in Europe — routing follows peering relationships, not just kilometres. DE-CIX and Netnod (which runs the main Stockholm exchange) have a partnership interconnecting the two, so the Nordics are well-connected to Frankfurt, but the density of networks present at DE-CIX can give a Frankfurt origin a shorter real path to a chunk of European destinations than the map suggests. This is precisely what your own RIPE Atlas run will reveal or refute.

Your audience isn't only Nordic. If a meaningful share of your users sit in Germany, the Netherlands, Poland or the UK, Frankfurt's central position wins. A quick floor check for the UK makes the point: London to Frankfurt is roughly 640 km (~6 ms floor); London to Stockholm is roughly 1,440 km (~14 ms). For a UK-heavy user base, Stockholm is the slower choice, and if your market is British, hosting in the UK beats both. Weight the cities by where your paying users actually are, not by where the shortest single hop lands.

What about data residency? Little to choose on the law

People sometimes reach for a legal reason to prefer one country. On GDPR grounds there isn't one. Sweden and Germany are both EU member states, so both fall directly under the General Data Protection Regulation (Regulation (EU) 2016/679). Personal data stays inside the EU/EEA either way, and none of the Chapter V rules on transfers to third countries are triggered by choosing one over the other. There are narrower sector-specific rules and contractual commitments that can favour a specific country for a specific customer — if that is you, get it in the DPA in writing — but "Germany is better for privacy than Sweden" is not a claim GDPR supports. Decide on latency and price, not on a data-protection difference that isn't there.

A decision rule

Run the measurement, then apply this:

1. Users mostly in Stockholm, Oslo, Helsinki or Gothenburg, and your app is interactive: host in Stockholm. The 3-RTT multiplier turns a real ping advantage into real milliseconds.
2. Users mostly in Copenhagen, or spread across continental Europe, or your traffic is CDN-fronted / async: the latency gap is small or irrelevant — choose on price, peering and where your other infrastructure lives, and Frankfurt is a fine default.
3. UK- or Germany-heavy audience: don't host in Stockholm to serve them. Pick the hub closest to that audience.

If you are still unsure which VPS spec to pair with the location, our guide on how to choose the right VPS plan covers the sizing side of the same decision.

Sources

1. Primer on Latency and Bandwidth - High Performance Browser Networking (Ilya Grigorik, O'Reilly) (unknown)
2. LatencyMON - RIPE Atlas Documentation (unknown)
3. RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 (2018-08)
4. Calculating Optical Fiber Latency - M2 Optics (unknown)
5. Interconnecting Frankfurt and Stockholm - partnership with Netnod (DE-CIX) (unknown)
6. Regulation (EU) 2016/679 (General Data Protection Regulation) - EUR-Lex (2016-04)

Frequently asked questions

Is a VPS in Sweden faster than Germany for Nordic users?

Usually, but by less than people assume. On distance alone, Stockholm's RTT floor beats Frankfurt's by roughly 4-11 ms for users in Stockholm, Oslo, Gothenburg and Helsinki. Copenhagen is nearly a tie (~2 ms). Measure your own paths with RIPE Atlas before deciding, because routing and peering can change the real numbers.

How do I measure VPS latency from Nordic cities reliably?

Use RIPE Atlas: schedule ping or traceroute measurements from probes in Sweden, Norway, Denmark and Finland against an endpoint in each candidate city, and compare the minimum RTT. A carrier or exchange looking glass gives a quicker, less controlled sanity check. Run both at several times of day.

How much does latency actually add to a page load?

Multiply it by the round trips a cold load needs. A fresh HTTPS request over TLS 1.3 is about 3 RTT to first byte (TCP + TLS + request), so a 12 ms ping difference becomes roughly 36 ms of extra wait, or ~48 ms on TLS 1.2. Cached CDN content and async jobs pay none of this.

When does the Sweden vs Germany latency difference not matter?

When the bytes don't come from the origin or nobody is waiting synchronously: CDN-served static assets and cached pages, background and queued jobs, bulk transfers, and server-to-server calls users don't wait on. In those cases 20 ms is noise; choose on price and peering instead.

Is Germany better than Sweden for GDPR data residency?

No. Sweden and Germany are both EU member states under the GDPR (Regulation (EU) 2016/679), so personal data stays in the EU/EEA either way and no third-country transfer rules apply. Sector-specific or contractual requirements can favour a country for a specific customer, but general GDPR compliance doesn't distinguish the two.