What Is Latency? Why Is Your Website Slow to Load?

Latency is the time it takes for a request to travel from a visitor's device to the server and for the response to come back, measured in milliseconds (ms). What is latency, from a business point of view? However fast your visitor's internet connection is, every request has to travel a route, and the time that route takes shapes how quickly your site seems to "open." In this post we explain where latency comes from, how it differs from bandwidth and what you can improve on your site.

What is latency?

According to MDN's definition, latency is the time it takes for a packet of data to get from its source to its destination. On the web it is usually measured as round-trip time (RTT): the browser sends a request, the server responds and the first part of that response reaches the browser.

When you run ping example.com on your computer, the "time=… ms" value you see is a simple measurement of this round-trip time. A low value means requests are going back and forth quickly.

Latency also has a "sibling" concept: jitter. Jitter is the variation in latency. If packets sometimes arrive in 20 ms and sometimes much later, the connection is irregular. On web pages the effect of jitter is limited; in video calls and live streams it is felt as stuttering.

Latency vs. bandwidth

These two concepts are often confused. A simple analogy:

• Bandwidth is how many lanes the road has: it determines how much data can be carried at the same time (Mbps).
• Latency is how long it takes a vehicle to get from point A to point B.

Widening the road to ten lanes does not shorten a car's journey from Istanbul to London. The internet works the same way. As Ilya Grigorik stresses in his book High Performance Browser Networking, for most websites the factor that limits performance is not bandwidth but latency. That's because a web page is not one large file but many small requests: HTML, CSS, JavaScript, fonts, images. The round-trip time is paid again on every request.

Where does latency come from?

The time a request takes doesn't come from a single source; it is the sum of several parts.

1. Physical distance

In fiber-optic cables, data travels close to, but slower than, the speed of light: roughly 200,000 km per second. According to the calculations in High Performance Browser Networking, a round trip between New York and London takes about 56 ms even over an ideal fiber link. In real life, cables don't follow a straight line and packets pass through many intermediate devices, so the time is longer. That's why, if your visitors are in Turkey and your server is on another continent, every request gets a noticeable extra delay.

2. Intermediate devices and the "last mile"

Along the way, packets pass through routers. Each device processes the packet and, if necessary, holds it in a queue. The first stretch where a home or office connection joins the operator's network (the "last mile") can add tens of milliseconds on its own. On mobile connections this share is usually higher.

3. Connection setup steps

When connecting to a site for the first time, the browser does some preparation before it asks for any data:

1. DNS lookup: It finds the IP address of the domain name (see What is DNS?).
2. TCP connection: It "shakes hands" with the server.
3. TLS handshake: It sets up the encrypted connection for HTTPS (see HTTP vs. HTTPS).

As MDN notes, latency is longer on the first request, because the DNS lookup, TCP handshake and TLS negotiation are included in that time. Requests after the connection is established come back faster. That's why it matters how many different domains your page pulls resources from (fonts, analytics tools, chat widgets, external scripts): every new domain means a separate DNS lookup and a separate connection.

TLS 1.3 was designed to shorten connection setup compared with the previous version. So whether your server supports the current TLS version is not only a security issue but also a speed issue.

4. Server response time

Once the request reaches the server, the server prepares the page: in a system like WordPress, PHP runs, the database is queried and HTML is generated. This time is not network latency, but for the user it feels like the same wait. A slow server can cancel out the advantage of a nearby data center.

5. Redirects

A chain that goes from http:// to https://, then to the www address, then to a language folder means a new round trip at every step. web.dev's TTFB guide lists redirects as one of the common causes of a longer time to first byte.

How does latency affect your website and your business?

The most direct measure of latency is TTFB (Time to First Byte). TTFB covers redirects, the DNS lookup, connection and TLS setup, and the time until the server sends its first response. As a rough guide, web.dev says most sites should aim to keep their TTFB at 0.8 seconds or less.

TTFB on its own is not a Core Web Vitals metric. But it comes before LCP, the time it takes for a page's main content to appear: if the first byte arrives late, everything else starts late too. You can read our detailed post on Core Web Vitals here.

For a business the result is simple: the longer a visitor stares at a blank screen while the page loads, the more easily they leave your site. Customers who visit your site on a mobile connection, out in the field or on the move, feel latency even more.

How can you reduce latency?

You can't change distance or the speed of light, but you can reduce the impact of latency.

• Choose your server location based on your visitors. If most of your customers are in Turkey, ask about the data center's location when choosing hosting or a server. We covered the types of hosting in our post What is web hosting?
• Consider using a content delivery network (CDN). A CDN keeps copies of your site's static files on servers close to your visitors. If your visitors are spread across different countries, the effect is clear. web.dev notes that distant users can experience high TTFB and that, for sites not using a CDN, this is a priority improvement.
• Use page caching. Having the server send a ready-made copy instead of regenerating the page on every visit shortens the wait on the server side.
• Shorten redirect chains. Make your internal links point directly to the final address (e.g. https://www…).
• Reduce external domains. Remove tracking codes, plugins and external fonts you don't use; serve the ones you need from your own server where possible.
• Reduce the number of requests. Unnecessary scripts and large but unused files each mean a separate wait.

Common mistakes

• Saying "Our internet plan is fast, the problem isn't on our side." A speed test measures bandwidth. If your site is on a server on another continent, a fast connection won't eliminate latency.
• Testing only from your own computer. You may be seeing your site from cache, over the office's wired network. A visitor on a mobile network has a different experience.
• Not noticing that caching hides a slow server. As web.dev warns, caching can mask a slow back end. Pages that aren't cached (the cart, pages shown after a form is submitted, logged-in users) can stay slow.
• Adding every new plugin as "just a small snippet." Every external script can mean a new domain and a new connection.

Our experience

Our own site, artsution.com.tr, runs on a LiteSpeed server with the LiteSpeed Cache plugin. While improving our mobile PageSpeed results, we combined CSS files, served fonts locally instead of pulling them from an external service, and prepared small font subsets for Turkish characters. This reduced the number of external connections and requests the page needs.

We also learned a lesson: the "guest optimization" option in LiteSpeed Cache can delay JavaScript until the first interaction. That may look good in measurement tools, but it can stop menus and forms from working on the first tap. That's why we keep this option turned off. When you reduce latency, you shouldn't break the visitor's real experience.

Frequently asked questions

Conclusion

Latency is often the answer to the question "why does my site load slowly despite a fast internet connection?" When you look at distance, connection steps and server response time together, the points to improve become clear: the right server location, caching, short redirect chains and few external resources.

If you'd like us to look into why your site is slow together, take a look at our web design and WordPress development services, or contact us.