Website latency is the time it takes for information to travel between a visitor and the services needed to load a page. It is usually measured in milliseconds. Lower latency makes interactions feel more immediate; high latency adds delay before a server can respond and before each network request can continue.

Latency is often confused with bandwidth. Bandwidth is how much data a connection can carry over time, while latency is how long a message takes to make the trip. A fast broadband connection can still feel slow when it must make many round trips to a distant server.

Where latency appears during a page load

A single visit can include several network exchanges:

• Resolving the domain name through DNS
• Connecting to the server and negotiating TLS for HTTPS
• Waiting for the server to begin its response
• Fetching images, stylesheets, scripts, fonts, and API data
• Sending interaction requests after the page becomes usable

Modern connection protocols help reduce some of this overhead, but every unnecessary request, redirect, and third-party domain can still introduce waiting. The first response delay is often visible in a site performance test as a higher TTFB.

What causes high latency?

Physical distance is a basic constraint: data cannot travel instantly. Visitors far from the origin server generally have a longer round trip. Congested networks, unreliable Wi-Fi or mobile connections, routing problems, overloaded servers, and packet loss can add more delay.

Use a ping test from relevant locations to establish a rough network baseline. Ping measures ICMP round trips, not full browser performance, so use it alongside browser-based testing rather than as a complete speed score. A traceroute can help when latency rises suddenly or differs significantly by region.

Ways to reduce the delay visitors experience

Put cacheable assets near users

A content delivery network (CDN) stores assets—and sometimes public HTML—at edge locations. A visitor can receive a cached file from a nearby point of presence instead of requesting it from a distant origin. Configure cache headers carefully so updates reach users when they should.

Reduce round trips and request count

Every request has overhead. Remove unused scripts and styles, avoid redirect chains, preload genuinely critical resources, and consolidate small requests only when it does not harm caching or increase the initial payload. The goal is not the fewest requests at any cost; it is fewer blocking trips before useful content appears.

Make the origin respond quickly

Network distance becomes more painful when the server is also slow. Cache frequently requested data, optimize database queries, and remove unnecessary work from the response path. See our guide to reducing server response time for a focused approach to TTFB.

Choose infrastructure based on your audience

Review analytics and customer geography before choosing hosting regions. A single origin can be sensible for a local audience, while a global audience may need edge delivery, regional services, or a multi-region strategy. Measure from the places your visitors actually use the site.

Use measurements to prioritize

Do not chase one latency number in isolation. Compare locations, repeat tests, and examine whether the delay is DNS, connection setup, server response, or asset delivery. A small improvement at the beginning of a critical path can often improve the entire page load.

Latency cannot be reduced to zero, but thoughtful architecture can make it nearly invisible to the people using your site.