WordPress chậm: đo trước khi cài thêm plugin tăng tốc, và năm thủ phạm hay gặp

Phần lớn site WordPress chậm vì máy chủ mất quá lâu để dựng trang (TTFB cao), không phải vì ảnh hay CSS. Đo TTFB trước; nếu cao thì tìm nguyên nhân phía máy chủ: không có bộ đệm trang, plugin truy vấn nặng, wp-cron, bot dò mật khẩu. Cài thêm plugin “tăng tốc” mà không đo thường chỉ thêm một plugin nữa.

Ban biên tập SEO Gốc · 09/11/2026 · 6 phút đọc

Thợ máy nối ống chẩn đoán vào động cơ xe tay ga cũ trước khi đụng vào thứ gì khác trong xưởng sạch sẽ

“Site WordPress chậm quá, cài plugin tăng tốc nào?” Câu hỏi quen thuộc, và câu trả lời thường là: chưa cần cài gì, đo trước đã. Trang chậm có thể vì máy chủ mất 3 giây mới trả byte đầu tiên, vì ảnh 5 MB, vì một plugin chạy 200 truy vấn cơ sở dữ liệu, hay vì hàng xóm trên hosting dùng chung đang ăn hết CPU. Mỗi nguyên nhân có cách sửa khác hẳn. Plugin tối ưu ảnh không cứu được máy chủ quá tải; bộ đệm trang không cứu được ảnh 5 MB.

Bước 1: đo TTFB

TTFB (thời gian tới byte đầu tiên) là thời gian máy chủ cần để bắt đầu trả trang. Với WordPress, đây là chỉ số nói nhiều nhất về phía máy chủ:

curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s  Tổng: %{time_total}s\n" \
  -H "Accept-Encoding: gzip" https://tenmien.vn/

TTFB	Đánh giá	Hướng tìm
Dưới 0,3 giây	Tốt; có thể đã có bộ đệm trang	Chậm nếu có thì ở phía trình duyệt: ảnh, JS, CSS
0,3–0,8 giây	Chấp nhận được, cải thiện được	Bộ đệm trang, phiên bản PHP
Trên 0,8 giây	Chậm phía máy chủ	Bộ đệm, plugin nặng, cơ sở dữ liệu, hosting
Trên 2 giây, dao động mạnh	Máy chủ quá tải hoặc bị bot đánh	Nhật ký truy cập, tải CPU, hàng xóm trên hosting

Đo vài lần, vài giờ khác nhau, đo cả trang chủ, bài viết, trang sản phẩm. Chấm điểm SEO đo thời gian phản hồi và báo ttfb_cham nếu quá ngưỡng. Chi tiết về các chỉ số ở TTFB và Core Web Vitals.

Một lưu ý khi đo: đo bằng trình duyệt đã đăng nhập quản trị thì luôn chậm hơn, vì phần lớn bộ đệm trang bỏ qua người đã đăng nhập và thanh quản trị còn tải thêm kịch bản. Đo bằng cửa sổ ẩn danh hoặc dòng lệnh để thấy đúng tốc độ khách và Googlebot gặp.

Năm thủ phạm hay gặp phía máy chủ

1. Không có bộ đệm trang

Không có bộ đệm, mỗi lượt xem WordPress chạy PHP, gọi hàng chục tới hàng trăm truy vấn, dựng lại toàn bộ trang. Bộ đệm trang lưu sẵn HTML đã dựng, trả trong vài mili giây. Đây là cải thiện lớn nhất cho site nội dung. Có ba tầng: bộ đệm của hosting (nhiều hosting WordPress có sẵn), plugin bộ đệm trang, hoặc bộ đệm ở máy chủ web, CDN. Chỉ dùng một lớp bộ đệm trang; hai plugin bộ đệm cùng chạy gây lỗi khó đoán.

2. Plugin nặng

Một số plugin chạy truy vấn nặng trên mọi trang: thống kê lượt xem tự ghi vào cơ sở dữ liệu, bài liên quan tính toán động, page builder, plugin dịch tự động. Plugin Query Monitor (dành cho quản trị viên) cho biết mỗi trang chạy bao nhiêu truy vấn, truy vấn nào chậm, plugin nào gây ra. Tắt thử từng plugin nghi ngờ trên bản sao site để đo khác biệt.

3. wp-cron chạy theo lượt truy cập

WordPress mặc định chạy các tác vụ hẹn giờ (wp-cron) khi có lượt truy cập, kể cả lượt của bot. Site bị bot ghé nhiều thì wp-cron chạy liên tục, chồng tải lên tải. Cách sửa: thêm define('DISABLE_WP_CRON', true); vào wp-config.php và đặt một tác vụ cron thật của máy chủ chạy wp-cron.php mỗi 5–15 phút.

4. Bot dò mật khẩu qua xmlrpc.php và wp-login.php

Đọc nhật ký truy cập của nhiều site WordPress trên hosting dùng chung, không hiếm khi thấy gần một nửa lưu lượng là lượt gọi /xmlrpc.php từ bot dò mật khẩu, mỗi lượt tốn CPU như dựng cả trang, và một lệnh system.multicall có thể thử hàng trăm mật khẩu. Chặn xmlrpc nếu không dùng ứng dụng di động hay Jetpack; giới hạn đăng nhập. Xem bảo mật WordPress ảnh hưởng SEO.

5. Cơ sở dữ liệu phình to

Bảng tuỳ chọn (wp_options) chứa dữ liệu tự nạp (autoload) của plugin đã gỡ từ lâu, hàng chục nghìn bản nháp tự động, bình luận rác, dữ liệu tạm hết hạn. Mọi lượt dựng trang đều nạp phần autoload. Dọn bằng plugin dọn cơ sở dữ liệu hoặc truy vấn trực tiếp (sao lưu trước), và gỡ dữ liệu của plugin đã không dùng.

Con hẻm hẹp phố cổ đông đúc, một xe giao hàng bị kẹt sau mấy chiếc xe đẩy, nhìn từ trên cao

Phía trình duyệt: khi TTFB đã ổn

Ảnh: thu nhỏ, WebP, lazy load đúng chỗ; xem tối ưu ảnh.
Giao diện và page builder nặng: hàng trăm KB CSS, JS cho mọi trang. Đổi giao diện nhẹ là việc lớn nhưng hiệu quả nhất về lâu dài.
Kịch bản bên thứ ba: chat, pixel, bản đồ nhúng; xem INP.
Font: ít độ đậm, đúng phạm vi ký tự tiếng Việt; xem CLS.
WooCommerce cart fragments: lượt gọi AJAX cập nhật giỏ hàng trên mọi trang, kể cả trang không cần; tắt ở trang không có giỏ.

Plugin tăng tốc: bật gì, tránh gì

Plugin tối ưu tốc độ thường gom nhiều tính năng. Một số có ích rõ, một số dễ làm hỏng site:

Tính năng	Đánh giá
Bộ đệm trang	Có ích nhất; chỉ một lớp
Nén gzip, Brotli	Có ích; thường máy chủ hoặc CDN đã làm
Lazy load ảnh	Có ích, nhưng phải loại trừ ảnh đầu trang (ảnh LCP)
Gộp, thu nhỏ CSS, JS	Lợi ích nhỏ với HTTP/2; hay làm vỡ giao diện
Hoãn mọi JavaScript	Dễ làm hỏng menu, bộ lọc, nút mua; kiểm kỹ từng loại trang
“CSS quan trọng” tự sinh	Có thể có ích; hay lỗi trên trang có bố cục khác nhau
Tải trước liên kết khi rê chuột	Có ích cho trải nghiệm, tốn thêm tài nguyên máy chủ

Bật từng tính năng một, kiểm trang chủ, bài viết, sản phẩm, giỏ hàng trên điện thoại sau mỗi lần bật. Bật mười tính năng cùng lúc rồi phát hiện nút mua không chạy thì không biết tính năng nào gây ra.

Ví dụ: trang tin địa phương chậm vào buổi sáng

Ví dụ minh hoạ: một trang tin địa phương trên WordPress, hosting dùng chung, TTFB buổi tối khoảng 0,6 giây nhưng buổi sáng lên 4–6 giây, Googlebot gặp lỗi 503 rải rác. Chủ site đã cài ba plugin tăng tốc, không đỡ. Đo lại theo các bước trên: Query Monitor cho thấy trang chạy hơn 300 truy vấn vì một plugin “bài viết xem nhiều” ghi và đọc lượt xem trên mỗi lần tải; nhật ký truy cập buổi sáng có hàng nghìn lượt /xmlrpc.php từ vài dải IP lạ; wp-cron chạy theo lượt truy cập và kẹt ở một tác vụ gửi bản tin.

Sửa: gỡ plugin đếm lượt xem (dùng số liệu GA4 thay thế), chặn xmlrpc trong cấu hình máy chủ, chuyển wp-cron sang cron thật, gỡ hai trong ba plugin tăng tốc và giữ một lớp bộ đệm trang. TTFB về dưới 0,5 giây cả buổi sáng, lỗi 503 biến mất khỏi báo cáo Thống kê thu thập dữ liệu. Không cần đổi hosting.

Hosting: khi nào là lỗi của hosting

Trên hosting dùng chung, tốc độ site phụ thuộc cả “hàng xóm”. Dấu hiệu: TTFB dao động mạnh theo giờ, kể cả trang đã có bộ đệm; Query Monitor cho thấy truy vấn nhanh nhưng trang vẫn chậm. Cách phân biệt chắc chắn: đo thời gian PHP thực thi (Query Monitor ghi) so với thời gian tổng qua curl; PHP nhanh mà tổng chậm thì vấn đề nằm ngoài site. Khi đó, nâng gói hoặc chuyển hosting là cách duy nhất.

Phiên bản PHP cũng đáng kiểm: PHP 8.x nhanh hơn rõ rệt so với 7.x cũ; nâng cấp (sau khi kiểm plugin tương thích) là cải thiện miễn phí.

Checklist

Đo TTFB nhiều lần, nhiều loại trang.
TTFB cao: bật một lớp bộ đệm trang.
Query Monitor tìm plugin, truy vấn nặng.
wp-cron chạy bằng cron thật.
Chặn xmlrpc nếu không dùng; giới hạn số lần thử đăng nhập.
Dọn autoload, bản nháp, dữ liệu plugin đã gỡ.
Phía trình duyệt: ảnh, giao diện, kịch bản, font.
Nâng PHP; nếu vẫn dao động, xem lại hosting.
Đo lại sau mỗi thay đổi, ghi kết quả để biết thay đổi nào có tác dụng.

Hỏi đáp

Nên cài plugin tăng tốc nào cho WordPress?

Đo trước. Nếu TTFB cao, cần bộ đệm trang, có thể có sẵn ở hosting hoặc một plugin bộ đệm. Nếu TTFB thấp mà trang vẫn chậm, vấn đề ở ảnh, giao diện, kịch bản. Chỉ dùng một plugin bộ đệm trang.

TTFB bao nhiêu là tốt?

Dưới 0,8 giây là chấp nhận được theo hướng dẫn chung, dưới 0,3 giây là tốt. Với site có bộ đệm trang, thường đạt dưới 0,3 giây.

Tắt wp-cron có hại không?

Không, nếu thay bằng cron thật của máy chủ chạy wp-cron.php định kỳ. Các tác vụ hẹn giờ vẫn chạy, chỉ không còn chạy theo mỗi lượt truy cập.

Làm sao biết site chậm do hosting?

Nếu Query Monitor cho thấy PHP thực thi nhanh mà tổng thời gian phản hồi vẫn chậm và dao động theo giờ, thường là máy chủ quá tải do tài nguyên dùng chung. Khi đó cần nâng gói hoặc đổi hosting.