Ping Is Fast but Your Website Is Slow? Don't Confuse Latency with Load Speed

Ping is fast, but the website is slow? Don't confuse latency with page load speed

When a website opens slowly, many people's first reaction is to open the command line:

ping example.com

The result shows latency of only a dozen milliseconds and no packet loss. But when they reopen the site in the browser, the page still takes two or three seconds to load, and images may take even longer to appear.

At this point, the easiest conclusion is: “The network is clearly fine, so the speed test must be inaccurate.”

In fact, Ping and page loading do not measure the same thing.

A fast Ping only means that the ICMP round-trip response from the current network to the target IP is fast. It does not prove that DNS resolution is fast, HTTPS connection setup is fast, server processing is fast, or that the CDN cache is hit. Nor does it prove that the page has few resources or that JavaScript executes quickly.

Treating Ping latency as website load speed is like knowing that a road is not far away and assuming that leaving home, passing through a toll booth, loading the goods, and delivering them back must all be fast.

Distance is only one part of it; the whole journey is much longer.

What does Ping actually measure?

Ping usually sends an ICMP Echo Request to the target and waits for an Echo Reply, then calculates the time required for the packet to make the round trip.

It is suitable for checking a few basic questions:

• Whether the target IP is reachable via ICMP;

• The approximate round-trip latency from the current network to the target;

• Whether packet loss occurs during continuous tests;

• Whether latency fluctuates significantly;

• When a domain name is used, which address the domain ultimately resolves to.

Microsoft's official documentation for the Windowspingping command also says it “verifies IP-level connectivity through ICMP echo requests and displays the round-trip time.” This definition already draws its boundary: Ping is not a complete web page visit.

SeeMicrosoft ping command description.

A normal Ping usually does not do the following:

• It does not establish the TCP connection required for a web page;

• It does not complete the HTTPS TLS handshake;

• It does not send a normal HTTP page request;

• It does not wait for PHP, Java, database, or API processing;

• It does not download CSS, JavaScript, images, fonts, or video;

• It does not execute JavaScript or render the page;

• It does not tell you whether the CDN returned a HIT or a MISS.

Therefore, “Ping is only 15 ms” and “the page takes 3 seconds to open” can both be true at the same time; there is no contradiction.

Opening a web page involves far more than one network round trip

After a user enters a URL in the address bar, the browser may go through the following processes in sequence:

Ping only observes a very basic part of these network round trips, and it uses a different protocol from web page access.

web.dev's definition of TTFB also explains that time to first byte itself can include redirects, DNS, connection, TLS negotiation, and waiting before the server starts responding.

In other words, even if basic network latency is low, later connection and server processing can still make TTFB longer. Seeweb.dev's TTFB explanation.

Ping is fast but the website is slow: these are the usual causes

DNS resolution is slow, but Ping results do not clearly show it

When runningping example.comPing, the system usually must first resolve the domain name to an IP address before it starts sending ICMP requests.

The common “10ms, 12ms, 11ms” in the command output generally indicates the round-trip time of subsequent ICMP packets, not the full DNS resolution time.

If a domain has a long CNAME chain, the authoritative DNS response is unstable, or recursive DNS performs differently across networks, users may already have waited for some time before a connection is even established.

In this case, the round-trip latency shown by Ping can still look excellent. For troubleshooting methods, see“Can Slow DNS Resolution Slow Down a CDN? How to Troubleshoot Domain Resolution Time”.

Fast ICMP does not mean TCP, TLS, and HTTP are equally fast

Network devices can apply different policies to ICMP and business traffic.

Some servers do not respond to Ping but serve websites normally; some servers reply to ICMP quickly, while the HTTPS port is under queuing, packet loss, or processing pressure.

Web page access also requires TCP or QUIC connection establishment and TLS negotiation. Even if each round trip is only 20 ms, multiple handshakes, redirects, and new connections can add up to a noticeable increase in time.

Therefore, a Ping timeout does not necessarily mean the website is down; a fast Ping also does not necessarily mean HTTPS access is normal.

The CDN node is close to the user, but the cache is not hit

This is a very common situation after using a CDN.

The user Pings a nearby CDN edge node, so latency is low. But after the request reaches the node, if the resource is not cached, the cache has expired, or the page itself cannot be cached, the CDN still needs to fetch from the origin.

If the origin is far away, bandwidth is insufficient, or application processing is slow, users will experience this process:

Fast to the CDN node → CDN waits a long time for the origin → browser does not receive the first byte for a long time

At this point, you should check the cache status, Age, TTFB in response headers and origin logs, rather than repeatedly Pinging the node.

For how to determine cache status, see“How to Check CDN Cache Hits? Understanding HIT, MISS, and Age”.

Slow server or database processing

Ping requests do not go through the website's business application or database.

An IP can reply to ICMP within a dozen milliseconds, but an endpoint on the same server may take seconds to respond because of the following:

• Database queries lack indexes;

• External APIs respond slowly;

• Insufficient PHP, Java, or Node.js worker processes;

• CPU, memory, or disk bottlenecks;

• Application locks, queues, or connection pools are congested;

• The page must be generated in real time and cannot be cached directly;

• The origin triggers rate limiting during peak hours.

These problems usually show up as TCP and TLS connections that are not slow, but a long time to first byte.

This requires application monitoring, slow query analysis, server load, and endpoint path analysis. Client-side speed testing alone cannot determine which line of code is slow.

First byte is fast, but file downloads are slow

A website starting to respond quickly does not mean all content can be transferred quickly.

If page images are large, JavaScript bundles are excessive, video files are not properly segmented, or the node's actual throughput is insufficient, TTFB can be low while total download time is still long.

Ping packets are usually very small and cannot represent the sustained transfer speed of multi-MB files.

To evaluate download capability, use a real file of a fixed size and observe download time, average speed, and whether the transfer is interrupted.

HTML is fast, but third-party resources hold the page back

The website's own HTML may return quickly, but the page also references ads, analytics, customer service, maps, fonts, payment components, or other third-party scripts.

If any third-party resource in the critical rendering path has a slow connection, users may see a blank page for a long time, or buttons may remain unresponsive.

At this point, Pinging the main domain is meaningless, because the actual slow resource is on another domain.

Open the browser developer tools and sort requests by time; this usually shows directly which domain or resource is consuming the time.

Network requests are complete, but the browser is still busy

Some pages are not “slow to download”; rather, after download completes, the browser needs to execute a large amount of JavaScript, calculate layout, or render complex components.

Common signs include:

• Resources in the Network panel complete quickly, but the page is still stuck;

• CPU usage rises significantly;

• The page is visible but cannot be clicked for a long time;

• Low-end phones are much slower than computers;

• The page stutters when scrolling, typing, or switching sections.

In this case, look at LCP, INP, long tasks, and main thread activity, rather than continuing to optimize Ping latency.

A CDN can help deliver resources faster, but it cannot automatically eliminate the execution cost of front-end code.

Ping is fast on the current network, but not necessarily in other regions

A local Ping only represents the result from the current device, current ISP, and current moment to a particular resolved IP.

CDNs schedule different users to different nodes based on region, ISP, and DNS results. You may get only 10 ms when Pinging a nearby node on Shanghai Telecom, but that does not mean users on Chengdu Mobile, Beijing Unicom, or overseas will hit the same node.

For regional complaints, useCdnChart website speed testto observe resolved IPs, connection time, TTFB, download time, and failures from different regions and ISPs, rather than treating the office network's Ping result as national performance.

Average latency is low, but packet loss and occasional jitter exist

Looking only at the average of four Pings can also miss problems.

For example, most requests are only 15 ms, but occasionally jump to 300 ms, or there is a small amount of packet loss. Web page loading usually involves multiple requests, and retransmission of any critical resource can slow down the overall experience.

Therefore, when using Ping, at least look at:

• Whether there is packet loss;

• Minimum, maximum, and average latency;

• Whether latency fluctuation is significant;

• Whether the problem occurs only during peak hours;

• Whether IPv4 and IPv6 results differ.

Ping is still valuable; you just cannot look at only one average number.

Don't guess—use this table to determine which part is slow

This table cannot replace logs, but it can help you move from “the website feels slow” to a more specific troubleshooting direction.

Step 1: Use Ping correctly and record what it can provide

On Windows, you can run:

ping example.com

On Linux or macOS, you can increase the number of tests:

ping -c 10 example.com

Record the resolved IP, average latency, maximum latency, and packet loss rate.

If the website supports both IPv4 and IPv6, test them separately so that a problem on one protocol path is not overlooked.

However, do not stop troubleshooting just because Ping is normal. It only completes the first basic check.

Step 2: Break down web page request time with curl

The following command can show the resolved IP, status code, DNS, connection, TLS, first byte, total time, and download speed:

curl -L -o /dev/null -sS \
  -w 'status=%{http_code}\nremote_ip=%{remote_ip}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\nsize=%{size_download}\nspeed=%{speed_download}\n' \
  https://example.com/

The official curl manual clearly explains the meaning of these fields:

• time_namelookup: from start to completion of domain name resolution;

• time_connect: from start to completion of TCP connection;

• time_appconnect: from start to completion of application-layer connection such as TLS;

• time_starttransfer: from start to receipt of the first byte;

• time_total: time required to complete the entire operation.

For detailed definitions, seeofficial curl manual.

Most of these values are cumulative from the start of the request and cannot simply be added together.

For example:

• time_connectalready includes the previous DNS time;

• time_appconnectusually includes the DNS and TCP connection process;

• time_starttransferalso includes previous connection and server wait time.

Also, a single curl result only represents the current network and moment. It is advisable to repeat the test and observe both cache HIT and MISS, so that an incidental result is not mistaken for long-term performance.

Step 3: Open the browser Network panel and see which request is holding up the page

Take Chrome as an example:

1. PressF12to open developer tools;

2. Go to the Network panel;

3. CheckDisable cacheto simulate a first visit;

4. Clear existing records and refresh the page;

5. Sort by Duration or Waterfall to observe slow requests;

6. Click a specific request to view Timing, status code, protocol, and remote address;

7. Check HTML, JS, CSS, images, fonts, and third-party APIs separately.

Chrome's official documentation states that the Network panel can record requests and display status, protocol, remote address, response size, total time, and waterfall; disabling cache is closer to a first visit.

SeeChrome DevTools Network reference.

When checking, do not focus only on the homepage HTML. Many cases of “slow website” are actually caused by a large image, a third-party font, or an API that takes a long time to respond.

Step 4: Test across multiple regions and ISPs; do not trust only the local network

When local Ping and browser results are normal but users still report slowness, expand testing to the regions where real users are located.

At minimum, record:

测试时间、地区、运营商、解析IP、HTTP状态码、
DNS耗时、TCP耗时、TLS耗时、TTFB、总耗时、
下载速度、响应大小、缓存状态、失败原因

When usingCdnChart website speed test, the focus is not on finding the fastest node in this round, but on identifying patterns:

• Whether a particular ISP is generally slower;

• Whether a particular region is scheduled to a distant node;

• Whether P50 is normal but P95 is very high;

• Whether some nodes return different status codes;

• Whether the failure rate rises significantly during peak hours.

If you need to judge whether data from different speed-test platforms is reliable, see “How to Choose a CDN Speed Test Site? Check Nodes, Metrics, and Result Records First.”

Step 5: Combine CDN, origin, and real user data

External speed tests can tell you “where it is slow and at which stage,” but they may not directly explain why the origin is slow internally.

Continue checking:

• CDN cache hit rate and origin fetch ratio;

• CDN status codes, origin status codes, and request logs;

• Origin CPU, memory, disk, network, and connection counts;

• Database slow queries and connection pools;

• API and third-party dependency latency;

• Real page performance for users in different regions;

• Page LCP, INP, and error rate.

Synthetic tests and real user data each have their role.

Synthetic tests have more consistent conditions and are suitable for reproduction and horizontal comparison; real user data includes differences in devices, networks, and page interactions and is closer to the final experience.

When both point to the same problem, the judgment is usually more reliable.

A few common misjudgments

Ping to Baidu or a public DNS is fast, so there is no problem with the website's network

Different targets have different server locations, ISPs, routes, and loads.

A fast Ping to a public DNS only means the path to that public DNS is good; it does not represent the access path to the target website.

The domain cannot be Pinged, so the website must be down

Not necessarily. Servers or CDNs may restrict ICMP responses, while HTTP/HTTPS still works normally.

You should continue checking DNS resolution, TCP connection, and HTTP status codes.

The Pinged IP is local, so the CDN must have hit the nearest node

IP geolocation databases and ISP attribution can be inaccurate, and “geographically close” does not equal the optimal network path.

You also need to consider ASN, actual routing, connection time, and results from different ISPs.

TTFB is low, so the web page must be fast

TTFB only indicates when the response starts to arrive.

After that, there may still be large file downloads, image decoding, JavaScript execution, and rendering blocking. TTFB matters, but it is not the complete page load speed.

Average Ping is low, so the network is very stable

Averages can hide occasional high latency and a small amount of packet loss.

You should also look at maximum values, fluctuation, packet loss rate, and cover real business peak hours.

Frequently Asked Questions

How many milliseconds is considered fast for Ping?

There is no single answer independent of distance and business scenario.

Nodes in the same city or nearby are usually lower than cross-border nodes, but what matters more is whether results are stable, whether there is packet loss, and whether actual TCP, TLS, TTFB, and page experience meet business requirements.

Why are the results different when Pinging a domain and Pinging a server IP?

The domain may go through a CDN or intelligent DNS and resolve to an edge node; the server IP may be the origin or another network address.

The two targets are different, so latency can naturally differ. First record the domain's actual resolved IP, then confirm whether you are comparing the same target.

After using a CDN, does Ping target a CDN node or the origin?

Usually, when Pinging a domain, it pings the CDN node IP finally returned by DNS, not the origin.

But it depends on the domain resolution result, CDN integration method, and current scheduling. You can useCdnChart CDN checkto check CNAME, node IP, and the CDN possibly in use.

Ping is fast but TTFB is high. What should I check first?

First check the cache status.

If it is a MISS or a dynamic request, check CDN origin fetch, origin application, database, and external APIs; if it is a HIT but still slow, check edge node processing, network connection, and the statistical scope of the test metrics.

If a website opens slowly, will switching CDNs solve it?

Not necessarily.

If the slowness is in regional scheduling, cache hits, or static resource downloads, adjusting the CDN may help; if the slowness is in the database, backend APIs, third-party scripts, or browser execution, simply switching CDNs will hardly solve it.

First break down the time into DNS, connection, TLS, TTFB, download, and rendering, then decide whether to optimize DNS, CDN, origin, or front end. Ping can serve as the starting point for this troubleshooting, but it should not be the final conclusion.