Website Troubleshooting · Updated October 10, 2026
Why Is My Website So Slow? 5 Free Ways to Test Server Response Time
A slow page can come from the origin server, a database, redirects, large assets, third-party scripts, or the visitor’s network. Start by measuring the specific URL and separating time to first byte (TTFB) from total page load; a single “ping” number cannot explain every delay.
Start with a connection baseline
PulseTools’ Latency & Speed panel can provide a limited HTTP round-trip reading to a CDN endpoint, which helps put your current connection in context. It does not request your website’s URL: its jitter is derived from the measured latency and its throughput figure is simulated, so use the tests below for target-site TTFB.
Open Latency & Speed Test1. Chrome DevTools Network panel
Open the page in Chrome, open DevTools, select Network, enable Disable cache, reload, and select the main document request. In Timing, inspect Waiting for server response (TTFB). Repeat several times and note whether the page is served from cache, since a cached response can hide origin work.
This measures a real browser request to that URL from your current location and device. Other requests, extensions, VPNs, and network conditions can influence the result.
2. Google PageSpeed Insights
Enter the exact page URL in PageSpeed Insights. Review its diagnostics for server response and the page’s other bottlenecks. Lab results are a controlled test; field data, when available, reflects real-user experience over time. A single report is a starting point, not a complete server trace.
3. WebPageTest waterfall
Use WebPageTest to inspect a page-load waterfall and compare runs from different test locations or connection profiles. Look at the document request’s initial wait as well as DNS, connection, TLS, redirects, and later asset requests. Availability and free test limits may change.
4. curl timing output
From Windows, run curl.exe in PowerShell; macOS and Linux can use curl. Replace the URL with the exact page to test.
curl.exe -s -o NUL -w "DNS %{time_namelookup}s | Connect %{time_connect}s | TLS %{time_appconnect}s | TTFB %{time_starttransfer}s | Total %{time_total}s`n" https://example.com/Run several requests and compare like conditions. TTFB includes network setup and server wait; it is not a pure measure of application execution time. On macOS or Linux, replace NUL with /dev/null and remove the Windows newline escape if needed.
5. PulseTools connection-latency check
Use the PulseTools Latency & Speed Test as a quick network-context check, not as a server monitor. It times a request to a CDN resource rather than your domain; the displayed jitter is calculated and the throughput animation is simulated. For your site’s TTFB, use DevTools, PageSpeed Insights, WebPageTest, or curl above.
What to do when TTFB is consistently high
Check redirects, cache hit/miss headers, origin location, server CPU and database traces, and dynamic page generation. Compare a cached page with an uncached request only when you can safely control the test. If TTFB is fine but the page still feels slow, inspect image bytes, render-blocking resources, JavaScript, and layout shifts separately.