How to Test the Speed of a Dynamic Website: Methods for Measuring Dynamic Page Response Time

Just because a website's homepage loads quickly doesn't mean its search page, login page, product detail page, or admin panel will be equally fast. The biggest difference between dynamic pages and ordinary static pages is that much of the content isn't prepared in advance. Instead, after a user sends a request, the server executes code, queries databases, and calls APIs in real time before generating the final page. If any one of these steps slows down, users may feel like the page is taking forever to respond.

So when testing a dynamic website, looking only at Ping, download speed, or how many seconds the final load took often makes it hard to identify the real problem. A more practical approach is to break the entire visit process apart and observe DNS, TCP, TLS, TTFB, server processing, API requests, and page rendering time separately. The real goal of dynamic website speed testing isn't simply to get a "fast" or "slow" result—it's to find out exactly which layer is slow.

1. What Is a Dynamic Website? Why Is the Testing Method Different?

Static pages can usually return existing HTML, image, CSS, or JavaScript files directly.

Their access flow is relatively simple: user request → web server / CDN edge node → return static file directly

Dynamic pages are different. After a user visits a dynamic page, the server may still need to execute code, read caches, query databases, or even call multiple internal or external APIs.

The rough process might be: user request → web server (Nginx/Apache) → application (PHP/Java/Node.js/Python) → database query (MySQL/PostgreSQL) → API/cache/permission check (Redis/API) → generate HTML in real time → return to user

Common dynamic pages include: WordPress article pages, e-commerce product detail pages, search result pages, login pages, user centers, shopping cart and order pages, SaaS admin panels, real-time data pages, and so on. Even if network latency is low, these pages can slow down because server processing takes too long. So when testing a dynamic website, you can't just look at "how fast resources download"—you also need to pay attention to how long the server takes before it starts returning content.

2. Which Metrics Matter Most for Dynamic Website Speed Testing?

You don't need to review every performance metric when testing a dynamic website, but the following are worth paying attention to.

The ones most worth focusing on are usually TTFB, API response time, and slow request distribution. That's because the real trouble spots for dynamic pages are often not file downloads, but the long time the server spends before it actually starts returning content.

Take a page like this:

DNS          20ms
TCP          35ms
TLS          45ms
TTFB         1200ms
Total load   1800ms

At this point, the network connection isn't showing any obvious abnormality. The real problem is more likely in server processing, database queries, or API calls.

3. How Do You Test a Dynamic Website's Speed?

For dynamic website speed testing, it's best not to rely on just one tool. You can first use Chahu multi-node speed testing to determine the scope of the problem, then use browser and server-side monitoring to narrow it down further.

1. Start with Chahu Multi-Node Speed Testing to Determine Whether It's Global or Local

If your website's users are spread across different regions, you can start by using Chahu for website speed testing.

After entering the URL you want to check, you can directly observe access performance across different regions and carriers.

When testing dynamic pages, it's worth focusing on a few questions:

• Is it slow in all regions?

• Is it only slow in certain regions?

• Are there obvious differences between Telecom, Unicom, and Mobile?

• Are there a lot of timeouts?

• Does response time fluctuate a lot?

For example:

Beijing Telecom      182ms
Shanghai Unicom      205ms
Guangzhou Mobile     194ms
Chengdu Telecom      188ms

If data from multiple nodes across the country is fairly close but overall on the high side, the problem is usually worth investigating on the server and backend side. If only certain regions or one carrier are noticeably slower, it looks more like a network route, cross-carrier interconnection, or CDN scheduling issue. The goal of this step isn't to directly find the bottleneck in the code—it's to figure out: is the website itself slow, or are only some users experiencing slowness?

2. Use Chrome DevTools to Inspect the Main Document and APIs

Open the target page, press F12 to enter the Network panel, check Preserve log, and refresh the page. Focus on two types of requests:

• Doc (main document request): Click the first HTML request at the top of the page and check its Waiting (TTFB) under the Timing tab. If this takes too long, it means the origin server is too slow at generating the HTML page.

• Fetch/XHR (API requests): Modern websites heavily use a frontend-backend separation architecture. The main HTML shell might come out in 200ms, but the content is all pulled via APIs (such as /api/products or /api/user). If just one core API takes 2 seconds to execute, the page will keep spinning.

3. Use the curl Command to Precisely Break Down Timing

If you want to precisely quantify the time spent in each network phase versus TTFB, you can run the curl command directly in a Linux/Mac terminal:

curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://www.example.com

If the output is:

DNS:      0.020s
Connect:  0.055s
TLS:      0.095s
TTFB:     1.180s
Total:    1.420s

This provides solid evidence: the network connection (DNS + Connect + TLS) accounts for only about 0.1 seconds, while the server preparing data (TTFB) took 1.085 seconds. At this point, there's no need to waste effort adjusting network configuration or switching DNS providers—you should go straight to the backend logs.

4. Combine with Server-Side Monitoring for Precise Location

Once external speed testing confirms a backend bottleneck, you need to pull server-side monitoring metrics to continue tracking:

• System layer: CPU usage, memory usage, load average, disk I/O.

• Application layer: Whether PHP-FPM process count is maxed out, JVM garbage collection time, Node.js event loop blocking.

• Data layer: MySQL slow query log, Redis cache hit rate, whether the connection pool is overflowing.

If you find TTFB is as high as 1.3 seconds while the database log happens to record a slow SQL query that took 900ms, the problem becomes clear.

4. What's a Normal Response Time for a Dynamic Website?

It's hard to give a fixed standard that applies to all dynamic pages. A simple article page and a backend page that queries orders, inventory, permissions, and recommendation data in real time have completely different processing complexity. A more reasonable approach is to judge by stage.

For dynamic websites, stability matters more than single response time.

For example: average response time is only 300ms, but P95 reaches 2 seconds. This means most users have normal access, but a significant portion of requests are still very slow. From a real user experience perspective, this website still has obvious problems.

So when doing dynamic page performance analysis, it's not advisable to look only at averages. If conditions allow, it's best to observe P50, P95, and P99 at the same time. Especially for high-traffic websites, P95 and P99 are often more likely to expose real performance problems during peak periods.

5. Why Is TTFB Especially High on Dynamic Pages?

In actual troubleshooting, the causes of slow dynamic page responses usually fall into the following 7 areas:

1. Inefficient backend code execution

Complex business logic, large amounts of repeated loop calculations, or blocking code (such as Java interface blocking or Python/Node.js logic freezing synchronously) can cause the program to run for a long time after the request reaches the server before generating the HTML.

2. Database queries dragging down performance

This is the performance killer for the vast majority of dynamic websites. Common scenarios include:

• Query fields without indexes, causing full table scans;

• Complex multi-table JOINs or deep pagination queries;

• Looping database calls (the N+1 query problem);

• Database connection pool full, with requests queuing for connections.

3. External third-party API blocking

Many pages depend on third-party APIs (such as logistics tracking, payment gateways, real-time exchange rates, recommendation systems). If the program is designed to "synchronously wait for the API to return," then any 2-second delay from a third-party API will forcibly slow down your entire page by 2 seconds.

4. Lack of a reasonable caching strategy

If every request has to go through the whole "read the database → run the logic → render the template" cycle again, the server will quickly be overwhelmed. Failing to properly introduce Redis object caching, partial page caching, or FastCGI Cache will put enormous pressure on the origin server.

5. Cookies and login state invalidate the cache

Some sites are extremely fast when you're not logged in, because requests hit the CDN or edge cache directly. But once a user logs in and carries a Session/Cookie, the CDN detects the dynamic cookie and forces the request to bypass the cache and go straight back to the origin, causing origin load to spike.

6. Resource queuing and concurrency bottlenecks during peak hours

"Fast during the day, sluggish during the evening peak" is a classic sign of insufficient concurrency resources. When the CPU is maxed out, all PHP-FPM worker processes are allocated, or the database connection pool is full, incoming requests can only queue up, causing TTFB to skyrocket.

7. Dynamic HTML frequently hits the origin

Even if static assets (images, CSS, JS) are all hosted on a CDN, if the dynamic HTML must always be fetched from the origin in real time and the origin responds slowly, users will still feel that "the page frame takes forever to show up, but the images load pretty fast."

6. How do you tell which layer a dynamic site is actually slow at?

When a site slows down, the following decision tree can quickly narrow down who's responsible:

• Ping latency extremely high, severe packet loss: Check the network route, physical distance, cross-border links, or routing detours first.

• Ping is normal, but TCP/TLS connection takes a long time: Focus on server network configuration, HTTPS handshake time, and server connection limits.

• TCP/TLS is normal, but TTFB is very high: Focus on backend code, slow SQL queries, Redis caching, and origin CPU/memory load.

• HTML responds quickly, but Fetch/XHR APIs are slow: Focus on backend API logic, database performance, or third-party external services.

• All network and API requests are fast, but the page still feels sluggish: The problem isn't in the backend—shift to frontend optimization and check for heavy JavaScript execution, CSS blocking rendering, or uncompressed images.

• Fast when not logged in, noticeably slower after logging in: Check whether cookies are invalidating the CDN cache, and whether permission checks and user data queries are overly complex.

7. Why is a dynamic page slow on first load but fast after a refresh?

Many developers notice during testing that the first visit to a page takes 2 seconds, but a manual refresh brings it down to 200ms. This is because on the second visit, caching mechanisms at multiple layers kick in:

• Local DNS resolution is already done;

• TCP connections are reused;

• The browser has cached static assets;

• The database has written hot data into its buffer;

• The application has completed cold start, and Redis has cached data ready.

 If it's only fast after a refresh, while real new users (with no cache at all) experience extremely slow visits every time, the site's experience is still unacceptable. When testing speed, you must distinguish between "first visit (cold start/no cache)" and "second visit (warm cache)"—don't use the most ideal refresh data to cover up real performance flaws.

8. How should you optimize a slow dynamic website?

Once you've pinpointed the real bottleneck, then formulate a targeted optimization plan. Don't blindly upgrade hardware specs:

• Backend code bottleneck: Refactor time-consuming logic, reduce unnecessary repeated computation, and rewrite unrelated serial tasks as parallel processing.

• Database bottleneck: Optimize slow SQL, add precise indexes for high-frequency query conditions; design tables sensibly, introduce Redis caching for hot data, and reduce direct database read/write frequency.

• External API bottleneck: Set reasonable timeouts for third-party APIs, and for non-critical data, prefer asynchronous loading or background scheduled pre-fetching.

• Concurrency and server bottleneck: Adjust web server connection limits, optimize PHP-FPM / Java thread pool configuration; when resources are insufficient during peak hours, then consider vertical scaling of the origin or adding load balancing for horizontal scaling.

• Caching and CDN strategy: Introduce edge dynamic acceleration or origin page caching (such as Redis/FastCGI Cache) for dynamic content that doesn't change often; separate cookies properly to avoid meaningless static or semi-dynamic requests piercing the cache and hitting the origin directly.

The ultimate goal of dynamic website speed testing is to let data speak. Only by figuring out exactly which stage the time is spent on can you apply your limited optimization effort and hardware budget where they matter most.

Related Q&A

Q: With a CDN enabled on a dynamic page, how do you know whether you're testing the cache or the origin?
A: Look at the X-Cache, Age, and CF-Cache-Status fields in the response headers. To test origin fetch, add a random parameter or clear the cache, then compare TTFB under MISS and HIT states. A low hit rate for dynamic content is normal—focus on the origin link and origin processing time, not just the CDN hit rate.

Q: How do you load-test a dynamic site realistically? Is ab good enough?
A: ab is too simple—it can't handle complex login and POST scenarios. Use k6, JMeter, or Locust to simulate real actions like login, search, and checkout, and focus on P95, P99, and error rates. Don't test during production peak hours, and start with read-only APIs, or your load test will take down your own site.

Q: How do you tell whether a slow dynamic page is a database problem or a code problem?
A: Enable the slow query log and check the proportion of SQL execution time; then use APM or code instrumentation to measure application-layer time. If SQL is fast but the API is slow, it could be loop calls, external APIs, or serialization. N+1 queries are especially common—a list page can trigger hundreds of queries.

Q: How do you speed-test an SPA? How is it different from a traditional dynamic page?
A: An SPA's first-screen HTML is fast, but route transitions, API waterfalls, and JS execution determine the experience. Use the Performance panel to spot long tasks, Lighthouse to check LCP, and RUM to measure real route transition times. Don't just test the homepage—the moment a user clicks into a detail page is where the truth shows.

Q: How do you establish a performance baseline for a dynamic site so you can compare after releases?
A: Pick a few core pages and APIs, fix the test environment, concurrency, and data volume, and record P50, P95, TTFB, and API latency. Run it after every release, and investigate if the difference exceeds a threshold. Don't rely on gut feelings like "it seems slower"—data beats memory.

Q: What should you watch out for when speed-testing parameterized dynamic pages like search and list pages?
A: Use real search terms, not just empty parameters. Pay attention to pagination, sorting, and filter combinations—these change the SQL. It's best to fix a few typical queries as a baseline and observe response times under different result counts. When it's slow with many results, it's usually a pagination or indexing issue.