Website Speed Test from São Paulo, Brazil

Why can a site that is fast in the US or Europe feel slow in Brazil?

Latixo can open your page in a real Chromium browser on a live Browser Node in São Paulo, Brazil. The report gives you TTFB, total load time, page weight, request count, a WebP screenshot and a Loading Replay from that run. Use it when you need to know how a page behaves once the request has to reach South America. A test from your office, from your server's own region or from another continent will not show you that.

Here is a common case. The site is hosted in the eastern United States or in Europe. Every test from those regions looks fine, but customers or the sales team keep saying the site “feels slow in Brazil.” A São Paulo run turns that complaint into a controlled measurement. You can repeat it, compare it with other regions and run it again after you make a change.

Run a website speed test from São Paulo →

Often the page itself is not the only issue. Distance and routing can add unavoidable network delay. Brazil is a major online market in Latin America, while many sites that serve Brazilian users are still hosted in North American or European cloud regions.

Physics sets a lower bound on propagation delay. The straight-line distance from São Paulo to Northern Virginia is roughly 7,600–7,700 km. Light in optical fibre travels at about 200,000 km per second, so an idealized round trip is already around 75–80 ms before routing detours, switching, queueing or server work. São Paulo to central Germany is close to 10,000 km, giving an idealized round-trip floor of roughly 100 ms. These are geography-based illustrations, not Latixo measurements, and real network paths are normally slower.

Round trips also accumulate. For a new TCP/TLS-based HTTPS connection, the browser may need to resolve the hostname, open a TCP connection, complete the TLS handshake, send the request and wait for the response to begin. TLS 1.3 reduces handshake cost compared with older full handshakes, but distance still matters.

Three 80 ms network round trips already total about a quarter of a second before application processing is added. Other origins used by the page — font hosts, tag managers, chat widgets, payment SDKs and similar services — can introduce their own setup costs. That is why a modest TTFB difference can grow into a much larger total-load difference. For the full mechanism, see why website speed varies by location.

Brazil is also geographically large. Manaus is roughly 2,700 km from São Paulo in a straight line, much farther from São Paulo than Buenos Aires is. A São Paulo run therefore represents Latixo's southeastern Brazilian vantage point; it does not represent every visitor in the North or Northeast.

What runs on the São Paulo Browser Node

São Paulo (sao-paulo-br) is one of Latixo's eight live test locations and has two browser workers. Latixo uses independent location pools. When you choose São Paulo, the test is routed to the São Paulo location rather than being silently reassigned to another region.

Every test opens a fresh, isolated Chromium browser context. Service workers are blocked for the run, so one test does not warm the next test through a service-worker-controlled browser cache. Chromium then loads the public URL you submitted. Scripts run, stylesheets and fonts load, and third-party requests can fire as they would during a browser visit.

• Desktop1366 × 768 viewport, DPR 1, using the node's native CPU and native network.
• Mobile (simulated)390 × 844 viewport, DPR 3, 4× CPU slowdown, 1.6 Mbps down, 750 Kbps up and 150 ms configured network latency.
• ScreenshotA WebP capture of the tested viewport is returned when the run completes successfully.
• Loading ReplayA WebM recording lets you watch the visible loading process from that browser run.

What the standard Website Speed Test report includes

The current Latixo Website Speed Test focuses on the measurements and visual artifacts that are available in the production interface today:

• the Latixo performance grade,
• TTFB measured from navigation start to responseStart,
• total load time based on loadEventEnd when available,
• transferred page weight and observed request count,
• the main document's HTTP status, protocol and content type,
• a WebP screenshot and WebM Loading Replay of the tested viewport.

Some things are intentionally not presented as separate fields in the standard result. It does not expose separate public FCP, LCP or CLS values, a separate DNS/TCP/TLS timing breakdown, or a full per-request waterfall. The performance grade is Latixo's own heuristic; it is not a Lighthouse score, PageSpeed Insights score or Core Web Vitals assessment. The metric definitions explain how the current values should be interpreted.

How should you read a São Paulo result?

One number from São Paulo tells you little by itself. The same URL tested with the same Test Profile from another region tells you much more. These patterns are useful starting points:

These are investigation starting points, not diagnoses. A controlled lab result can show you where a difference appears, but it usually cannot prove the root cause on its own.

Is your CDN actually serving Brazil from Brazil?

Using a CDN does not guarantee that a Brazilian visitor is served from a South American edge, or that the requested object is already cached there. Three issues commonly matter.

Plan or price class

Some CDN configurations limit which edge regions can serve content. Amazon CloudFront is a concrete example: Price Class 100 and Price Class 200 exclude South America, while the all-edge option includes all CloudFront edge locations. If São Paulo TTFB looks like an intercontinental trip even though CloudFront sits in front of the site, verify the distribution's price class.

Cacheability

A nearby edge helps most when the response can actually be served there. If the HTML is dynamic or otherwise not cached, the edge may still need to contact the origin. TTFB can then include part of the long edge-to-origin path even though the browser connects to a nearby CDN edge.

Cache warmth

The first request after a deploy, purge or eviction can miss the edge cache. A slow first São Paulo run followed by faster repeated runs is consistent with cache state being involved, although the speed test alone cannot prove that explanation.

The standard Latixo result does not expose a full raw-response-header inspector. To confirm which CDN edge answered and whether the object was a hit, use your CDN analytics or logs, or inspect the relevant cache-status headers in browser developer tools.

If you run a Shopify store that sells in Brazil, the Shopify Speed Test can also use São Paulo as a test location. Its diagnostics classify observed resources into Shopify, theme and third-party groups, which can help separate storefront platform resources from app or third-party script overhead.

Which regions should you compare São Paulo with?

Choose the comparison point based on where your infrastructure is and keep the URL and Test Profile identical between runs.

São Paulo vs Virginia

Use this comparison if your origin or main cloud region is in the eastern United States. The difference can show how the north–south network path affects the two controlled runs. The Virginia speed-test page explains that vantage point.

São Paulo vs Nuremberg

Use this comparison for sites hosted in central Europe. The request crosses the Atlantic and the geography-based propagation floor is higher than on the route between São Paulo and the eastern United States. Do not treat the difference as pure network latency, because CDN routing, cache state, backend placement and transient conditions can also change.

Change one variable at a time. Keep the URL and Desktop/Mobile profile identical, repeat the runs, and the regional difference becomes much easier to interpret.

One limit applies here: São Paulo is currently Latixo's only South American location. It cannot stand in for Buenos Aires, Santiago, Bogotá or other Latin American markets. Regional traffic does not always follow the geographically shortest route.

What a São Paulo run cannot tell you

A Latixo test is lab data: one browser, on one Browser Node, with one Test Profile, at one moment. That makes it useful for repeatable comparisons and before-and-after checks, but it does not represent every visitor in Brazil.

Real users connect through different home broadband providers and mobile carriers, on devices with widely different CPU, memory and radio performance. Latixo's Mobile profile is browser-based simulation with fixed CPU and network settings. It does not run on a physical phone on a Brazilian mobile network. Compare Mobile with Mobile and Desktop with Desktop.

Field data answers a different question. Real-user datasets such as the Chrome User Experience Report aggregate actual visits over time. When a performance decision matters, use field data alongside controlled lab measurements. For the limits and interpretation of Latixo measurements, read the Latixo methodology.

Questions about testing from São Paulo

Is the test really run from Brazil, or is the location simulated?

It is run on Latixo's live São Paulo Browser Node. The job goes to the São Paulo location and Chromium on that node loads the page. Latixo does not create a Brazilian result by taking a test from somewhere else and adding artificial delay afterward.

Why is my Mobile result from São Paulo so much slower than Desktop?

The Mobile profile deliberately uses a 4× CPU slowdown and fixed network limits of 1.6 Mbps down, 750 Kbps up and 150 ms configured latency. A heavy or script-heavy page can be affected much more than on Desktop, which uses the node's native CPU and network.

Can I test the Portuguese (pt-BR) version of my site?

Yes. Enter that public URL directly. If your site redirects users based on location, check the screenshot and final rendered page before comparing it with runs from other regions.

Can I test staging sites or pages behind a login?

The standard test is intended for public HTTP or HTTPS URLs. Private destinations, credentials and disallowed ports are blocked by Latixo's URL validation model, so authenticated or private staging environments are outside the normal public test scope.