Website Fast Locally but Slow Online? What Changes in Production

A site that loads instantly on your own machine and drags once it goes live is usually not broken. Localhost hides most of what makes a real page load slow. On your own machine there is almost no network distance, no new DNS lookup or TLS handshake across the internet, often a warm browser cache, a small development database, and none of the third-party scripts that production loads for every visitor. Production adds all of those back, along with a server you share with real traffic.

The useful question is not “why is production slow?” but “which of those differences is costing the time?” Each one leaves a different mark in a speed test, so you can usually narrow it down without guessing.

Is your local test measuring the same thing as production?

Often it isn’t, and that alone can explain a large gap.

When you open localhost, the request goes through the loopback interface. The round-trip time is close to zero, so connection setup costs almost nothing. You are probably logged in, which can change what the server renders and which caches apply. Your browser may already hold the CSS, JavaScript, fonts and images from earlier visits. And your development machine is likely faster than the mid-range phone a typical visitor uses.

The table below lists the differences that most often show up between the two environments.

Not every row will apply to your site. The point is that a local measurement and a production measurement are two different experiments, and comparing their totals tells you very little until you know which rows changed.

Where does the extra time come from?

Network distance and connection setup

For a fresh HTTPS connection over TCP, the browser may first need a DNS lookup (unless cached), then a TCP handshake and a TLS handshake before sending an ordinary HTTP request. TCP setup typically costs one network round trip, and a full TLS 1.3 handshake typically adds one more; sending the request and receiving the first response byte can add another round trip. A full TLS 1.2 handshake commonly needs an additional round trip compared with TLS 1.3. Connection reuse, TLS resumption and HTTP/3 can change these costs.

As an illustration, not a measurement: at 150 ms round-trip time, a fresh connection can spend around 450 ms before the first byte arrives, without the server doing any slow work at all. On localhost the same sequence takes a few milliseconds. This is why a page can feel instant locally and still show a high Time to First Byte from a distant region. Our guide on why website speed varies by location covers routing, peering and regional caching in more detail.

Connection costs also multiply. A page that pulls assets from six different origins may need several new connections, each with its own setup cost, although connection reuse and HTTP/2 or HTTP/3 coalescing can reduce that number.

Server resources under real conditions

A development server usually faces very little concurrent traffic. A production server, especially on shared or entry-level hosting, may be handling crawlers, scheduled tasks, backups and real visitors at the same time. When PHP workers, Node processes or database connections run out, requests wait in a queue. That waiting shows up as server time inside TTFB, and it may appear only at certain hours.

Production data is bigger than test data

A query that scans 200 rows locally may scan 2 million rows in production. Missing indexes, unbounded queries and plugins that load every option on every request are easy to miss with a small development database. These problems tend to grow with the site, so a page that was fine at launch can slow down months later without any code change.

If the database lives on a separate host in production, each query also pays network latency. A page that runs hundreds of small queries can lose meaningful time to round trips alone, even if every query is fast.

Caches that work differently, or not at all

Caching is one of the most common reasons local and production results disagree, and it can push in either direction:

• A page cache may be bypassed for logged-in users, so you see a slower page than visitors do. Or the reverse: you test anonymously right after a deploy, the cache is cold, and you see the slowest version of the page.
• Cookies or query strings (including marketing parameters) can stop a CDN or page cache from serving a cached copy.
• A CDN may have the page cached in one region and not another, so the result depends on where the request came from.

A single slow run after a deploy or cache purge may reflect a cold cache rather than typical performance.

Third-party scripts you never see locally

Many teams disable analytics, ads, consent banners and chat widgets in development. In production, a tag manager can load several more scripts, each from its own domain, each with its own connection setup and execution time on the main thread. These often add more to total load time than the site’s own code. They rarely affect TTFB, which is a useful clue: if TTFB looks fine but the page finishes loading much later than it does locally, look at what loads after the HTML.

Configuration and edge behavior

Production adds steps that localhost usually doesn’t have:

• Redirect chains (http → https → www, or a trailing-slash redirect), each costing at least one more round trip.
• WAF rules or bot challenges that delay or replace the real page.
• Compression or HTTP/2 or HTTP/3 settings that differ between environments. If you’re unsure what your server negotiates, our HTTP/2 vs HTTP/3 guide explains what each changes.
• Images served at original upload size from production storage, where local fixtures were small placeholders. See how large images slow down a website.

Is it slow for everyone, or just in some situations?

Before changing anything, work out the shape of the problem. Three comparisons separate most causes:

• Location. Slow from one region but acceptable from another usually points to distance, routing or regional cache misses. Slow from every region points more toward the server or the page itself.
• First visit vs repeat visit. If a refresh is fast and a first visit is slow, caching and asset weight matter more than server speed.
• Anonymous vs logged in. If only logged-in pages are slow, the page cache is probably bypassed and the application is doing full work on every request.

Your own browser alone makes these comparisons hard to control, because it carries your cache, cookies, extensions and network conditions.

How do you find which difference is costing the time?

Work through the layers in order, changing one thing at a time.

• Test outside your own browser. Run the public URL from an external test location so your cache, login session and local network are out of the picture.
• Compare TTFB with total load time. A high TTFB means the delay happens before the HTML arrives: connection setup, redirects or server work. A normal TTFB with a long load time points you toward resources and browser work after the initial response begins. What is a good TTFB covers how to read that number.
• Separate connection time from server time. If DNS, TCP and TLS take a large share of TTFB, connection setup or the network path deserves attention. If setup is quick and TTFB remains high, investigate request travel, edge or origin queues, and server processing rather than assuming one cause.
• Compare page weight and request count with what you expect. A production page that makes far more requests than your local build is a sign of third-party tags or assets that only load in production.
• Look at what the browser actually received. A screenshot or loading replay can reveal a consent wall, a bot challenge, an error page or a redirect destination that the timing numbers alone won’t show.
• Test from more than one region. Compare the same URL from several locations to see whether the slowdown follows distance.
• Repeat runs before drawing conclusions. One run can catch a cold cache or a busy moment on the server. Several runs show what is typical.

If the evidence points to the server, reproduce production conditions where you can: a copy of production data on a staging server, the same caching setup, the same PHP or Node configuration. A staging environment that only mirrors the code will reproduce only some of the problems.

What a Latixo test can show, and what it can’t

Latixo’s website speed test loads a public URL in a real Chromium browser running on a Browser Node in the location you choose. That gives you the outside view that localhost can’t: the page as a visitor’s browser receives it, over a real network path, without your browser’s cache or login session.

The result includes TTFB, measured from navigation start to the first response byte, so it contains redirects, connection setup and server time together. It also includes total load time (based on Chromium’s load event), page weight, request count, the main document’s HTTP status and protocol, a WebP screenshot and a Loading Replay of the page as it rendered. You can run a Desktop profile or a simulated Mobile profile (390 × 844 viewport, DPR 3, 4× CPU slowdown, 1.6 Mbps down, 750 Kbps up, 150 ms added latency), which is useful when your local tests only ever ran on a fast laptop.

Tests can currently run from eight locations: Virginia, Seattle, Nuremberg, Tokyo, Singapore, São Paulo, Beijing and Sydney. Running the same URL from, for example, Virginia and Seattle, then from a node on another continent, helps show whether the gap you see is about distance or about the server.

There are limits to keep in mind. A Latixo result is a lab measurement from one location at one moment, not field data from your real visitors. It cannot see inside your server, so it can show a high overall TTFB but cannot isolate which server-side query or plugin caused the delay. It tests public URLs, so pages that require a login are outside its scope. And the public result is not a full per-request waterfall. The methodology page and website speed test metrics explain exactly what each number means.

Quick answers

My site is fast when I open it on my own phone. Why do customers say it’s slow?

Your phone has probably cached the site’s assets, and you may be close to the server or on fast Wi-Fi. A first-time visitor in another region, on a slower phone or network, pays for connection setup and a full download that you skip.

If staging is fast, will production be fast?

Not necessarily. Staging often has less data, less traffic, a different cache setup and fewer third-party scripts. It confirms that the code works, not that production conditions will be fast.

Why is the first load slow but a refresh fast?

A refresh can reuse cached assets and existing connections. The gap is a clue about caching, connection setup and asset size, though other conditions may also change between visits.

Should I worry about one slow test result?

Treat a single result as a lead to check, not a verdict. Repeat the test, compare locations, and look for a pattern before changing your setup.