Diagnosing and Resolving Slow or Unresponsive Web Pages After Entering a URL

During a ByteDance interview, candidates may be asked how to investigate a situation where entering a URL in a browser does not display the page; the first step is to determine whether the problem lies on the client side or the server side by checking basic network connectivity.

The typical workflow involves confirming that the browser can reach other sites, verifying DNS resolution to an IP address, ensuring a successful TCP three‑way handshake, and examining the HTTP response code (e.g., 404 indicates a wrong URL, 500 signals a server error, 200 means the request succeeded and the issue is likely in the front‑end code).

A real‑world case is presented where a friend’s website was extremely slow for most users but fast for the owner. Ping tests showed failure because the server’s firewall blocked ICMP, while HTTP monitoring indicated the network path was healthy. Packet capture confirmed normal TCP/TLS handshakes and low latency, so the problem was not network‑related.

Using the browser’s F12 developer tools revealed multiple CSS files that timed out; all of these files were hosted on the jsdelivr CDN, which is inaccessible from mainland China. Disabling the plugin that loads assets from this CDN resolved the issue and restored normal page load times.

Key takeaways: a failed ping does not necessarily mean the website is down; always verify TCP/TLS/HTTP first; employ browser dev tools to locate missing or slow resources; and avoid using CDNs that are blocked in the target region.