Website Speed Test in the United States: Compare Real Loading Performance from Coast to Coast

Two US test locations, two different vantage points

The two US nodes are not interchangeable. They sit roughly 3,700–3,800 km apart in a straight line, and each one answers a slightly different question.

If you can only run one test, the more informative choice is often the coast farther from your origin. A Virginia test of a site hosted in a US East cloud region often shows a near-origin case. A Seattle test of the same site shows what the network adds for visitors on the other side of the continent. If you don’t know where your origin or CDN edge actually answers from, test from both.

Each location has its own page with more detail on what that node is good for. See Website Speed Test from Virginia, USA and Website Speed Test from Seattle, USA.

What a US test measures, and what it doesn’t

Both nodes use the same Browser Node stack and the same two Test Profiles. A Virginia result and a Seattle result are therefore built from the same measurement method.

A completed test returns TTFB, DOMContentLoaded, load timing, transferred bytes, request count, the main document’s HTTP status and protocol, a WebP screenshot, and a WebM Loading Replay. It also returns a Latixo score with an A–F grade. That score is Latixo’s own heuristic. It is not Lighthouse, PageSpeed Insights or a Core Web Vitals assessment. The standard Website Speed Test does not report LCP, CLS or INP. The Website Speed Test Metrics page defines each field.

The choice of profile changes what a coast-to-coast comparison can show. On the Mobile profile, the same throttled bandwidth and added latency apply at both nodes. Those fixed costs can make up most of the total load time, so the share caused by geography gets smaller and harder to read. If your question is mainly “how much does distance inside the US cost this page?”, start with Desktop. Use Mobile afterward to see how the page holds up on a constrained connection.

How to compare East Coast and West Coast results

1. Pick the exact URL you care about. Use the final address rather than one that redirects. If the two runs end on different final URLs, the comparison will flag it.
2. Choose one Test Profile and keep it. A Desktop run against a Mobile run is a profile comparison, not a location comparison.
3. Run the test from Virginia and keep the saved report link.
4. Run the same test from Seattle within a few minutes. Keeping the runs close in time reduces the chance that a deploy, traffic spike or cache purge lands between them.
5. Repeat each location at least once. The first request through a CDN edge may be a cache miss, and the second may not. Two similar runs from each node are much easier to interpret than one run each.
6. Open the comparison. Use Compare saved reports on a result, then paste the other report’s link or ID, or pick it from your browser-local history. The comparison reads the two saved reports and does not re-run either test.
7. Read the conditions notice first. It will report that the Browser Node location differs, which is the point of this comparison. Any other flagged difference means you are comparing more than geography. Examples include protocol, HTTP status, final URL or Test Profile settings.

Reading the gap between Virginia and Seattle

The comparison shows each metric for both runs, plus the absolute difference and, where it applies, the percentage difference. The pattern across those rows tells you more than any single row.

TTFB differs, but transferred bytes and request count match

The page is the same, but the first byte arrives later from one coast. That points to the network path, the location of whatever responds to the HTML request, or cache state at the edge. Some of this delay is physical. At roughly 3,700 km, light in optical fiber needs about 37 ms for a round trip between the coasts, before any routing detours. This figure is a calculation, not a Latixo measurement. A fresh HTTPS navigation may spend multiple round trips on connection setup before the first byte. So if your HTML comes from a single origin on one coast, a TTFB gap well above 37 ms can be expected, not necessarily a sign that something is broken. Whether your gap is reasonable depends on your stack. What Is a Good TTFB? covers the benchmarks.

TTFB is close on both coasts

Either an edge node near each test location is serving the HTML, or server processing time is so large that network distance barely registers. These two numbers alone can’t tell those cases apart. Your CDN’s cache-status headers or logs can.

TTFB is close, but load time differs

The main document arrived on time, and the delay came later. Common causes are third-party scripts, fonts or media fetched from hosts that are far from one of the two nodes. Every new origin needs its own connection, so distance costs repeat across the page. The request count and the Loading Replay can help show where the time went. Heavy assets make this worse; see how large images slow down a website.

Request count or transferred bytes differ noticeably

The two nodes may have received different pages. Geo-targeted content, consent banners, A/B tests and ad auctions can all change what loads. Compare the two screenshots before reading anything into the timing.

Failed requests appear on only one side

Look for location-based rules: geo-blocking, CDN configuration or bot protection. Browser Nodes run in data centers, and some security layers treat that traffic differently from home or mobile visitors.

The score or grade changed

Treat it as a signal to check the underlying fields, not as the finding itself. The comparison shows no numeric difference for letter grades on purpose.

What two US nodes can’t represent

A Virginia–Seattle pair covers both ends of the continent, but it doesn’t sample everything in between.

• The middle of the country. There is currently no Latixo node in the central or southern US. If your origin is in Texas or the Midwest, both nodes are some distance away from it, and neither shows the near-origin best case.
• Real visitor connections. The Desktop profile uses each node’s data-center network, and the Mobile profile is a simulation. Neither one is a residential ISP or a real mobile carrier.
• Locations outside the contiguous US. Latixo has no node in Alaska, Hawaii, Canada or Mexico.
• Your real-user distribution. Every result is one controlled lab load. Field data from real visitors shows the spread across devices and networks, which lab tests are not designed to show.
• Ongoing monitoring. Latixo runs tests when you ask for them. It doesn’t schedule repeat checks or alert you about changes.

When to add a location outside the US

If your US site also serves Europe or Asia, the US pair is half the picture. Virginia compared with Nuremberg shows the cost of crossing the Atlantic. Seattle compared with Tokyo or Sydney shows the cost of crossing the Pacific. For the wider explanation of why the same page loads differently by country, see Why Website Speed Varies by Location.