How to Run a Ping Test and Read Latency

Use it to separate “the path is sick” from “the page is heavy.” Then stop. Ping will not tell you which image is the LCP element.

ICMP, HTTP, and WebSocket are not the same ping

ICMP echo is what ping on Windows, macOS, and Linux sends. Many hosts and firewalls drop it. A 100% ICMP loss can sit next to a perfectly healthy HTTPS site.

HTTP ping is a small request/response (HEAD or GET) timed in the browser or on a server. You are measuring TLS + HTTP as well as the network, unless the implementation is careful. That number is often higher than ICMP to the same IP, and that can be fine.

WebSocket ping is another application-level round trip. Useful if you are debugging a socketed app; still not ICMP.

When you read a result on DevOkk, treat it as application-level RTT from the probe’s network, labeled honestly as a ping test, not as a kernel ICMP statistic. If you need ICMP, use a machine you control and a host that permits it.

What a millisecond number includes

A single sample is:

time to resolve the name (if you typed a hostname) + time to reach the peer + time for the peer to answer + time back.

DNS can dominate the first probe and vanish on the next if the name is cached. That is why a first-hit 180 ms and a second-hit 25 ms can both be “correct.” If the name is the suspect, run DNS Record Lookup or Domain to IP separately - those also send the hostname, on purpose.

Average hides spikes. Min is the best path you saw. Max is the worst. Jitter (variation) is what video calls and game clients care about. A 40 ms average with 120 ms spikes is a different story than a flat 40 ms.

Your last-mile Wi-Fi, a VPN, and a distant anycast POP all move these numbers. Compare two vantage points before you file a ticket on the origin.

Loss versus a high average

High latency, no loss - usually distance, a slow middle hop, or a far region. Not automatically “the CPU is pegged.”

Loss - probes that never return. Congestion, rate limiting, or a host that does not answer this probe type. Short tests over-fit: 1/5 loss is 20% and might be noise.

Timeouts on every probe - the name may not resolve, the address may be unused, or the host may ignore this probe. Check DNS first. Confirm you are allowed to test the target. Do not keep retrying someone else’s infrastructure.

Traceroute / mtr (on your machine) is the next tool when you need which hop. A web ping will not draw that map.

How to ping a host you are allowed to test

1. Pick a public hostname or public IP you operate or have permission to measure. Documentation endpoints and your own edge: yes. 192.168.1.1 on a stranger’s LAN: no.
2. Open Ping Test and submit it. The identifier is sent so the remote side can respond.
3. Run enough samples to see min/avg/max, not one click.
4. If the name does not resolve, stop pinging and fix or inspect DNS.
5. If RTT is fine but users still complain, leave ping. Look at bytes, TTFB, and images - Lighthouse Simulator for a preset conversation, real Lighthouse for a page you own.

From a terminal on a box you control, ping and curl -o /dev/null -s -w '%{time_total}\n' are the same class of measurement: they also leave the machine.

When ping is the wrong first tool

• Certificate errors - SSL Certificate Checker, not ping.
• Wrong A record after a cutover - Domain to IP.
• CORS or cache - HTTP Header Viewer.
• Slow hero image - lazy-load and compression, not RTT. See How Lazy Loading Images Affects Page Speed.

Ping is also the wrong tool for “is this company real” or “what other sites share this IP.” That is not what a latency sample means.

Limits of a browser-based ping

The probe runs from a network - yours, or DevOkk’s, depending on how the tool is wired - not from every customer ISP. Firewalls that allow browsers but drop datacenter ranges will look “down” from a hosted probe and “up” from home.

It will not pierce NAT to a machine that never accepted the connection. It will not satisfy a compliance auditor. It will not stay local.

Used narrowly, it is still the fastest way to say “the path I have can reach this public host in N milliseconds.”

Ping the host, then blame the page if the path is fine

Open Ping Test, enter a public host you are allowed to probe, and read min/avg/max as a path sample. If the name is the unknown, start with DNS Record Lookup. If the path is fine, the delay is probably the page, not the ping.