What Is Ping? Latency, RTT and Why Hosting Location Matters

What is ping and what does it measure?

Ping is a network command that checks whether your device can reach another host and how long the reply takes. It sends an ICMP echo request, waits for the echo reply, and prints the round trip time in milliseconds. In short, ping tells you that a connection exists and how fast it is.

Also, the name comes from the sound of sonar. A submarine sends a pulse and judges distance from the time the echo takes to return. For instance, ping works the same way, but with a tiny network packet instead of sound.

For site owners, ping is often the first number to check when choosing hosting. However, it never tells the whole story. In this guide we explain what ping measures, what it misses, and how it connects to hosting location and CDN decisions.

The short technical answer to what is ping fits in one line. The practical answer depends on who asks. A network admin sees a fault finder. For a site owner it is a quick distance check. Developers use it as the first health check after a deployment.

How does the ping command work behind the scenes?

Ping relies on ICMP, the Internet Control Message Protocol. RFC 792 defines it. In that document the echo message has type 8, and the echo reply has type 0. The sender transmits the echo, then the receiver sends the same data back.

RFC 792 says the data received in the echo message must come back in the echo reply. The receiver swaps the source and destination addresses, sets the type to 0, and recomputes the checksum. The sender then measures the elapsed time on its own clock.

This detail matters because the measured time covers the whole trip there and back. It is not a one way time. As a result, a ping result is really an RTT, or round trip time, value.

Note that ping does not test your web server software. It tests the network layer of the operating system. A crashed website can still answer ping, and a healthy website can still ignore it.

What is ping in a command output, and how do you read it?

The output below is an illustration. The values are made up, and the addresses come from the reserved documentation range. Real output differs slightly between operating systems.

$ ping -c 4 example.com
PING example.com (192.0.2.10): 56 data bytes
64 bytes from 192.0.2.10: icmp_seq=0 ttl=57 time=28.4 ms
64 bytes from 192.0.2.10: icmp_seq=1 ttl=57 time=27.9 ms
64 bytes from 192.0.2.10: icmp_seq=2 ttl=57 time=31.2 ms
64 bytes from 192.0.2.10: icmp_seq=3 ttl=57 time=28.1 ms

--- example.com ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 27.9/28.9/31.2/1.3 ms

Here is how to read each part:

• icmp_seq: the packet sequence number. A skipped number means a lost packet.
• ttl: the remaining number of routers the packet may cross. It drops at every hop.
• time: the round trip time of that packet, in milliseconds.
• packet loss: the share of packets that never got a reply.
• min/avg/max/stddev: the lowest, average, and highest time, plus the spread.

First, look at the average and the spread. If the average is low but the spread is high, the connection is unstable. That instability has a name: jitter. So one fast reply does not prove a fast connection.

What do packet loss and jitter tell you in a ping result?

Ping shows stability as well as speed. Packet loss is the percentage of packets that got no reply. If the loss is not zero, something on the path is dropping packets. It could be the line, a router, or the remote host.

Jitter is how much the reply times vary from one packet to the next. The deviation value in the ping summary gives you a rough idea. For example, a line with a 30 ms average may return packets in 25 ms one moment and 90 ms the next. That line has high jitter.

Why does this matter for a website? A page load consists of dozens of small requests. Each one uses the same line. Therefore an unstable line makes the page fast one minute and slow the next. Visitors describe that as a site that is sometimes slow.

So never trust a single ping run. Take a series of at least ten packets, and read the loss and the spread along with the average. Also repeat the test at different times of day to catch congestion patterns.

How do you use ping on Windows, macOS and Linux?

The command name is the same on all three systems. The difference lies in the flag that sets the packet count. According to the Microsoft documentation, Windows sends 4 requests by default, and you change that with /n. On macOS and Linux, ping runs until you stop it, and the -c flag limits the count.

Therefore, do not guess flag names on a system you do not know. Type man ping in a terminal, or ping /? on Windows. That way you only use options your own version supports.

What is latency, and is it the same as ping?

Latency is the time data spends travelling from one point to another. In other words, it is the general name for waiting time on a network. Ping is the simplest way to measure it. Still, the two are not identical.

Latency can describe one way or round trip time. In everyday speech people usually mean the round trip. Ping, however, only reports the round trip of one small ICMP packet.

For instance, a browser loading a page uses TCP, TLS and HTTP, not ICMP. Networks may treat these protocols differently from ICMP. Therefore ping is a rough indicator of real page latency, not an exact measure.

Latency has four main sources. First comes propagation delay, the time a signal needs to cover the distance. Second comes processing and queuing time inside routers and switches. Third come the connection setup steps. Fourth is the time the server needs to handle the request. Ping sees the first two, while TTFB and browser tools reveal the last two.

What is RTT, and how does it differ from latency?

RTT stands for round trip time. It is the total time a packet needs to travel from your device to the target and for the reply to come back. The time value in a ping output is exactly this number.

The difference between latency and RTT is a matter of direction. Latency is the general concept. RTT is its round trip measure. On a symmetric path, one way latency is roughly half the RTT.

On the internet, however, paths are not always symmetric. The way there and the way back may take different routes. So halving the RTT is only a rough estimate. For hosting decisions, RTT is the value that matters anyway, because every step of a new connection needs a full round trip.

What is the difference between latency, RTT and TTFB?

People mix these terms up all the time. The table below summarizes what each one measures and where you meet it.

In short, ping measures the network. TTFB measures the network, the connection setup and the server working time together. Bandwidth is a separate topic, and we cover it in its own guide.

What does TTFB include, and what counts as a good value?

According to web.dev, TTFB is the time between starting navigation to a page and the moment the first byte of the response begins to arrive. The documentation lists its parts: redirect time, service worker startup, the DNS lookup, connection and TLS negotiation, and the request phase until the first byte.

The same page gives rough thresholds. A TTFB of 0.8 seconds or less is good, between 0.8 and 1.8 seconds needs improvement, and above 1.8 seconds is poor. These are guidelines aimed at keeping the 75th percentile of users in the good range. They are not hard limits.

The key point is this: many parts of TTFB depend directly on round trip time. As distance grows, RTT grows, and every one of those parts slows down. That is where hosting location enters the picture.

Why does distance increase latency, and what is the speed of light limit?

Signals travel through cables at the speed of light, but not at the speed of light in a vacuum. In optical fiber, light slows to roughly two thirds of its vacuum speed. That is about 200,000 kilometers per second, or roughly 5 microseconds per kilometer.

A research paper titled Dissecting Latency in the Internet's Fiber Infrastructure examines where latency comes from in fiber networks. You will find the link at the end of this article. The takeaway here is simple: no software optimization changes physics.

Moreover, cables do not follow straight lines. They run under the sea, through cities and across many nodes. The real route is often longer than the straight line. Each router and switch also adds its own waiting time. Consequently, the theoretical time is always a lower bound.

Worked example: how much time does distance add before the first byte?

The table below is a worked example. Distances are straight line, and the speed is 200,000 kilometers per second. Real times run longer, so these numbers only show the physical lower bound.

Why 3 RTT in the last column? A new TCP connection needs one round trip for its handshake. The TLS 1.3 handshake adds one more. Then the HTTP request and the first response take the third. The DNS lookup and the server processing time are not part of this calculation.

In other words, a visitor 10,000 kilometers away waits at least roughly 300 milliseconds for the first byte, even if the server answers in a single millisecond. This example shows why distance matters. Serve the same connection from a nearby location, and the wait drops to a tenth.

What is a good ping time in milliseconds?

There is no official ping threshold. The ranges below are common rules of thumb. Treat them as a starting range, not as an official limit or a guarantee.

• Same city or region: usually around one to twenty milliseconds.
• Same continent, different country: usually twenty to eighty milliseconds.
• Different continent: one hundred milliseconds or more is common.
• Satellite and mobile links: can be clearly higher than wired links.

So use these numbers to find your direction, not as targets. If most of your visitors use mobile, their own line counts too. Also, on a heavy page the page structure matters more than ping.

What is ping time worth without context? Very little. Compare your own site against its own history instead. If yesterday's 30 ms became 120 ms today, something changed, whatever the absolute number. Sharing that change with your hosting provider helps far more than a vague verdict of good or bad.

Why can a site be slow even when ping is low?

Ping measures only the network path. Site slowness usually sits elsewhere. A slow database query, a heavy plugin or a missing cache delays the first byte on the server. In the browser, large images and too much JavaScript slow the page down.

So you diagnose layer by layer:

1. Use ping to confirm that the network path looks reasonable.
2. Check TTFB to judge the server and the connection setup.
3. Then inspect page weight, image sizes and scripts.
4. Finally, compare the result with real user data.

To complete this chain, read our guides on how site speed affects SEO, the Lighthouse performance test and caching approaches.

Does a silent ping mean the server is down?

No, not always. Many servers and firewalls block or rate limit ICMP on purpose. In that case ping times out, but the website opens fine. According to the Microsoft documentation, Windows shows a Request timed out message when no reply arrives. The default timeout is 4 seconds.

The right approach is to check through several channels. Open the site in a browser. Then check the DNS records and the IP details of the domain. Our DNS lookup tool and IP lookup tool help with that.

The opposite case exists too. If ping answers but the site does not open, the problem sits in the web server or the application layer. As a result, you can give your hosting provider accurate information.

ICMP is more than echo, too. RFC 792 also defines Destination Unreachable (type 3) and Time Exceeded (type 11). Routers use these messages to report network problems. Tools that show the hops along a path rely on them, and we cover that command in a separate guide.

What is ping's link to your hosting location?

Anyone who searches what is ping is often close to a hosting decision. Ping is the easiest way to see how close a server is to a visitor. A closer server means a lower RTT, and a lower RTT means a shorter connection setup.

However, the answer to what is ping does not end there. Ping shows network distance. Real site speed comes from TTFB, page weight and real user data together.

Here is a practical method. Ask candidate hosting providers for a test address, or ping the current server of your own domain. Then compare similar measurements from the cities where your audience lives. That way the location decision rests on numbers, not on guesses.

In short, ping works like a compass for location decisions. It is not the whole map. Before you decide, add a TTFB measurement and your CDN needs to the picture.

What should you look at when choosing a hosting location?

First, think about where your visitors are. If your audience sits mostly in one country, a location that serves that country or a nearby region makes sense. If visitors are spread across the world, a single location alone will not be enough.

Here is the decision list:

• Visitor distribution: check the country and city breakdown in your analytics report.
• Content type: is it mostly static pages, or personalized and dynamic?
• Legal requirements: where data is stored is a separate legal question, so ask your legal adviser.
• Provider network quality: two providers in the same city can have different network paths.
• Openness to testing: ask the provider for a test IP or a trial period.

We explain general selection criteria in our guide to choosing web hosting. Here we only cover the location and latency side.

How does a CDN reduce latency, and when is it not enough?

A CDN, or content delivery network, is a distributed network that stores copies of your content on servers in many places. web.dev describes it this way: CDNs solve the problem of user proximity by caching resources on servers that are physically closer to your users.

The same document notes that CDN providers usually offer fast DNS resolution and modern TLS versions. Protocols such as HTTP/3 stand out here too. As a result, the number of round trips during connection setup drops.

Still, a CDN does not solve everything. Requests that cannot be cached still travel to your origin server. A shopping cart, a logged in account page and a checkout step are examples. For these requests, the location of the origin server keeps its importance.

Hosting location or CDN: how do you decide?

The answer depends on your site structure. The table below gives a rough decision frame. It contains no figures, because the right choice only shows up in measurements from your own site.

The effect of page speed on sales is a separate topic. We covered it in does page speed affect ecommerce sales.

Consider one scenario. A local clinic in Istanbul has visitors almost entirely in Turkey. Then a location close to Turkey is usually enough. A store that sells to Europe and North America, by contrast, gains a lot by serving static images through a CDN. This is an example scenario, and the real decision comes from measurement.

What are the most common mistakes when measuring ping?

Ping looks simple, so people also misread it easily. These are common limits, and the official documents point to several of them:

• Deciding from one measurement: a single packet can be lucky or unlucky.
• Forgetting Wi-Fi: a weak signal at home looks like server latency.
• Measuring with a VPN on: traffic first travels to another country, so the time grows.
• Treating ping as page speed: ping measures the network path only.
• Reading a blocked ICMP reply as a crash: a firewall may drop the reply on purpose.

So clean up the environment before you measure. Use a wired connection, switch the VPN off, and run the test several times. Then the number you get really says something about the server and the path.

How do you measure latency yourself?

Also, a measurement from one point is not enough. Look at different times, and from different locations if you can. You can follow these steps:

1. Run ping -c 10 example.com in a terminal with your own domain, and note the average.
2. Repeat the same measurement at different times of the day.
3. Open the browser developer tools, go to the network tab and look at the waiting time of the main document request.
4. Read the server response time finding in your PageSpeed Insights and Lighthouse reports.
5. If possible, ask a friend abroad, or use an online measurement tool, to run the same test.

Once you put the results side by side, a pattern shows. For example, if the values stay high every night, peak hour congestion may be the cause. You can also follow the Core Web Vitals side in our Core Web Vitals guide.

How do you report a ping result to your hosting provider?

Instead of writing that your site is slow, attach the measurement. The provider can then tell faster whether the problem sits in its network or on your side. A good support ticket contains the following:

• The domain name or IP address you tested.
• The date, the time and the network you were on.
• The complete ping output, including the summary lines.
• Whether the problem is constant or only appears at certain hours.

Also, do not flood the target. Sending hundreds of packets at short intervals creates load, not a measurement. Some providers may treat that as abuse.

Does a secure connection add latency?

HTTPS adds a TLS handshake to connection setup. Therefore the first connection takes a little extra time. However, TLS 1.3 is designed to cut the handshake down to one round trip. On modern servers this cost is small.

So do not give up on security. HTTPS is now the standard that browsers expect and users trust. We explain how certificates work in our SSL certificate guide.

Redirect chains, on the other hand, are a real source of delay. According to web.dev, even one redirect adds unwanted latency, and it gets worse when that redirect points to another one. The HSTS header tells the browser to use HTTPS directly on later visits, which reduces such redirects.

When should you not do this yourself and leave it to your hosting provider?

Let us be honest: we are a digital marketing and web team, not a hosting company. Network routing, server hardware and data center links belong to the provider. In these areas you measure, but you do not intervene.

Contact your provider directly in these cases:

• Ping stays high and the cause is not on your side.
• Packet loss appears at certain hours.
• The server IP address needs a change, or the location needs a move.
• A firewall rule for ICMP needs a change, and you lack the permission.

If you decide to move, take a backup first. Our website backup strategy guide helps at that step.

How can we help with your site speed and infrastructure decisions?

However, our team does not provide hosting. We do look at how a hosting decision affects your site speed, your SEO and your conversions together. When we build or renew a site, we plan location, CDN and caching choices alongside the design and content plan.

If you want support, take a look at our web design service and our SEO consulting service. First we measure your current situation, then we decide together which step will really make a difference.

In short, ping shows the network, TTFB shows the connection and the server, and user data shows the real experience. Read all three together, and your hosting location and CDN decision rests on measurement, not guesswork.

Now that you know what is ping and how to read it, the next step is to measure your own site. Take a ten packet ping first. Then check your TTFB value. After that, look at your visitor distribution in analytics. With these three data points in hand, the hosting and CDN decision gets much clearer.

Sources: web.dev: Time to First Byte, web.dev: Optimize TTFB, Microsoft Learn: ping command, RFC 792: Internet Control Message Protocol, Dissecting Latency in the Internet's Fiber Infrastructure.