How to Test a Slow Website? A Guide to Website Speed Testing, TTFB, and Performance Troubleshooting

Many site owners and Operation and maintenance have encountered this: your homepage loads instantly on your office computer, but customers complain about slow loading on WeChat; or tests from Shanghai Telecom nodes are fine, but Beijing Unicom users are stuck staring at a blank screen. You check the server CPU and bandwidth—they're idle, and speed tests show no errors, yet the page takes forever to deliver content.

Website speed testing is not just about seeing "how many seconds it took to load." This article provides a practical performance troubleshooting guide, from DNS resolution latency and Ping/RTT round-trip time to TTFB response and Core Web Vitals, helping you break down the entire access chain and pinpoint exactly where your website is slow.

1. Why Is Your Website Slow to Open?

Let's clarify a common misconception first: A slow website doesn't necessarily mean poor server performance.

A normal webpage visit roughly involves the following steps:

User enters URL ↓ DNS resolution ↓ TCP connection established ↓ HTTPS / TLS handshake ↓ HTTP request sent ↓ Server processes request ↓ First byte returned (TTFB) ↓ HTML downloaded ↓ CSS / JavaScript / images / fonts loaded ↓ Browser renders page

If DNS resolution takes 500ms, the browser has already wasted half a second before even connecting to the server; if network RTT is high, every handshake adds more wait time; if the network is fast but the server takes two seconds to process a dynamic page, TTFB will be high as well.

Even if the server and network are fine, a multi-megabyte hero image or several render-blocking JavaScript files can leave users staring at a blank screen for a long time.

Therefore, website speed testing isn't about a single number—it's about a set of metrics.

When troubleshooting website speed, if you can first determine whether the problem is "network slow," "server slow," or "page resources slow," subsequent optimization becomes much easier.

2. Step 1: Use Multi-Node Website Speed Testing to Identify Which Users Are Affected

If your own access is slow, it doesn't mean all users are slow. Similarly, if your access is instant, it doesn't mean users in other regions have normal access. This is an easily overlooked point in website performance troubleshooting.

Suppose your server is deployed in Shanghai, and you're also in Shanghai. Local access latency might be just a few dozen milliseconds. But when users from Beijing Unicom, Guangzhou Mobile, Xi'an Telecom, or even overseas access, the network paths are completely different, so speeds can vary greatly. When facing slow website loading, the first step shouldn't be repeatedly pressing F5, but rather using Chahu for a multi-region, multi-ISP website speed test.

Chahu provides website speed testing, online Ping, TCPing, DNS lookup, and traceroute capabilities, covering China Telecom, China Unicom, China Mobile, as well as Hong Kong, Macau, Taiwan, and overseas nodes—ideal for observing access differences across regions and ISPs.

When testing, choose the same URL and focus on these questions:

1. Is there a significant latency gap among core hub nodes like Beijing, Shanghai, Guangzhou, and Shenzhen?

2. Among Telecom, Unicom, and Mobile, is one ISP particularly slow?

3. Are there widespread node timeouts or high packet loss?

4. Is DNS resolving to different IPs in different regions?

5. During evening peak hours, is the data noticeably worse than during the day?

Here's a typical example from real troubleshooting:

With this data, you absolutely cannot conclude "server performance is poor." Since southern Telecom and Mobile are normal, the problem clearly lies with the northern Unicom lines or cross-network interconnection.

But if dozens of nodes all hover above 2 seconds, don't doubt it—shift your focus to the server, database, or backend application.

Use the following table to quickly interpret multi-node speed test results:

The core value of multi-node speed testing isn't to report to your boss that "the average website load time is X milliseconds," but to help you narrow down the battlefield in the shortest time.

3. Step 2: Check If DNS Resolution Is Slowing Down Your Website

When a user types a domain in the browser, the computer doesn't know where the server is—it must first ask a DNS server for the IP address corresponding to that domain.

Usually, DNS resolution is fast and easily overlooked. But if your DNS provider has a minor issue or configuration is improper, users may be stuck waiting at the entrance before even reaching your server.

Compare normal access with abnormal access:

• Normal: DNS 32ms➔ Connect 48ms➔ Server response 180ms (smooth)

• DNS bottleneck: DNS 650ms➔ Connect 50ms➔ Server response 180ms (stuck at the entrance)

If it's the latter, tweaking server programs is futile.

When running DNS queries in Chahu, focus on resolution effectiveness across different regions. If you find that DNS responses from a particular ISP are unusually slow, or IPs resolved in different regions show abnormal deviations (e.g., Guangdong users resolved to a Xinjiang node), it's time to check your DNS hosting provider's configuration, TTL refresh times, or resolution line planning.

If the resolved IP is wrong, all subsequent Ping, TCP connections, and rendering will be affected.

4. Step 3: Test Ping and Network Latency, but Don't Rely Solely on Ping

When it comes to speed testing, most people's first reaction is "just Ping it."

Ping reflects the physical round-trip time (RTT) between the test node and the server.

• If Ping is 25ms, the network link is excellent;

• If Ping is 180ms, packets are taking longer on the road (possibly due to distance or routing detours).

However, a low Ping does NOT mean a fast-loading webpage. This is a trap many have fallen into.

Consider a typical case:

• Ping: 30ms (excellent)

• TTFB: 1.6s (terrible)

The network is extremely smooth, but users still wait 1.6 seconds to see a response, indicating the bottleneck is on the server backend. Common causes include:

• Inefficient backend code (PHP/Java/Node.js, etc.);

• Slow database queries, missing indexes, or even deadlocks;

• Heavy calls to slow third-party APIs;

• CPU at 100% or database connection pool exhausted.

Conversely, if:

• Ping: 160ms

• TTFB: 230ms

This means the server processing took only a few milliseconds, with most time spent on the physical transmission line.

So, Ping can only answer: "Is the network reachable? Is the physical distance far? Is there packet loss on the line?" It cannot answer: "Can this webpage be displayed quickly?"

If you suspect network issues, use TCPing and traceroute to pinpoint where the bottleneck occurs.

5. Step 4: Focus on TTFB to Determine If Server Response Is Too Slow

If multi-node network latency is low but the website is still slow, the most critical metric to check is TTFB.

Simply put, TTFB is the time from when the browser sends a request to when it receives the first byte from the server.

If users click a link and the browser stays blank for a long time, then suddenly loads everything at once, that's a classic TTFB problem.

According to industry standards (e.g., Google web.dev recommendations):

Of course, don't apply this mechanically. A page serving static HTML and a backend system computing massive data in real time naturally have incomparable TTFB. The key is to compare changes for the same type of business over time or before/after optimization.

If TTFB is consistently high, focus on these 5 areas:

1. Server basic resources: Check if CPU, memory, or disk I/O are maxed out, or if concurrent connections have hit the limit.

2. Backend code performance: Look for infinite loops, overly complex logic, or high-cost encryption calculations.

3. Slow database queries: The most common culprit. SQL statements without indexes scanning tens of thousands of rows can instantly cripple response.

4. Blocking external dependencies: Are you synchronously calling SMS APIs, third-party payment, or external analytics APIs during request processing?

5. Missing dynamic caching: Pages that could use Redis or Memcached are hitting the database on every request.

Whenever you encounter the strange phenomenon of "low Ping but slow page," investigating TTFB on the backend will likely uncover the issue.

6. Step 5: Use a Waterfall Chart to Identify Which Resource Is Slowing Down the Page

Sometimes the server responds extremely fast—TTFB is just a few dozen milliseconds—but the browser's loading icon keeps spinning and the page never fully displays. In such cases, shift your focus from the "server" to "page resources."

Use the browser's built-in Chrome DevTools (F12) Network panel, or tools like WebPageTest and GTmetrix, to pull up the page's waterfall chart.

The waterfall chart lays out each resource's loading timeline:

[HTML] ---- 180ms [style.css] -- 90ms [main.js] ------------------------ 1.8s [banner.jpg] ------------------------------ 2.4s [vendor.js] -------- 720ms

In this case, even if you upgrade your server to the top tier, the website will still be slow. Because what truly ruins user experience is a multi-megabyte image or a slow-loading JS file.

When viewing the waterfall chart, focus on these:

• Large monolithic resources: Such as uncompressed original images or multi-megabyte frontend JS bundles.

• Render-blocking resources: Complex JS or CSS in the <head> that prevents the browser from rendering until downloaded and parsed.

• Unstable third-party scripts:

  • Third-party analytics code

  • Online customer service pop-ups

  • External font libraries/map components

  • Ad SDKs

Your main site's HTML might be delivered in 200ms, but if you have a third-party customer service script that takes 3 seconds to respond, users will still perceive "this website is too laggy."

7. Step 6: Check Core Web Vitals to See How Fast Users Actually See the Page

Fast network requests don't equal a satisfying user experience. To quantify the real visual and interactive experience, Google introduced Core Web Vitals, which include three key dimensions:

1. LCP (Largest Contentful Paint)

• What it measures: How quickly the largest core element in the viewport (big banner, product hero image, large heading block) becomes fully visible.

• Good threshold: ≤ 2.5 seconds.

• Common pitfall: Even if the server responds fast, if the homepage banner is a 5MB lossless PNG, LCP will be terrible.

2. INP (Interaction to Next Paint)

• What it measures: How quickly the page provides visual feedback after a user clicks a button or expands a menu.

• Good threshold: ≤ 200 milliseconds.

• Common pitfall: Some websites load fast, but clicking a button feels like the page is frozen—this is caused by the main thread being blocked by long tasks in JavaScript.

3. CLS (Cumulative Layout Shift)

• What it measures: Whether content unexpectedly jumps around during page load.

• Good threshold: Less than 0.1.

• Common pitfall: Just as you're about to click "Confirm," an ad suddenly appears at the top, pushing the button down and causing you to accidentally click "Cancel." This doesn't necessarily slow down speed, but it severely harms user experience.

​

8. How to Interpret Website Speed Test Results

After completing the above tests, you can quickly narrow down the scope based on the data.

The ultimate goal of troubleshooting isn't to see which metric is red, but to quickly find the most critical bottleneck and solve it precisely.

9. What Is a Normal Website Loading Speed?

There's no one-size-fits-all absolute standard in the industry. A backend admin system and an e-commerce homepage have completely different load requirements; domestic access to a domestic server and cross-border access to a European or American server have entirely different expectations.

For daily maintenance, refer to these experience-based benchmarks:

• DNS resolution: The faster, the better; aim for under 50ms;

• Ping / RTT: Same city/region < 30ms, cross-province same ISP < 80ms, cross-network/cross-border depends on the line;

• TTFB: For static pages, aim for < 300ms; for dynamic business pages, try to keep it under 800ms;

• LCP: Aim to complete core rendering within 2.5 seconds;

• INP: Interaction feedback should be within 200 milliseconds;

• CLS: Keep layout shift below 0.1.

Rather than obsessing over absolute milliseconds, comparing trends before and after optimization is more meaningful:

• Before optimization: Shanghai Telecom 1.6s / Beijing Unicom 2.3s / Guangzhou Mobile 1.9s

• After optimization: Shanghai Telecom 0.8s / Beijing Unicom 1.1s / Guangzhou Mobile 0.9s

This tangible performance improvement is the best testament to your optimization efforts.

Additionally, when conducting comparison tests, ensure variables remain consistent (use the same test nodes, network environment, time period, and URL).

10. How to Optimize Website Speed Based on Test Results

Once you've identified the bottleneck, you can apply targeted fixes:

1. If the bottleneck is DNS

• Switch to a more stable high-protection/smart DNS provider;

• Check for multiple CNAME nesting in domain resolution records;

• Adjust TTL cache time appropriately;

• Configure targeted resolution lines for different ISPs and regions.

2. If the bottleneck is high network latency

• Focus on high-latency regions and use traceroute to see if packets are taking detours;

• Deploy CDN acceleration to push static resources to edge nodes, allowing users to fetch them from nearby;

• For nationwide or cross-border business, avoid single data center and single line deployment; consider multi-line data centers or BGP lines.

3. If the bottleneck is TTFB (backend slow)

• Introduce Redis/Memcached to reduce direct database load;

• Optimize slow SQL queries and create proper database indexes;

• Enable page-level/API-level HTTP caching;

• Move time-consuming non-core logic (e.g., sending emails, SMS, logging) to asynchronous queues;

• Review and optimize backend code logic to reduce CPU and memory usage.

4. If the bottleneck is image download

• Upgrade formats: Use WebP or AVIF wherever possible instead of original PNG/JPG;

• Compress images: Use tools for lossless/lossy compression;

• Resize appropriately: Don't fetch a 4000×3000 original image when the frontend displays 400×300;

• Enable lazy loading for all below-the-fold images.

5. If the bottleneck is heavy JS/CSS

• Implement code splitting in frontend bundling to avoid putting all logic into one massive JS bundle;

• Enable Gzip or Brotli compression for static resources (typically reduces size by 60%–80%);

• Add defer or async attributes to non-essential JS to prevent blocking HTML rendering;

• Remove unused libraries or redundant code to reduce main thread execution time.

6. If the bottleneck is third-party services

• Load third-party analytics and customer service scripts asynchronously;

• Evaluate the necessity of non-core third-party components and remove them if possible;

• Self-host third-party CSS/font libraries to avoid external domain response delays affecting your main site.

When troubleshooting a slow website, the worst thing is to panic and try random fixes. Remember this standard process: First, use Chahu multi-node speed testing to identify regional and ISP differences; then check TTFB to confirm if the backend is slow; finally, pull up the waterfall chart to inspect frontend large images and JS blocking.

Once you've pinpointed the bottleneck, optimization can be precise. If your website is currently experiencing regional lag or high TTFB, follow the steps in this article to capture data. If you encounter uncertain waterfall chart nodes, feel free to leave a screenshot in the comments, and we'll analyze it together.