Diagnosing a slow website: server, network and browser

Identify which wait the visitor experiences

A slow page can wait for DNS, the connection, HTML generation, a font or a busy browser. Buying a larger server before locating that wait can leave the problem unchanged. Record the exact public URL, device, network, time and whether the visit was cold or warm. Use a normal anonymous page rather than an account response.

Read HTTP timings before changing infrastructure

curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' https://example.com/

This Linux/macOS shell example sends a GET and discards its body. On Windows, invoke curl.exe and adapt the output destination. Timings are cumulative seconds from the start: connect minus DNS approximates the TCP phase, and TLS minus connect approximates TLS for a simple direct HTTPS connection. First-byte time includes earlier setup; it is not purely database or PHP time. Reuse, proxies and redirects change interpretation. Inspect redirects separately and repeat against the final URL.

Run several comparable samples from the affected location and another location. Compare medians and variation rather than choosing the fastest result. Ping uses ICMP and may be filtered or follow different treatment; a fixed ping or jitter threshold cannot diagnose HTTPS performance by itself.

If the first byte is late

• Compare the requested route with a small static asset from the same host. A slow dynamic route with a fast asset points toward application work, but confirm with logs and request timings.
• Inspect CPU usage, runnable tasks, available memory, swap activity and disk latency during the affected period. Linux tools such as top, vmstat and iostat help when already available. Cached memory is not automatically memory pressure, and disk utilization alone is not a universal saturation test.
• Inspect slow database queries and their execution plans. An index should address a demonstrated query pattern and account for write costs; a full scan on a small table is not automatically a defect.
• Compare IPv4/IPv6 and DNS answers when only some networks are affected. Use the DNS verification workflow before changing records.

Read-only checks come first. Load testing belongs in an authorized controlled environment with limits and monitoring; sending a guessed burst of requests at production can affect existing users.

If HTML arrives quickly but the page appears late

Open the browser Performance and Network panels or a mobile PageSpeed report. Identify the actual LCP element and its dependencies. For text, a blocking stylesheet or late font can delay rendering. For an image, check discovery time, transferred size and priority. Do not lazy-load the main above-the-fold image. Reserve image dimensions and verify that font changes do not introduce visible shifts.

For slow interactions, examine main-thread tasks and the input delay, handler work and next paint. A server upgrade does not remove a long JavaScript task. Remove unnecessary work and split heavy handlers while retaining intended behavior. Hiding important content to get a lower LCP number is not a useful improvement.

A measured ServerNet example

On 10 October 2026, a mobile lab run for the ServerNet homepage measured LCP at 2.762 seconds, TBT at 71 milliseconds and CLS at 0.001. An earlier asynchronous stylesheet experiment caused CLS of 0.538 and was rejected. This is one page under test conditions, not a promise about every visitor or proof of a ranking change. The recorded report illustrates why improvements must be checked across several metrics.

Close the loop with a reversible change

Write down the suspected bottleneck and expected effect. Change one relevant factor, retain its previous configuration, then repeat the same measurements. Check functionality and shifts as well as speed. Roll back if the benefit is inconsistent or behavior regresses. Separate first-visit measurements from browser-cache reuse, then assess the longer trend with real-user data.

References: curl timing variables and LCP diagnosis.