The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
Network latency is the delay between a browser requesting something from a website and receiving a response. It is not the same as bandwidth: a connection can transfer data quickly once it starts, yet still feel slow if each request waits a long time to make the round trip. To reduce website latency, first measure where the wait occurs, then address the cause—often by caching suitable content near visitors, locating the origin closer to them, or reducing unnecessary requests.
What network latency means for a website
Latency is the time it takes for data to travel between a source and a destination. For a website, people usually care about the request’s round-trip time: how long it takes the browser to send a request and begin receiving a response. MDN Web Docs describes latency as the time it takes for a packet of data to travel from source to destination; the page was last modified on February 25, 2025.
Latency is different from bandwidth. Bandwidth is the capacity to transfer data; latency is the delay before and during delivery. A high-bandwidth connection can download a large file quickly once data starts flowing, while a long round trip can still delay the first visible content or make interactions feel sluggish. That is why “fast internet” at the visitor’s home does not guarantee a fast website.
Every extra request can add another opportunity to wait. A page may request HTML, stylesheets, scripts, images, fonts, and data from APIs. Some requests can be made in parallel, and browsers can reuse established connections, but a page that depends on many separate responses may still accumulate meaningful delay. Browser parsing and rendering also take time; those are not network latency, even though visitors experience them as part of page speed.
#1 Best Overall
- DUAL-BAND WIFI 6 ROUTER: Wi-Fi 6(802.11ax) technology achieves faster speeds, greater capacity and reduced network congestion compared to the previous gen. All WiFi routers require a separate modem. Dual-Band WiFi routers do not support the 6 GHz band.
- AX1800: Enjoy smoother and more stable streaming, gaming, downloading with 1.8 Gbps total bandwidth (up to 1200 Mbps on 5 GHz and up to 574 Mbps on 2.4 GHz). Performance varies by conditions, distance to devices, and obstacles such as walls.
- CONNECT MORE DEVICES: Wi-Fi 6 technology communicates more data to more devices simultaneously using revolutionary OFDMA technology
- EXTENSIVE COVERAGE: Achieve the strong, reliable WiFi coverage with Archer AX1800 as it focuses signal strength to your devices far away using Beamforming technology, 4 high-gain antennas and an advanced front-end module (FEM) chipset
- OUR CYBERSECURITY COMMITMENT: TP-Link is a signatory of the U.S. Cybersecurity and Infrastructure Security Agency’s (CISA) Secure-by-Design pledge. This device is designed, built, and maintained, with advanced security as a core requirement.
Where website latency comes from
Distance between the visitor and the server
Data has to travel through networks. The farther a visitor is from the server handling a request, the longer the path can take. Cloudflare identifies distance as a principal cause of latency. Its 2019 load-balancing whitepaper gives an estimate of 0.82 milliseconds per 100 miles. Treat that as a vendor estimate, not a universal constant: real routes, network conditions, and endpoints affect the result.
Distance matters for both static and dynamic content. A nearby cache can serve a copy of a suitable asset without sending the request all the way to the origin. A request that must be processed by the origin, such as a dynamic request, may still need a closer or distributed compute location to avoid a long trip.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →DNS, TCP, and TLS setup
Before a browser can receive a response on a new connection, it may need to look up the domain through DNS, establish a TCP connection, and negotiate TLS for HTTPS. MDN notes that the first request includes these stages; later requests may reuse an established connection. Setup delay therefore matters especially when a page needs a new connection, while connection reuse can avoid repeating some of the work.
In an example cited by an AWS static-site whitepaper, TCP handshake overhead accounts for 10%–30% of request-serving latency. That is a figure from the whitepaper’s cited example, not a fixed share for every website or request.
Routing, congestion, and packet loss
Packets do not necessarily take a direct path between visitor and server. Network routing, packet processing, and queuing add delay; congestion and packet loss can make the path slower still. A poor route can hurt even when the visitor and origin are not especially far apart. Distance is one factor, not a complete explanation of every slow connection.
Origin processing and time to first byte
After a request reaches the origin, the application may need to run code, query a database, wait for an overloaded server, or recover from a cold start before it can send the first response bytes. This waiting contributes to time to first byte (TTFB). If DNS and connection setup look reasonable but TTFB is high, investigate origin processing and the route to the origin rather than assuming that a larger image or faster visitor connection is the problem.
Rank #2
- OneMesh Compatible Router - Form a seamless WiFi when work with TP-Link OneMesh WiFi Extenders
- Next-Gen Wi-Fi 6 Technology – The Archer AX10 leverages advanced Wi-Fi 6 features like OFDMA and 1024-QAM to deliver improved efficiency across your entire network. Perfect for high-bandwidth activities like streaming, gaming, and smart home connectivity.
- Next-gen Dual Band router - 300 Mbps on 2. 4 GHz (802. 11n) plus 1201 Mbps on 5 GHz (802. 11ax)
- Connect more devices than ever before - Wi-Fi 6 technology simultaneously communicates more data to more devices using OFDMA and MU-MIMO while reducing lag dramatically
- Powerful Dual-Core 900MHz Processor – Handles multiple data streams simultaneously for reliable performance across your devices. Ensures smooth streaming, online gaming, and video conferencing without buffering or lag.
Too many requests, large transfers, and browser work
Each additional asset or third-party call can add network work, and render-blocking CSS or JavaScript can delay when a page becomes usable. Large images increase transfer time, but compressing an image does not remove the round-trip delay required to request it. Likewise, reducing page weight can improve loading without eliminating the propagation time between a visitor and a distant server.
How to read a request waterfall
A browser waterfall makes the stages visible for each resource. The DNS portion shows name-resolution time. The connection portion covers establishing TCP, while the secure-connection portion covers TLS negotiation. The request can then sit waiting for the first response byte, which is reflected in TTFB, followed by the period during which the response body is downloaded. A long final download points toward transfer size or throughput; a long idle period before the first byte points toward setup, routing, or origin work.
These milestones are cumulative. If a command reports 0.08 seconds to DNS, 0.16 seconds to TCP connect, and 0.31 seconds to TLS completion, those values mark when each stage finished from the beginning of the request; they are not three independent durations to add together. Compare the gaps between milestones and compare the same URL on a cache hit and a cache miss.
Inspect the first navigation separately from later requests. The first request may pay DNS, TCP, and TLS costs, while resources fetched over an established connection can avoid some setup. A page that is quick on a repeat visit but slow on a fresh navigation may have a connection-establishment or request-count problem rather than a payload-size problem.
How to measure latency and locate the delay
Measure the stages separately before changing hosting or buying a routing service. A single total-load number cannot show whether the issue is DNS, connection setup, origin response, transfer, or browser rendering. Use browser developer tools’ Resource Timing information and a command-line request, then compare results from locations that reflect your audience.
Measure request phases with curl
Cloudflare documents this curl pattern for measuring phases of a request:
Rank #3
- NIGHTHAWK WIFI 6 ROUTER FOR YOUR WHOLE HOME: Delivers fast, reliable WiFi across every room of your apartment or small home for streaming, gaming, video calls, and smart home devices, all running at the same time without slowing each other down.
- WORKS WITH YOUR EXISTING INTERNET SERVICE: Pairs with your existing modem or gateway via ethernet. Compatible with most cable, fiber, DSL, and satellite providers. Some gateways and modem router combos may require bridge mode. No coax needed.
- SET UP AND MANAGE YOUR NETWORK WITH THE NIGHTHAWK APP: Download the free Nighthawk app on iOS or Android for guided setup. Manage WiFi, run speed tests, pause devices, and set up guest networks from anywhere. Active internet required.
- READY FOR THE DEVICES YOU ALREADY OWN: Your phones, laptops, and TVs work right out of the box. WiFi 6 delivers speeds up to 1.8 Gbps across 2.4 GHz and 5 GHz bands. Backward compatible with WiFi 5 and earlier.
- COVERAGE IN EVERY ROOM: Covers up to 1,500 sq. ft. for up to 20 connected devices. Walls, floors, and interference can reduce range. Larger or multi-story homes may benefit from a NETGEAR Orbi mesh WiFi system.
curl -w "nnDNS Lookup: %{time_namelookup}snTCP Connect: %{time_connect}snTLS Handshake: %{time_appconnect}snTime to First Byte: %{time_starttransfer}snTotal Time: %{time_total}sn" -o /dev/null -s https://www.example.com/slow-asset.jpgReplace the example URL with the asset or page you want to inspect. The reported times are measured from the start of the request, so they are phase milestones rather than independent durations to add together. Compare the milestones: a long DNS lookup points toward name resolution; a large gap before connection or TLS completion suggests setup delay; a long wait until TTFB can include network travel and origin processing; and a large difference between TTFB and total time suggests substantial response transfer time.
Check cache behavior and browser timing
Inspect response cache headers, including cf-cache-status where applicable, to determine whether a request was served from cache or went to the origin. A cache miss is not automatically a fault: the content may be intentionally uncached, personalized, or too fresh to reuse. Use browser Resource Timing to see how individual page resources behave, and distinguish network timing from the browser’s later parsing and rendering work.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Test from relevant locations and connection conditions
Run tests from geographic regions where your visitors live. One measurement location cannot represent every ISP, device, route, or time of day. MDN recommends network throttling to make tests better represent people using high-latency or lower-quality connections. Combine synthetic tests with real-user monitoring: synthetic tests are repeatable, while real-user data shows the range of conditions visitors actually encounter.
For real-user timings, examine p50, p75, and p95 rather than relying only on an average. The median can conceal a poor experience for a substantial slower segment, while a high percentile helps reveal the tail. Compare these percentiles alongside TTFB, cache-hit ratio, and error rates, and record results before and after one change at a time.
How to reduce latency: work from diagnosis to remediation
- Separate the bottleneck. Measure DNS lookup, TCP connection, TLS setup, TTFB, transfer time, cache status, and browser rendering. Identify which stage dominates for the affected audience and requests. Avoid changing infrastructure based solely on a page’s overall load time.
- Cache content at an edge when it is safe to reuse. Start with versioned static assets such as fingerprinted images, scripts, stylesheets, and fonts. Cache other responses only when their freshness and privacy requirements permit it. A nearby edge cache hit can avoid a trip to the origin; Cloudflare’s guide describes cached responses dropping from hundreds of milliseconds to a few milliseconds, a vendor description rather than a guaranteed result.
- Place the origin or compute nearer to major visitor populations. If a request must be processed dynamically at the origin, choose a region near the largest user groups or consider multi-region compute. AWS recommends moving content or systems closer to users and describes Local Zones and CloudFront as options. Consider whether the workload can operate correctly across locations before distributing it.
- Improve routing when measurements justify it. Tiered caching can reduce repeated fetches to an origin. Managed routing may avoid congested paths; Cloudflare reports an average 30% latency reduction for Argo Smart Routing. That is a product claim, not a result to assume for your site. Test against your own user measurements and operating costs.
- Reduce request and transfer work. Resize and compress images, use efficient image formats, minify and split CSS and JavaScript where appropriate, remove unnecessary third-party calls, and avoid render-blocking resources. Reuse persistent connections and configure HTTP caching headers correctly. These measures reduce avoidable work; they cannot erase the travel time to a distant endpoint.
- Re-test by region and over time. Compare p50, p75, and p95 real-user timings, TTFB, cache-hit ratio, and error rates before and after each change. Check that an apparent latency improvement has not caused stale content, broken cache invalidation, privacy exposure, reduced reliability, or unsustainable operating costs.
Requirements to check before changing architecture
Document where visitors are located, which requests are static, how often content changes, and which responses contain private or personalized data. This inventory determines whether an edge cache can answer a request safely or whether every request must reach application code. Record the freshness requirement for each response: a versioned asset can often remain cached until its URL changes, while frequently updated content may need short lifetimes or explicit invalidation.
For a multi-region origin, verify that databases, sessions, queues, and other dependencies work across locations. A second compute region can shorten the network path but still leave a request waiting on a distant database. It also adds deployment, monitoring, failover, and data-movement decisions. Define success metrics before rollout—regional TTFB, p75 and p95 page timing, cache-hit ratio, errors, and cost—so an infrastructure change can be judged against the experience it is meant to improve.
Rank #4
- Next-Gen Gigabit Wi-Fi 6 Speeds: 2402 Mbps on 5 GHz and 574 Mbps on 2.4 GHz bands ensure smoother streaming and faster downloads; support VPN server and VPN client¹
- A More Responsive Experience: Enjoy smooth gaming, video streaming, and live feeds simultaneously. OFDMA makes your Wi-Fi stronger by allowing multiple clients to share one band at the same time, cutting latency and jitter.²
- Expanded Wi-Fi Coverage: 4 high-gain external antennas and Beamforming technology combine to extend strong, reliable, Wi-Fi throughout your home.
- Improved Battery Life: Target Wake Time helps your devices to communicate efficiently while consuming less power.
- Improved Cooling Design: No heat ups, no throttles. A larger heat sink and redefined case design cools the WiFi 6 system and enables your network to stay at top speeds in more versatile environments.
Cost and operational trade-offs
A CDN bill can include requests, transferred traffic, cache storage, invalidations, and optional security or routing features. A closer or multi-region deployment can add compute instances, replicated services, data transfer, deployment automation, and operations work. Managed routing may improve a congested path, but it introduces another service charge and another layer to observe. Compare those recurring costs with the number of requests that actually avoid the origin and the value of faster service for the affected regions.
Do not evaluate cost only on a cache-hit test. Measure traffic patterns, misses, invalidation frequency, origin egress, and failure behavior under load. A low-cost configuration that serves stale private data or fails when one edge is unavailable is not a successful optimization. Include privacy review, cache-key design, purge procedures, and regional observability in the implementation plan.
CDN edge caching or closer hosting?
A CDN and a closer origin address different parts of the problem. Edge caching is usually the fastest first option for cacheable static content because a hit can serve a copy near the visitor. Closer or multi-region compute is more relevant when each request must reach an origin for fresh or personalized processing. The right choice depends on where users are, what can be cached, and how long origin work takes.
| Decision factor | Edge caching with a CDN | Closer or multi-region hosting |
|---|---|---|
| User geography | Useful when visitors are spread out and nearby edge locations can serve content. | Useful when important visitor groups are far from the current origin and requests need origin processing. |
| Cacheability | Best suited to static assets and responses that can safely be reused. | Relevant when a response must be generated for each request or cannot be served from cache. |
| Dynamic-request frequency | Can help only to the extent requests or parts of responses can be cached; a miss still needs origin work. | Can shorten the path for dynamic requests if compute is placed nearer to the users who make them. |
| Freshness and invalidation | Requires cache lifetimes and invalidation behavior that match how quickly content must change. | Does not by itself solve stale edge copies, but requires keeping distributed systems and data consistent where applicable. |
| Origin processing time | Does not make uncached origin computation faster; it can reduce how often the origin is asked for cacheable content. | May reduce network travel to compute, but does not automatically make slow application or database work faster. |
| Routing control | Some managed services offer routing options; benefits need to be verified against your traffic. | May provide control over where requests are processed, but introduces deployment and operations decisions. |
| Observability and reliability | Assess cache status, regional performance, error rates, and behavior when an edge cannot serve a request. | Assess per-region performance, error rates, and the reliability of the application and its dependencies across locations. |
| Cost | Account for service, traffic, cache, and invalidation costs under your usage and service terms. | Account for additional compute, data movement, deployment, and operations costs under your architecture. |
These approaches are not mutually exclusive. A site can cache static assets at the edge while serving dynamic requests from a region chosen for its users. Decide from measured request patterns rather than assuming that a CDN alone will fix a slow origin or that moving the origin will help assets already served quickly from cache.
Common mistakes when trying to make a site faster
- Confusing bandwidth with latency. More transfer capacity may help large downloads, but it does not necessarily reduce the time before a response begins.
- Optimizing only from one test location. A nearby test can hide long routes for visitors elsewhere. Measure where your users are and inspect real-user variation.
- Putting dynamic or private responses into an unsafe cache. Caching decisions must account for freshness and privacy. Test cache rules and invalidation before relying on them.
- Expecting image compression to solve every delay. Smaller files can transfer faster, but request setup, origin waiting, and distance may still dominate.
- Buying routing improvements without a baseline. A product’s stated average is not a site-specific promise. Compare your own regional measurements and costs before and after deployment.
- Changing several things at once. If hosting, caching, and assets all change together, it becomes difficult to identify which change helped or introduced a problem.
A practical prioritization rule
If suitable static content is slow for distant users, test edge caching first. If requests that cannot be cached have high TTFB across distant regions, investigate origin processing and location. If setup time is the main issue, inspect connection reuse and request patterns. If transfer dominates, reduce payload size. If network timings are acceptable but the page still appears late, focus on rendering and blocking resources. Recheck the result with both regional tests and real-user data before treating the issue as fixed.
Implementation checklist
- List the countries, regions, devices, and networks that account for most visits.
- Record baseline DNS, TCP, TLS, TTFB, total time, cache status, p50, p75, p95, and error rates for important URLs.
- Classify each response as public or private, static or dynamic, and tolerant or intolerant of staleness.
- Give versioned assets long-lived cache rules where appropriate, and document how invalidation works for content that changes.
- Test an edge-cache configuration against a direct-origin request from several relevant regions.
- For uncached requests, profile application and database wait separately from the network path.
- Change one major variable at a time, then monitor regional results and costs over a representative period.
Frequently Asked Questions
Why is my website slow even with fast internet?
Bandwidth affects how much data can be transferred, but latency affects how long each round trip takes. DNS, TCP and TLS setup, distance, routing, origin processing, and many separate requests can delay a page even on a fast access connection.
Best Value
- 𝐆𝐢𝐠𝐚𝐛𝐢𝐭 𝐖𝐢𝐅𝐢 𝐟𝐨𝐫 𝟖𝐊 𝐒𝐭𝐫𝐞𝐚𝐦𝐢𝐧𝐠 – Up to 5400 Mbps WiFi for faster browsing, streaming, gaming and downloading, all at the same time. Performance varies by conditions, distance to devices, & obstacles such as walls.
- 𝐅𝐮𝐥𝐥 𝐅𝐞𝐚𝐭𝐮𝐫𝐞𝐝 𝐖𝐢𝐅𝐢 𝟔 𝐑𝐨𝐮𝐭𝐞𝐫 – Equipped with 4T4R and HE160 technologies on the 5 GHz band to enable max 4.8 Gbps ultra-fast connections.Power:12 V 2.5 A
- 𝐂𝐨𝐧𝐧𝐞𝐜𝐭 𝐌𝐨𝐫𝐞 𝐃𝐞𝐯𝐢𝐜𝐞𝐬 – Supports MU-MIMO and OFDMA to reduce congestion and 4X the average throughput
- 𝐄𝐱𝐭𝐞𝐧𝐬𝐢𝐯𝐞 𝐂𝐨𝐯𝐞𝐫𝐚𝐠𝐞 - Covers up to 2,000 sq. ft. High-Power FEM, 6× Antennas, Beamforming, and 4T4R structures combine to adapt WiFi coverage to perfectly fit your home and concentrate signal strength towards your devices.
- 𝐌𝐨𝐫𝐞 𝐕𝐞𝐧𝐭𝐬, 𝐋𝐞𝐬𝐬 𝐇𝐞𝐚𝐭 – Improved vented areas help unleash the full power of the router
Will a CDN make every website faster?
A CDN can reduce latency for cacheable content by serving it from a nearby edge. It will not automatically speed up uncached, personalized requests or slow application and database work at the origin.
How do I reduce latency for visitors in other countries?
Measure those regions first. Cache suitable static content at nearby edges, place dynamic compute nearer to major user groups, and check routing and origin TTFB. Validate improvements with regional synthetic tests and real-user percentiles.
Recommended Free Tools
What is a good latency number for a website?
There is no single universal target. Compare DNS, connection setup, TTFB, transfer time, and p50, p75, and p95 results for the regions and requests that matter to your audience.
Should I move my server or use a CDN?
Use a CDN first when cacheable assets are the problem. Move or distribute compute when requests must reach an origin and distant users have high TTFB. Many sites use both approaches.
Can compressing images remove network latency?
Compression reduces transfer work and can improve loading, but it does not remove DNS, connection setup, propagation, routing, or origin-processing delays.
How can I tell whether a cache is helping?
Inspect cache headers such as cf-cache-status where available, compare cache hits with misses, and track regional TTFB, cache-hit ratio, total timing, and errors over time.
Free tools Windows power users keep installed
One-click scans. No signup required.
The Bottom Line
Network latency is the delay in a request’s round trip, not a measure of bandwidth. Measure DNS, TCP, TLS, TTFB, transfer, cache status, and browser timing from the regions that matter. Then cache safe content near visitors, locate unavoidable compute appropriately, reduce unnecessary requests, and verify p50, p75, p95, errors, freshness, privacy, reliability, and cost after every change.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
