WordPress chậm: chẩn đoán 5 tầng từ ổ đĩa lên plugin

Trả lời nhanh: WordPress chậm có 5 tầng nghi phạm, chẩn từ dưới lên: (1) nền máy chủ, TTFB trang tĩnh cao là bệnh hạ tầng (ổ, CPU, vị trí); (2) PHP, phiên bản cũ và thiếu OPcache ăn 30-50% tốc độ; (3) database, bảng wp_options phình, wp_postmeta không index; (4) cache, chưa có page cache là mỗi lượt xem dựng lại từ đầu; (5) plugin/theme, vài plugin nặng gánh 80% thời gian. Sai lầm phổ biến nhất: nhảy thẳng đến tầng 5 cài 'plugin tăng tốc' chồng chất, trong khi bệnh nằm tầng 1-3.

"Web WordPress của em chậm lắm" là câu mở đầu của cả nghìn cuộc tư vấn, và 90% lời khuyên nhận được là 'cài plugin cache X đi'. Đúng một phần năm. Bài này đưa quy trình chẩn 5 tầng có công cụ đo từng tầng, để bạn xử đúng bệnh trong một buổi thay vì cài-gỡ plugin cả tháng.

Tầng 1: Nền máy chủ - phép thử file tĩnh 60 giây

# TTFB mot file tinh (vd anh logo), do THUAN ha tang, khong dinh PHP/DB:
curl -o /dev/null -s -w "tinh: %{time_starttransfer}sn" https://site.vn/wp-content/uploads/logo.png
# TTFB trang chu (dong):
curl -o /dev/null -s -w "dong: %{time_starttransfer}sn" https://site.vn/

Đọc: file tĩnh đã >300ms từ mạng VN → bệnh tầng 1, hosting yếu/ổ chậm/đặt xa (bộ bài TTFB, VPS-Việt-Nam, fio là phác đồ); tĩnh nhanh mà động chậm → bệnh nằm tầng 2-5, đi tiếp. Phép thử 60 giây này tiết kiệm hàng tuần đổ lỗi nhầm chỗ.

Tầng 2: PHP - hai nút vặn ăn tiền nhất

Phiên bản: PHP 8.x nhanh hơn 7.x ~30-60% trên WordPress thật, kiểm tra trong Site Health, nâng qua panel hosting (test kỹ plugin cũ trước). OPcache: cache mã PHP đã biên dịch, thiếu nó mỗi request biên dịch lại cả đống file (và đọc lại từ ổ, lại chuyện vạn-file). Kiểm: Site Health hoặc php -i | grep opcache.enable. Hai nút này miễn phí và thường bị bỏ quên ở hosting tự quản, riêng chúng đã đổi hạng nhiều site.

Tầng 3: Database - hai bảng tai tiếng

wp_options autoload: mọi trang tải toàn bộ option có autoload=yes, plugin cũ để rác hàng MB ở đây là mỗi lượt xem cõng thêm. Đo: SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes';: trên 1-2 MB là đáng dọn. wp_postmeta: site lớn + query lọc theo meta không index = full scan kinh điển (bài index database áp thẳng vào đây). Cả hai hiện nguyên hình trong slow query log, bật theo bài MySQL chậm, đừng đoán.

Tầng 4-5: Cache và plugin - xử có thứ tự

Tầng 4, page cache: trên hosting LiteSpeed (phổ biến ở VN), LiteSpeed Cache là lựa chọn số một, cache ăn ở tầng server, TTFB trang cache về 30-80ms. Đo lại bằng phép thử tầng 1 sau khi bật: trang động phải tiệm cận trang tĩnh. Tầng 5, plugin/theme: cài Query Monitor (X-quang: query chậm theo từng plugin, hook ngốn thời gian), mở trang chậm nhất, đọc bảng, thủ phạm thường là 2-3 cái tên quen: builder nặng, related-posts quét bảng, security scan mỗi request. Nguyên tắc xử: thay/gỡ đích danh theo số liệu, không gỡ mù; đo xong gỡ Query Monitor (chính nó cũng có giá). Và nghi thức cuối: mỗi quý kiểm kê plugin một lần, mỗi cái tự hỏi 'có ra tiền không?', trang trại 40 plugin hiếm khi vô tội.

Phép thử 60 giây: tách nền máy chủ khỏi phần mềm

# 1. Tao mot file tinh nho, do thoi gian may chu tra ve
echo "test" > /var/www/html/thu.txt
curl -o /dev/null -s -w "byte dau %{time_starttransfer}s | tong %{time_total}s\n" \
  https://trangcuaban.vn/thu.txt

# 2. Do trang chu
curl -o /dev/null -s -w "byte dau %{time_starttransfer}s\n" https://trangcuaban.vn/

# Cach doc:
#   file tinh cham (tren 0,3s) -> van de o nen may chu hoac mang, khong phai WordPress
#   file tinh nhanh, trang chu cham -> van de o PHP, co so du lieu hoac plugin

Bước này tiết kiệm nhiều thời gian nhất: nó tách hẳn hai nhóm nguyên nhân. Rất nhiều người bỏ cả ngày tắt từng plugin trong khi vấn đề nằm ở máy chủ đặt quá xa khách hàng.

Hai bảng tai tiếng trong cơ sở dữ liệu

# Kiem kich thuoc cac bang, hai bang duoi thuong lon bat thuong
mysql -e "SELECT table_name, ROUND(data_length/1024/1024,1) AS mb,
  ROUND(index_length/1024/1024,1) AS mb_index, table_rows
  FROM information_schema.tables WHERE table_schema='TEN_CSDL'
  ORDER BY data_length DESC LIMIT 10;"

# Bang tuy chon: dem so ban ghi tu tai moi lan tai trang
mysql -e "SELECT COUNT(*) FROM wp_options WHERE autoload='yes';"
mysql -e "SELECT ROUND(SUM(LENGTH(option_value))/1024/1024,2) AS mb_autoload
  FROM wp_options WHERE autoload='yes';"

# Bang meta cua bai viet: rac tu plugin da go
mysql -e "SELECT meta_key, COUNT(*) c FROM wp_postmeta
  GROUP BY meta_key ORDER BY c DESC LIMIT 15;"

Thứ tự xử đúng

1. Nền máy chủ trước: vị trí máy chủ, tốc độ ổ đĩa, steal time. Không sửa được ở đây thì mọi thứ sau chỉ vá tạm.
2. Bộ nhớ đệm mã PHP và giới hạn bộ nhớ cho PHP. Hai nút này cho hiệu quả lớn nhất với công sức nhỏ nhất.
3. Dọn cơ sở dữ liệu theo hai bảng ở trên.
4. Bật bộ nhớ đệm trang.
5. Cuối cùng mới tắt từng plugin để tìm thủ phạm. Đây là bước tốn thời gian nhất, để sau cùng.

Chi tiết về ảnh hưởng của tốc độ ổ đĩa nằm ở VPS NVMe.

Câu hỏi thường gặp

Cài nhiều plugin cache chồng nhau có nhanh hơn không?

Ngược lại, hai page cache giẫm nhau gây lỗi purge, trang cũ dai dẳng khó dò. Một page cache đúng hệ (LiteSpeed Cache trên máy LiteSpeed) + một object cache (Redis) khi cần là đội hình đủ.

Ảnh có phải thủ phạm làm WordPress chậm không?

Ảnh nặng làm trang tải lâu phía trình duyệt (LCP) nhưng ít ảnh hưởng TTFB, hai bệnh khác nhau. Chẩn 5 tầng của bài xử phần máy chủ; ảnh WebP + lazy-load phần dưới màn hình là bài Core-Web-Vitals nối tiếp.

Bao nhiêu plugin là 'quá nhiều'?

Không có con số thiêng, 15 plugin nhẹ tốt hơn 3 plugin quái vật. Thước đo đúng là Query Monitor: tổng thời gian plugin dưới ~200ms là lành mạnh; một plugin đơn lẻ trên 100ms là đối tượng thẩm vấn.

Làm hết 5 tầng rồi vẫn chậm thì sao?

Hiếm, nhưng khi đó nhìn hai hướng: traffic đã vượt cỡ máy (nâng gói, tách database) hoặc code custom/theme độc bản cần dev soi. Lúc này bạn đã có đủ số liệu 5 tầng để nói chuyện với dev bằng bằng chứng, giá trị lớn nhất của quy trình.

Bài viết liên quan

• TTFB là gì? Vì sao cao và cách giảm
• MySQL chậm: đọc EXPLAIN và tìm nghẽn
• VPS ổ Enterprise U.2 NVMe RAID 10 tại TND