Website Speed Test in South America: How to Compare Real Loading Performance

Why “South America” Is Not One Location

On a map, South America looks like one market. On the network, it is not.

São Paulo is one of the continent’s major interconnection hubs. Many networks, content providers and cloud platforms connect there, and several large cloud providers run regions in the city. A test from São Paulo therefore runs from a well-connected point in Brazil’s main traffic center. It does not run from an average South American connection.

Away from that hub, the picture becomes uneven. Traffic between some South American countries has historically gone through hubs in the United States, especially Miami, rather than directly across the continent. Regional interconnection has improved, but you still can’t assume that two neighbouring capitals are close in network terms. The Andes, the Amazon basin and the distances inside Brazil all affect where cables and exchange points sit.

In practice:

• A São Paulo result is a measurement of how your page loaded from São Paulo.
• How that result applies to Buenos Aires, Santiago, Bogotá or Lima is an inference, and it gets weaker the further those visitors are from São Paulo in network terms.

Both statements are useful, and the rest of this guide keeps them separate.

What Latixo Measures from São Paulo

A Latixo test is a full browser session, not a ping or a header check. The São Paulo Browser Node opens the submitted public URL in Chromium, records the load, and returns:

• Time to First Byte (TTFB): the time from navigation start until the browser begins receiving the main document. It includes network round trips as well as server or edge processing. See What Is a Good TTFB? for how to judge the number.
• Total load time, along with DOMContentLoaded and load-event timing recorded by the engine.
• Page weight and request count: the bytes transferred and the network requests observed during the run.
• Protocol and response basics: the negotiated HTTP version, plus the main response’s status and content type.
• Visual evidence: a WebP screenshot and a WebM Loading Replay of the first viewport, when capture succeeds.

You can run the test with a Desktop or a Mobile profile. The Mobile profile uses a 390 × 844 viewport at DPR 3, a 4× CPU slowdown, and simulated network conditions of 1.6 Mbps down, 750 Kbps up and 150 ms latency.

The standard Website Speed Test is not Lighthouse and does not produce a Core Web Vitals report. It is lab data from one controlled run. It shows how the page behaved under known conditions, but it does not show what your real visitors experienced on their own devices and networks. The methodology page and Website Speed Test Metrics explain both points in more detail.

Which Comparison Answers Your Question?

A São Paulo result means most when you set it beside a second run that differs in only one way. Pick the pair that matches what you are trying to find out.

The last row is often the most practical. If your traffic comes mainly from Brazil, a before-and-after comparison from the same location and profile is a cleaner test of an optimization than any cross-region comparison.

Running a Fair Comparison

Small differences in setup can produce large differences in results. These steps keep the two runs comparable:

1. Use the exact same URL. If your site redirects Brazilian visitors to a /pt-br/ path or a regional domain, decide which version you are testing and submit that one directly.
2. Keep the profile the same. Start with Desktop when the question is about geography. The Mobile profile adds simulated throttling and CPU slowdown, which are useful for mobile questions but can hide or change the network difference you are trying to isolate.
3. Run the locations close together in time. Deployments, cache purges and traffic peaks between runs make the comparison noisier.
4. Repeat each location more than once. The first request to a CDN edge in São Paulo may be a cache miss, and later runs may be hits. Keep the first run in mind but don’t let it represent the location on its own.
5. Compare the saved reports side by side. Latixo’s Saved Report Comparison puts two saved reports next to each other, with timing differences, screenshots and Loading Replay where the media is still available. It does not run a new test, and it warns you when the two reports differ in node, device or profile.
6. Watch both Loading Replays. Two pages with similar load times can look very different to a visitor while they load.

Reading the Differences

The TTFB gap is large, but the rest of the load is similar

This pattern can mean the main document is being fetched from far away. Common causes are that the HTML is generated or served only at a distant origin, that your CDN does not cache HTML, or that the edge had to go back to the origin on that run. If repeated São Paulo runs bring TTFB down sharply, a change in cache state may be involved. If TTFB stays high from São Paulo but not from Virginia, distance, routing and cache policy are worth investigating. The difference alone does not prove that application processing is fast or slow.

TTFB is close, but total load time is far apart

The document arrives quickly, so the delay comes later in the load. Look at request count and page weight, then look at the Replay. Typical causes include images that are not served from a CDN, fonts or scripts loaded from hosts with no nearby presence, and third-party widgets such as chat, analytics or A/B testing tools that call endpoints in North America or Europe. Each of those requests pays the long round trip again. The large images guide covers the most common case.

Page weight or request count differs between locations

Geography by itself does not require a page to send different bytes. If São Paulo transfers a different amount than Virginia, the responses or loading outcomes may differ. Possible reasons include a localized Portuguese page, a country-specific consent banner, geo-targeted promotions, a different ad stack, or a redirect that only Brazilian traffic receives. Failed requests, dynamic content and third-party behavior can also change the totals. Compare the screenshots before you treat this as a speed difference, because the two runs may not have loaded the same page state.

The screenshot shows a challenge or block page

Some bot-protection setups treat browser traffic from data centers differently, and that treatment can vary by country. If the São Paulo screenshot shows a verification screen or an access-denied page, the timing describes that screen, not your site. A run like this tells you nothing about real visitors’ load times. It may still be worth checking, because the rule could affect real visitors too.

The protocol differs

If one location negotiates HTTP/3 and the other falls back to HTTP/2, part of the gap may come from the protocol rather than distance. HTTP/3 can help on high-latency or lossy paths, but it will not make up for an uncached origin on another continent. HTTP/2 vs HTTP/3 explains when the difference matters.

How Far Can a São Paulo Result Stand In for the Rest of the Continent?

There is no precise answer, but a rough guide is possible. Treat the following as reasoned expectations, not measurements:

• São Paulo and Rio de Janeiro, plus much of southern and southeastern Brazil: a São Paulo run is a reasonable approximation of where these visitors sit on the network. Their own devices and last-mile connections will still vary.
• Northern and northeastern Brazil: distances inside Brazil are large, so these visitors may sit further from the São Paulo hub. The São Paulo result is likely to be on the optimistic side for them.
• Argentina, Chile, Uruguay and Paraguay: these countries often reach international content through different paths. Some traffic goes via Brazil and some goes elsewhere. A São Paulo result is informative but not interchangeable with a local measurement.
• Colombia, Venezuela, Ecuador and Peru: for many networks in the north and west of the continent, the path to a US East origin may be shorter than the path to São Paulo. A São Paulo result can be a poor stand-in here in either direction.

To learn what visitors in these countries actually experience, combine lab tests with field data, such as real-user monitoring segmented by country. The guide to why website speed varies by location covers the general mechanics behind these differences.

Common Reasons Sites Load Slowly from South America

These causes come up often when a site is fast in North America or Europe and slow from São Paulo. They are starting hypotheses to check against your own results, not diagnoses:

• The origin is far away and HTML is not cached at the edge. A CDN that only caches static assets still leaves every page request crossing the ocean.
• Redirect chains, especially language or country redirects. Each hop adds round trips, and those round trips cost more over a long path.
• Third-party scripts with no nearby endpoints. They can add delay even when your own infrastructure is well placed.
• Heavy pages. Large images and scripts cost more where links are slower or more congested, and the Mobile profile makes that easy to see.
• Different content for Brazilian traffic that turns out heavier than the default version.

Where to Start

For a first pass, run your homepage or a key landing page from São Paulo and from the location closest to your origin, using the Desktop profile. Repeat each run once, then put the saved reports side by side. If the gap is mostly in TTFB, look at hosting and caching. If the gap appears after the first byte, look at assets and third parties. Then run São Paulo again on the Mobile profile to see how the page holds up under constrained conditions.