Layered Troubleshooting for Slow Websites: Locating Issues Across Network, Frontend, Backend, and Database

“Slow website” is a vague description that can correspond to four completely different causes. Optimizing without layering often results in no effect—because you aren’t addressing the bottleneck layer.

The good news is: a single curl command can pinpoint which layer is at fault.

One Command to Locate the Issue

curl -o /dev/null -s -w 
 'DNS Lookup: %{time_namelookup}snConnection Established: %{time_connect}snTLS Handshake: %{time_appconnect}snTime To First Byte (TTFB): %{time_starttransfer}snTotal Time: %{time_total}sn' 
 https://example.com/

The two most critical values:

• High TTFB (Time To First Byte) → The issue lies with the server side (application or database)
• Normal TTFB but high total time → The issue lies with the frontend (resources are too large or there are too many requests)

This distinction alone cuts the troubleshooting scope in half.

Layer 1: Network

# DNS lookup time
dig example.com | grep 'Query time'

# Link quality
ping -c 5 example.com
mtr example.com --report

# TLS handshake
openssl s_client -connect example.com:443 -servername example.com </dev/null

Layer 2: Frontend

# Check total page size and request count
curl -s https://example.com/ | wc -c

# List all resources and their sizes
curl -s https://example.com/ | grep -oE '(src|href)="[^"]+.(js|css|png|jpg|webp)"'

# Check if compression is enabled
curl -I -H 'Accept-Encoding: gzip, br' https://example.com/ | grep -i 'content-encoding'

# Check cache headers
curl -I https://example.com/wp-content/themes/x/style.css | grep -i 'cache-control|expires'

Common causes at the frontend layer: uncompressed images, unmerged resources, missing cache headers, and disabled compression. None of these require backend changes.

# Enable gzip
gzip on;
gzip_types text/css application/javascript image/svg+xml;

# Static resource caching
location ~* .(js|css|png|jpg|jpeg|gif|webp|ico)$ {
    expires 30d;
    add_header Cache-Control "public";
}

Layer 3: Backend (Application)

# ① Check PHP slow logs (if enabled)
tail -50 /var/log/php-fpm/www-slow.log

# ② Check if processes are maxed out
ps aux | grep -c '[p]hp-fpm'
top

# ③ Check for blocked external requests (calling third-party APIs without timeout settings)
grep -iE 'curl|file_get_contents' /var/www/html/ -r --include='*.php' | head

Lack of timeout settings for external interfaces is a classic cause of backend slowdowns: if a third-party service is slow, your page slows down accordingly, and it continues to occupy php-fpm processes, cascading impact across the entire site.

Layer 4: Database

# ① Enable slow query log and view it
mysql -e "SHOW VARIABLES LIKE 'slow_query_log%';"
mysql -e "SHOW VARIABLES LIKE 'long_query_time';"

# ② View currently executing statements
mysqladmin processlist
mysql -e "SELECT * FROM information_schema.processlist
          WHERE command != 'Sleep' ORDER BY time DESC LIMIT 10G"

# ③ Analyze slow logs
mysqldumpslow -s t -t 10 /var/log/mysql/slow.log

# ④ Use EXPLAIN to check if indexes are being used
mysql -e "EXPLAIN SELECT * FROM wp_posts WHERE post_status='publish' ORDER BY post_date DESC LIMIT 10G"

Decision Tree

Website is slow
├─ curl segmented timing
│  ├─ time_namelookup high     → DNS layer
│  ├─ time_connect high        → Network link
│  ├─ time_appconnect high     → TLS handshake
│  ├─ TTFB high                → Server side
│  │  ├─ php-fpm processes maxed out → Add processes or optimize slow scripts
│  │  ├─ External requests present   → Check timeout settings
│  │  └─ Slow database               → Slow queries/indexes
│  └─ TTFB normal + Total time high → Frontend
│     ├─ Resources too large         → Compress images, enable gzip
│     ├─ Too many requests           → Merge resources
│     └─ No cache headers            → Configure Cache-Control
└─ Only specific pages are slow
   └─ Queries or logic issues on that page → Troubleshoot specifically for that page

Scenario Walkthrough: Server is Idle, but Pages Take Seconds to Load

Symptom: A site loads extremely slowly, but the server’s CPU, memory, and disk usage are all low, offering no obvious clues. Everyone has different opinions: some blame the network, others blame the frontend.

1. Don’t argue; measure where the time is spent first → Use request timing to separate domain resolution, connection establishment, first byte, and content transfer into four segments. This measurement directly ends the argument.
2. Analyze the first byte time to draw conclusions → If the first byte takes up the majority of the time, it means time is spent generating content on the server side; network and frontend can be ruled out initially.
3. Drill down further: Is execution slow or is the query slow? → Open the slow query log and find that several statements scan large amounts of data each time.
4. Confirm the bottleneck → Relevant tables lack usable indexes, and this issue is amplified as data volume grows.
5. Add indexes and re-test the same request → First byte time drops significantly, verifying the attribution was correct.
6. Handle the remaining segment last → Transfer time is related to resource volume; this is what frontend optimization needs to address.

# Four-segment timing: Slow first byte = Server-side issue; Slow transfer = Resource volume issue
curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} ttfb=%{time_starttransfer} transfer=%{time_total}n' https://example.com/

# Slow queries: First confirm if logging is enabled
mysql -e "SHOW VARIABLES LIKE 'slow_query_log%'; SHOW VARIABLES LIKE 'long_query_time';"

# Find the most time-consuming statements
mysqldumpslow -s t -t 10 /path/to/slow/log 2>/dev/null

# View the execution plan for a specific statement (check for full table scans)
mysql -e "EXPLAIN SELECT ... G"

Root Cause: Missing indexes caused queries to slow down as data volume grew, consuming all time during the server-side generation phase. Resource metrics were completely normal because the bottleneck wasn’t CPU or memory.

Two key takeaways to remember:

• The first step in troubleshooting “slowness” is segmented timing, not checking resource usage. It is very common for resources to be normal while responses are slow. You must determine which segment the time falls into before deciding which direction to investigate.
• For slow first bytes, check the backend and database; for slow transfers, check resource volume. The optimization methods for these two are completely different; mixing them up often leads to wasted effort.

8 Common Pitfalls

1. Optimizing without layering: Changing things that aren’t bottlenecks wastes effort.
2. Only looking at total time: Without seeing TTFB, you cannot distinguish between frontend and backend issues.
3. Tweaking server parameters for frontend slowness: Wrong direction.
4. Ignores external interfaces: Third-party slowness can cripple the entire site.
5. Ignoring slow query logs: Guessing when modifying indexes.
6. Concluding after only one test: Should test multiple times to rule out sporadic issues.
7. No comparison before and after optimization: Cannot confirm if changes were effective.
8. Caching masks problems: Clear cache before testing to see true performance.

Real Customer Feedback (From Cloud Market Reviews and Inquiries for Similar Products)

The following excerpts are taken from real buyer reviews and inquiries for similar operations and maintenance services on Alibaba Cloud / Tencent Cloud / Huawei Cloud Cloud Markets (service providers include our store and peers, provided here for reference only, not fictional tickets from our site):

d****9 Rating: 5.0 stars 2023-02-15 09:11 Yong****ying Rating: 5.0 stars 2021-03-29 11:04

1****4 Rating: 5.0 stars 2023-05-08 11:53 1****3 Rating: 5.0 stars 2022-09-22 22:01 r****u Rating: 5.0 stars 2020-07-07 15:05

b****4 Rating: 5.0 stars 2025-06-23 16:57 b****4 Rating: 5.0 stars 2025-06-23 16:56 Jian****wei Rating: 5.0 stars 2021-01-20 15:03 Technical skills are awesome, speed is fast! It turned out to be a Trojan causing Baidu global hijacking!!!!!! f****u Rating: 5.0 stars 2021-01-02 20:43 Thanks for assisting in maintaining Yuncai’s normal operation. 1****1 Rating: 5.0 stars 2020-11-20 10:03 Consistently good service as always. 1****1 Rating: 5.0 stars 2020-11-17 09:13 Thank you for the consistently good service. 1****1 Rating: 5.0 stars 2020-09-25 15:42 Many thanks. 1****1 Rating: 5.0 stars 2020-08-24 15:34 Many thanks to your company’s technical staff. 1****1 Rating: 5.0 stars 2020-07-24 09:49 Many thanks!