Checklist xử lý website chậm

Website chậm không phải lúc nào cũng xuất phát từ một nguyên nhân duy nhất. Có trường hợp CPU vẫn thấp nhưng database phản hồi chậm, có trường hợp server đủ mạnh nhưng hình ảnh quá nặng, hoặc website chỉ chậm vào giờ cao điểm vì số request đồng thời tăng mạnh. Nếu xử lý theo cảm tính, đội ngũ rất dễ rơi vào tình trạng tăng CPU, RAM hoặc đổi hosting nhưng tốc độ vẫn không được cải thiện đáng kể.

Cách xử lý hiệu quả hơn là kiểm tra theo từng lớp: trình duyệt, mạng, CDN, web server, application, database, CPU, RAM, Disk I/O và các dịch vụ bên ngoài. Mỗi lớp cần có chỉ số và cách xác minh riêng trước khi đưa ra quyết định tối ưu.

Bài viết này cung cấp một checklist thực tế để khoanh vùng nguyên nhân website chậm, từ bước xác định triệu chứng đến cách kiểm tra từng thành phần và cách xác nhận hệ thống đã được cải thiện sau khi tối ưu.

Nguyên tắc quan trọng: Không nâng cấu hình máy chủ chỉ vì website chậm. Hãy xác định bottleneck trước, sau đó mới quyết định tối ưu code, database, cache, CDN hay tài nguyên Cloud Server.

Xác định website chậm ở đâu trước khi xử lý

Trước tiên cần trả lời câu hỏi: website chậm ở giai đoạn nào?

Một trang web có thể chậm vì:

• DNS phản hồi lâu.
• Kết nối tới server có độ trễ cao.
• TTFB cao.
• HTML trả về chậm.
• Hình ảnh tải lâu.
• CSS hoặc JavaScript chặn hiển thị.
• API phản hồi chậm.
• Database query lâu.
• CPU hoặc RAM quá tải.
• Disk I/O cao.
• Dịch vụ bên ngoài phản hồi chậm.

Có thể hình dung luồng xử lý như sau:

Người dùng
   |
   v
DNS
   |
   v
CDN / Load Balancer
   |
   v
Web Server
   |
   v
Application
   |
   v
Database / Cache / External API

Nếu chưa biết lớp nào đang chậm, mọi hành động tiếp theo chỉ là phỏng đoán.

Kiểm tra bằng trình duyệt trước

Mở Developer Tools:

F12 -> Network

Reload trang và theo dõi:

• TTFB.
• Tổng thời gian tải.
• Số lượng request.
• Dung lượng trang.
• Request nào chậm nhất.
• File nào có kích thước lớn.
• API nào phản hồi chậm.
• Có request bị lỗi 4xx hoặc 5xx không.

Nếu HTML đầu tiên mất nhiều thời gian, vấn đề có thể nằm ở backend. Nếu HTML nhanh nhưng ảnh, CSS hoặc JavaScript tải chậm, nên kiểm tra frontend, CDN hoặc băng thông. Nếu chỉ một API chậm, cần khoanh vùng vào endpoint đó thay vì kiểm tra toàn bộ website.

Kiểm tra TTFB

TTFB, hay Time to First Byte, là thời gian từ lúc trình duyệt gửi request đến khi nhận byte dữ liệu đầu tiên.

TTFB cao có thể liên quan đến:

• Network latency.
• Web server.
• PHP, Node.js hoặc Java.
• Database.
• Cache miss.
• API bên ngoài.
• CPU quá tải.
• Worker bị thiếu.

Có thể kiểm tra nhanh bằng:

curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}\nTotal: %{time_total}\n' https://example.com

Nếu TTFB cao nhưng static asset tải nhanh, cần tập trung vào origin và backend. Nếu TTFB thấp nhưng trang vẫn hiển thị chậm, frontend có thể là vấn đề chính.

Kiểm tra DNS và network latency

DNS chậm hoặc network latency cao cũng có thể làm website phản hồi chậm dù server còn nhiều tài nguyên.

Kiểm tra DNS:

dig example.com

Kiểm tra kết nối:

ping example.com

Kiểm tra đường đi mạng:

traceroute example.com

Trên Windows có thể dùng:

tracert example.com

Cần chú ý DNS lookup time, packet loss, latency và routing bất thường. Nếu người dùng phân tán nhiều khu vực, CDN có thể giúp giảm thời gian phân phối tài nguyên tĩnh.

Kiểm tra số lượng và kích thước request

Một website có thể chậm đơn giản vì tải quá nhiều tài nguyên.

Ví dụ một trang có:

• 80 hình ảnh.
• 20 JavaScript.
• 15 CSS.
• 6 font.
• Nhiều tracking script.

Tổng số request có thể lên tới hàng trăm.

Trong DevTools, kiểm tra các chỉ số Requests, Transferred, Resources, Finish, DOMContentLoaded và Load.

Nếu trang có quá nhiều request, có thể:

• Loại bỏ file không cần thiết.
• Lazy load hình ảnh.
• Giảm plugin frontend dư thừa.
• Chỉ tải script khi thực sự cần.
• Bật cache.
• Phân phối static asset qua CDN nếu phù hợp.

Kiểm tra hình ảnh

Hình ảnh thường là thành phần chiếm dung lượng lớn nhất trên website.

Cần kiểm tra:

• Kích thước file.
• Kích thước ảnh so với vùng hiển thị.
• Định dạng.
• Lazy loading.
• Compression.
• CDN.

Ví dụ ảnh hiển thị ở 800x600 nhưng file gốc là 4000x3000 sẽ tạo tải không cần thiết.

Nên ưu tiên WebP hoặc AVIF khi phù hợp, resize ảnh đúng kích thước, nén ảnh, lazy load ảnh ngoài màn hình và cache ảnh đủ lâu. CDN không thể bù hoàn toàn cho một website sử dụng ảnh quá lớn.

Kiểm tra CSS và JavaScript

JavaScript nặng có thể làm website chậm ngay cả khi server phản hồi nhanh.

Cần kiểm tra:

• File JavaScript lớn.
• Script bên thứ ba.
• Tracking.
• Chat widget.
• Heatmap.
• Ads.
• Plugin frontend.
• Render-blocking resource.

Các script này có thể làm main thread bận và khiến người dùng cảm thấy trang phản hồi chậm.

Có thể kiểm tra trong:

Performance
Coverage
Network

Các hướng tối ưu thường gồm defer JavaScript không quan trọng, async script phù hợp, loại bỏ code không dùng, giảm plugin và chỉ tải script trên trang thực sự cần.

Kiểm tra CDN và cache

Nếu website đã sử dụng CDN, cần xác nhận CDN thực sự đang cache.

Kiểm tra header:

curl -I https://example.com/image.webp

Tùy nhà cung cấp, có thể thấy trạng thái:

HIT
MISS
BYPASS
EXPIRED

Nếu hầu hết request luôn MISS, CDN có thể không giảm tải origin như mong đợi.

Cần kiểm tra Cache-Control, TTL, query string, cookie, purge cache và cache rule.

Ngoài CDN, cần kiểm tra page cache và object cache nếu website sử dụng WordPress hoặc application có cache backend.

Kiểm tra CPU trên server

Nếu frontend không phải nguyên nhân, chuyển sang server.

Kiểm tra CPU:

top

Hoặc:

htop

Theo dõi CPU usage, Load Average, process dùng nhiều CPU và thời điểm CPU tăng.

Có thể xem process tiêu thụ CPU nhiều nhất bằng:

ps aux --sort=-%cpu | head

Nếu CPU chỉ cao trong giờ peak, cần đối chiếu với traffic. Nếu CPU cao liên tục, cần xác định process gây tải.

Không nên kết luận phải tăng CPU chỉ từ một ảnh chụp tại một thời điểm. Nên theo dõi theo thời gian.

Kiểm tra RAM và swap

Kiểm tra RAM:

free -m

Xem process dùng nhiều RAM:

ps aux --sort=-%mem | head

Kiểm tra swap:

swapon --show

Dấu hiệu cần chú ý:

• Available memory xuống thấp.
• Swap tăng liên tục.
• Process bị OOM Kill.
• Container restart.
• Database bị kill.
• Website chậm khi RAM gần đầy.

Kiểm tra OOM:

dmesg | grep -i -E 'oom|killed process'

Nếu ứng dụng dùng nhiều worker, cần tính RAM theo tổng số worker chứ không chỉ nhìn một process riêng lẻ.

Kiểm tra Disk I/O

CPU thấp không có nghĩa server không bị nghẽn.

Nếu ứng dụng phải chờ ổ đĩa, response time vẫn có thể cao.

Kiểm tra:

iostat -xz 1

Theo dõi I/O wait, latency, utilization và throughput.

Kiểm tra dung lượng:

df -h

Kiểm tra inode:

df -i

Các nguyên nhân thường gặp gồm database ghi nhiều, backup chạy giờ cao điểm, log tăng quá nhanh, disk gần đầy, swap hoặc container log không rotation.

Kiểm tra web server

Với Nginx:

sudo nginx -t
sudo systemctl status nginx

Xem error log:

sudo tail -f /var/log/nginx/error.log

Với Apache:

sudo systemctl status apache2

Web server có thể chậm vì worker limit, connection limit, keepalive cấu hình chưa phù hợp, reverse proxy timeout hoặc log quá nhiều.

Nếu website có nhiều connection đồng thời, có thể kiểm tra:

ss -s

Kiểm tra PHP-FPM hoặc application worker

Với PHP, một nguyên nhân phổ biến là hết PHP-FPM worker.

Khi toàn bộ worker đang bận, request mới phải chờ.

Cần kiểm tra:

• pm.max_children.
• Số process.
• RAM mỗi worker.
• Slow log.
• Request timeout.

Ví dụ:

ps aux | grep php-fpm

Không nên tăng pm.max_children quá cao khi RAM không đủ.

Với Node.js, Java hoặc Python cũng cần kiểm tra worker, thread, event loop, garbage collection, connection pool và process restart.

Kiểm tra database

Database là một trong những bottleneck phổ biến nhất.

Các dấu hiệu:

• TTFB cao.
• CPU application thấp.
• Request liên quan dữ liệu chậm.
• Database connection tăng.
• Query timeout.
• Lock hoặc deadlock.

Với MySQL có thể kiểm tra:

SHOW PROCESSLIST;

Nếu có slow query log, cần tìm những query tiêu tốn nhiều thời gian.

Các lỗi thường gặp:

• Thiếu index.
• Query quét toàn bảng.
• N+1 query.
• JOIN nặng.
• Query báo cáo trên production.
• Quá nhiều connection.
• Transaction kéo dài.

Không nên tăng CPU cho application nếu bottleneck thực tế nằm ở query.

Kiểm tra Redis hoặc cache backend

Nếu hệ thống sử dụng Redis, cần kiểm tra memory, eviction, hit ratio, connection và latency.

Ví dụ:

redis-cli INFO memory
redis-cli INFO stats

Cache hoạt động kém có thể khiến lượng request xuống database tăng mạnh.

Một tình huống đáng chú ý là cache hết hạn hàng loạt cùng lúc, gây cache stampede và làm database quá tải.

Kiểm tra API bên ngoài

Website có thể chậm vì phụ thuộc dịch vụ bên ngoài như:

• Payment gateway.
• CRM.
• Shipping.
• Email.
• SMS.
• AI API.
• Maps.
• Analytics.

Nếu application gọi đồng bộ tới một dịch vụ chậm, toàn bộ request có thể phải chờ.

Cần kiểm tra timeout, retry, response time, circuit breaker và fallback. Các tác vụ không cần phản hồi ngay nên cân nhắc chuyển sang background job.

Kiểm tra traffic tăng bất thường

Website chỉ chậm vào một số thời điểm có thể liên quan đến traffic.

Cần đối chiếu:

Traffic
CPU
RAM
RPS
Database connection
Response time
Error rate

Nếu tất cả tăng cùng lúc vào giờ peak, hệ thống có thể đang đạt giới hạn capacity.

Trong trường hợp này cần cân nhắc load test, cache, CDN, scale up, scale out, rate limiting hoặc queue.

Kiểm tra bot và request bất thường

Một số website chậm vì lượng request từ bot hoặc crawler tăng đột biến.

Kiểm tra access log:

sudo tail -n 1000 /var/log/nginx/access.log

Thống kê IP gửi nhiều request:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

Cần xem IP, User-Agent, URL, tần suất và response code.

Nếu có request bất thường, có thể cân nhắc rate limiting, WAF, bot management hoặc firewall.

Kiểm tra log lỗi

Log thường cho biết nhiều thông tin mà dashboard không thể hiện.

Nên kiểm tra Nginx error log, application log, PHP log, database log, container log và system log.

Ví dụ:

journalctl -p err --since "1 hour ago"

Tìm các lỗi như timeout, connection refused, too many connections, OOM, 502, 504, database unavailable hoặc disk full.

Nếu lỗi xuất hiện cùng thời điểm website chậm, đây là manh mối quan trọng.

Kiểm tra lỗi 502 và 504

Lỗi 502 thường liên quan tới upstream không phản hồi đúng. Lỗi 504 thường xuất hiện khi upstream mất quá nhiều thời gian để trả kết quả.

Luồng cần kiểm tra:

Nginx
   |
   v
PHP-FPM / Application
   |
   v
Database / External API

Nguyên nhân có thể nằm ở worker hết, application crash, query chậm, external API timeout hoặc container restart.

Không nên chỉ tăng timeout vì điều đó có thể che giấu bottleneck thay vì xử lý nguyên nhân.

Kiểm tra Cronjob và background job

Một website chỉ chậm đúng một số giờ có thể liên quan đến cronjob.

Ví dụ:

• Backup.
• Đồng bộ dữ liệu.
• Import sản phẩm.
• Generate report.
• Gửi email.
• Reindex.
• Log rotate.

Kiểm tra cron:

crontab -l

Kiểm tra system cron:

ls -la /etc/cron.d/

Nếu backup hoặc job nặng chạy cùng giờ peak, có thể chuyển sang khung thời gian tải thấp hơn.

Kiểm tra container nếu chạy Docker

Kiểm tra:

docker stats

Xem container restart:

docker ps -a

Xem log:

docker logs --tail 200 container_name

Cần chú ý CPU limit, memory limit, restart count, disk log, network và volume.

Có trường hợp Cloud Server còn nhiều RAM nhưng container bị giới hạn memory quá thấp nên vẫn restart.

Checklist xử lý website chậm theo thứ tự

Frontend

• Kiểm tra tổng số request.
• Kiểm tra dung lượng trang.
• Kiểm tra ảnh quá lớn.
• Kiểm tra JavaScript.
• Kiểm tra CSS.
• Kiểm tra font.
• Kiểm tra third-party script.
• Kiểm tra Core Web Vitals nếu cần.

Network và CDN

• Kiểm tra DNS.
• Kiểm tra latency.
• Kiểm tra CDN cache HIT.
• Kiểm tra băng thông.
• Kiểm tra static asset.
• Kiểm tra SSL.

Server

• Kiểm tra CPU.
• Kiểm tra RAM.
• Kiểm tra swap.
• Kiểm tra Disk I/O.
• Kiểm tra disk space.
• Kiểm tra inode.
• Kiểm tra network connection.

Application

• Kiểm tra worker.
• Kiểm tra timeout.
• Kiểm tra log.
• Kiểm tra API.
• Kiểm tra background job.
• Kiểm tra queue.
• Kiểm tra cache.

Database

• Kiểm tra slow query.
• Kiểm tra index.
• Kiểm tra connection.
• Kiểm tra lock.
• Kiểm tra transaction.
• Kiểm tra Disk I/O database.

Sau khi tối ưu phải đo lại

Không nên kết thúc quy trình ngay sau khi thay đổi cấu hình.

Cần so sánh trước và sau:

Chỉ số	Trước	Sau
TTFB	Ghi baseline	Đo lại
P95 response time	Ghi baseline	Đo lại
Error rate	Ghi baseline	Đo lại
CPU peak	Ghi baseline	Đo lại
RAM	Ghi baseline	Đo lại
Disk I/O	Ghi baseline	Đo lại
Cache hit	Ghi baseline	Đo lại
RPS xử lý được	Ghi baseline	Đo lại

Nếu response time không cải thiện, thay đổi vừa thực hiện có thể không nằm đúng bottleneck.

Quy trình nên là:

Đo
 |
 v
Xác định bottleneck
 |
 v
Thay đổi một nhóm yếu tố
 |
 v
Đo lại
 |
 v
So sánh

Không nên thay đổi quá nhiều thứ cùng lúc vì sẽ khó biết yếu tố nào thực sự tạo ra cải thiện.

Khi nào nên nâng Cloud Server?

Có thể cân nhắc tăng tài nguyên khi đã xác định:

• CPU thường xuyên cao.
• RAM không đủ.
• Application cần thêm worker.
• Disk I/O đạt giới hạn.
• Network đạt giới hạn.
• Traffic tăng thật và có tính ổn định.

Nếu website chậm do query database, hình ảnh hoặc JavaScript, nâng CPU chưa chắc tạo ra khác biệt.

Nếu hệ thống đã được tối ưu nhưng một server không còn đủ khả năng xử lý, có thể cân nhắc scale up hoặc chuyển sang kiến trúc nhiều application server sau Load Balancer.

Kết luận

Website chậm là một triệu chứng, không phải nguyên nhân. Vì vậy, cách xử lý hiệu quả không phải bắt đầu bằng việc tăng CPU, RAM hoặc chuyển nhà cung cấp hosting mà là khoanh vùng bottleneck theo từng lớp của hệ thống.

Một checklist thực tế nên đi theo thứ tự:

Frontend
->
Network/CDN
->
Web Server
->
Application
->
Database/Cache
->
CPU/RAM/Disk

Nếu HTML phản hồi chậm, tập trung vào backend. Nếu backend nhanh nhưng tài nguyên tải lâu, kiểm tra frontend, CDN và băng thông. Nếu website chỉ chậm vào giờ cao điểm, đối chiếu traffic với CPU, RAM, database connection và response time.

Sau mỗi thay đổi, cần đo lại bằng cùng một bộ chỉ số. Đây là cách tránh tối ưu theo cảm tính và giúp xác định chính xác giải pháp nào thực sự cải thiện hiệu năng.