Kiểm tra plugin làm WordPress chậm bằng Query Monitor giúp bạn nhìn thấy truy vấn database, lỗi PHP, HTTP API và thành phần chịu trách nhiệm ngay trên từng trang. Thay vì tắt hàng loạt plugin rồi đoán, bạn có thể thu thập bằng chứng, khoanh vùng nghi phạm và xác minh thay đổi theo một quy trình có thể lặp lại.
Query Monitor là bộ công cụ dành cho nhà phát triển WordPress và WooCommerce. Plugin không tự tuyên bố “plugin X là thủ phạm”, nhưng cung cấp dữ liệu đủ chi tiết để biết thành phần nào tạo truy vấn chậm, truy vấn trùng, request ra ngoài lâu hoặc lỗi PHP. Bài viết này tập trung vào cách đọc đúng dữ liệu và tránh kết luận sai.
Query Monitor có tạo thêm một lượng nhỏ thời gian xử lý và bộ nhớ khi thu thập dữ liệu. Chỉ bật trong lúc chẩn đoán, ưu tiên staging và tắt plugin sau khi hoàn tất.
Query Monitor có thể kiểm tra những gì?
Theo trang plugin chính thức, Query Monitor hiển thị thông tin của mỗi lượt tải trang, gồm:
- Truy vấn database chậm, trùng hoặc lỗi;
- Component chịu trách nhiệm: plugin, theme hoặc WordPress Core;
- Hàm gọi và call stack liên quan;
- Lỗi PHP, cảnh báo, deprecated và “Doing it Wrong”;
- HTTP API request, mã phản hồi và thời gian xử lý;
- Hook, action và callback được đăng ký;
- Script, stylesheet và dependency;
- Template, block, rewrite rule và query variable;
- Thông tin PHP, database, web server và bộ nhớ;
- Ajax và REST API đối với người dùng có quyền xem dữ liệu.
Mặc định, dữ liệu Query Monitor chỉ hiển thị cho Administrator trên website đơn và Super Admin trên WordPress Multisite. Plugin không lưu lâu dài dữ liệu đã thu thập và không gửi dữ liệu tới bên thứ ba, theo tuyên bố riêng tư của dự án.
Trước khi kiểm tra plugin làm WordPress chậm
Một phép đo thiếu kiểm soát rất dễ dẫn tới kết luận sai. Trang đầu có cache không thể so trực tiếp với trang quản trị không cache; trang giỏ hàng WooCommerce cũng không thể so với một bài viết tĩnh.
Trước khi bắt đầu, hãy chuẩn bị:
- Một bản backup có thể khôi phục;
- Website staging nếu có thể;
- Danh sách URL đại diện cho hành vi thực tế;
- Trình duyệt, tài khoản và điều kiện kiểm tra nhất quán;
- Cache được giữ cùng trạng thái trong các lần so sánh;
- Ghi lại thời gian tạo trang, số truy vấn và bộ nhớ ban đầu;
- Không cập nhật plugin, theme hoặc PHP giữa hai lần đo.
Không nên bật hoặc tắt plugin trực tiếp trên website bán hàng đang có giao dịch. Nếu bắt buộc kiểm tra production, hãy chọn thời điểm ít truy cập, chỉ thay đổi một thành phần mỗi lần và chuẩn bị rollback.
Bước 1: Cài và mở Query Monitor
Trong WordPress Admin, vào Plugins → Add New Plugin, tìm Query Monitor của John Blackbourn, cài đặt rồi kích hoạt. Sau đó mở trang cần kiểm tra khi đang đăng nhập bằng tài khoản có quyền Administrator.
Query Monitor thêm nhóm chỉ số lên Admin Toolbar. Tùy trang và cấu hình, bạn sẽ thấy thời gian tạo trang, bộ nhớ, tổng số database query và cảnh báo. Nhấp vào nhóm chỉ số để mở bảng chi tiết ở cuối màn hình.
Nếu toolbar không xuất hiện, hãy kiểm tra:
- Bạn đang đăng nhập đúng tài khoản quản trị;
- Admin Toolbar chưa bị tắt trong hồ sơ người dùng;
- Plugin đã được kích hoạt cho site hiện tại;
- Website Multisite yêu cầu quyền Super Admin;
- Cache trang không trả về bản HTML của phiên khác.
Bước 2: Ghi nhận số liệu nền của từng loại trang
Hãy chọn từ ba đến năm trang đại diện, chẳng hạn:
- Trang chủ;
- Một bài viết dài;
- Trang tìm kiếm hoặc danh mục;
- Trang quản trị bài viết;
- Trang sản phẩm, giỏ hàng và thanh toán nếu dùng WooCommerce.
Với mỗi URL, tải lại vài lần trong cùng điều kiện và ghi nhận:
- Page Generation Time;
- Peak Memory Usage;
- Total Database Query Time;
- Tổng số database query;
- Số cảnh báo PHP;
- HTTP API request chậm hoặc thất bại.
Không có một ngưỡng duy nhất phù hợp cho mọi website. Một trang có nhiều query chưa chắc chậm nếu các query đều nhanh và được thiết kế hợp lý. Ngược lại, chỉ một HTTP request ra ngoài bị treo cũng có thể làm toàn bộ trang phản hồi chậm.
Nếu muốn hiểu vì sao TTFB thay đổi theo vị trí và cache, hãy xem thêm bài TTFB trên trình duyệt và Google PageSpeed khác nhau như thế nào.
Bước 3: Tìm truy vấn database chậm theo Component
Mở bảng Database Queries và ưu tiên ba nhóm:
- Queries by Component: Nhóm query theo plugin, theme hoặc Core;
- Duplicate Queries: Các câu truy vấn giống nhau chạy nhiều lần;
- Slow Queries: Những query mất nhiều thời gian hơn mức cảnh báo của Query Monitor.
Khi một plugin xuất hiện nhiều, đừng kết luận ngay plugin đó có lỗi. Hãy xem đồng thời:
- Tổng thời gian query của component;
- Query cụ thể và số lần lặp;
- Caller hoặc hàm đã gọi query;
- URL nào tái hiện được hiện tượng;
- Query thuộc thao tác cần thiết hay chạy trên mọi trang không liên quan.
Ví dụ, plugin WooCommerce đương nhiên tạo nhiều query trên trang thanh toán. Điều đáng chú ý hơn là một plugin không liên quan vẫn tải dữ liệu lớn trên mọi trang, hoặc lặp cùng một query hàng chục lần vì callback được gọi sai vị trí.
Bước 4: Kiểm tra HTTP API request bị chậm
Mở bảng HTTP API Calls để tìm request WordPress gửi tới dịch vụ bên ngoài. Đây là nhóm nguyên nhân thường bị bỏ sót vì database vẫn nhanh nhưng trang phải chờ API phản hồi.
Hãy chú ý:
- Request mất nhiều thời gian;
- Mã phản hồi 4xx hoặc 5xx;
- DNS, SSL hoặc timeout;
- Component đã tạo request;
- Request có chạy trên mọi page load hay không;
- Plugin có cache kết quả từ API hay gọi lại liên tục.
Các nguồn phổ biến gồm API license, tỷ giá, vận chuyển, thanh toán, font, chống spam, đồng bộ CRM và webhook. Nếu dịch vụ ngoài không ổn định, hướng xử lý có thể là cache dữ liệu, chuyển sang tác vụ nền, giảm timeout hợp lý hoặc chỉ gọi API ở trang thật sự cần.
Không chặn request một cách mù quáng. Một API chậm vẫn có thể là bước bắt buộc của thanh toán hoặc xác thực license.
Bước 5: Đọc lỗi PHP và cảnh báo Deprecated
Bảng PHP Errors cho biết loại lỗi, file, dòng code, component và call stack. Một cảnh báo chưa chắc trực tiếp làm website chậm, nhưng lỗi lặp lại trên mọi request có thể làm tăng I/O khi ghi log và che khuất lỗi nghiêm trọng hơn.
Ưu tiên xử lý:
- Fatal error hoặc uncaught exception;
- Warning lặp lại với số lượng lớn;
- Deprecated sau khi nâng PHP hoặc WordPress;
- Lỗi thuộc plugin đã lâu không cập nhật;
- Lỗi chỉ xuất hiện ở một URL hoặc hành động cụ thể.
Không bật hiển thị lỗi PHP công khai trên production. Query Monitor cho phép quản trị viên xem dữ liệu chẩn đoán mà không cần in thông báo lỗi ra giao diện cho khách truy cập.
Bước 6: Kiểm tra Script, Stylesheet và Hook
Backend nhanh không đồng nghĩa giao diện tải nhanh. Mở bảng Scripts và Styles để xem asset, dependency và component chịu trách nhiệm.
Các dấu hiệu cần rà:
- Plugin tải CSS hoặc JavaScript trên trang không sử dụng tính năng của nó;
- Dependency bị thiếu hoặc tải sai thứ tự;
- Nhiều asset nhỏ đến từ cùng một plugin;
- Script bên thứ ba làm chậm phần giao diện;
- Plugin chỉ cần trong trang quản trị nhưng lại tải ở frontend.
Bảng Hooks & Actions hữu ích để biết callback nào được gắn vào một hook. Tuy nhiên, số callback nhiều không tự động đồng nghĩa chậm. Cần đối chiếu với database query, HTTP request và thời gian tạo trang trước khi kết luận.
Bước 7: Khoanh vùng plugin bằng phép thử có kiểm soát
Sau khi Query Monitor chỉ ra một hoặc vài component đáng ngờ, hãy xác minh trên staging:
- Lưu số liệu nền của URL đang chậm;
- Chỉ tắt một plugin nghi ngờ;
- Giữ nguyên URL, tài khoản và trạng thái cache;
- Tải lại nhiều lần và ghi số liệu mới;
- Bật lại plugin để xem hiện tượng có quay lại;
- Nếu cần, thử phiên bản plugin mới hoặc cấu hình nhẹ hơn;
- Kiểm tra chức năng nghiệp vụ trước khi đưa thay đổi lên production.
Phép thử tắt rồi bật lại giúp phân biệt tương quan và nguyên nhân. Nếu thời gian giảm một lần nhưng không lặp lại, khác biệt có thể đến từ cache, truy vấn nền, bot hoặc dịch vụ ngoài.
Cách đọc kết quả mà không kết luận sai
Plugin có nhiều query nhất chưa chắc là plugin chậm nhất
Một plugin thương mại điện tử có thể cần nhiều query hợp lệ. Hãy quan tâm tổng thời gian, query lặp, index database và việc query có xuất hiện ở trang không liên quan hay không.
Page Generation Time không phải toàn bộ thời gian tải trang
Chỉ số này phản ánh phần xử lý phía máy chủ mà Query Monitor quan sát được. DNS, TLS, mạng, ảnh lớn, JavaScript và hiển thị trên trình duyệt vẫn ảnh hưởng trải nghiệm thực tế.
Cache có thể che mất vấn đề
Người dùng ẩn danh có thể nhận trang từ full-page cache, trong khi quản trị viên và trang WooCommerce động vẫn chạy PHP. Vì vậy cần kiểm tra cả trang cache và luồng không cache.
Một plugin có thể chỉ chậm ở một tác vụ
Plugin có thể nhanh ở frontend nhưng chậm khi lưu bài, tìm kiếm sản phẩm, xử lý checkout hoặc chạy Ajax. Hãy mở đúng màn hình và thực hiện đúng thao tác cần chẩn đoán.
Để hiểu thêm mối quan hệ giữa số người dùng và số request, xem bài User và Request: Vì sao ít người online vẫn có thể làm web quá tải.
Hướng xử lý sau khi tìm được nguyên nhân
Tùy dữ liệu thu được, bạn có thể:
- Cập nhật plugin lên phiên bản đã sửa lỗi;
- Tắt module không sử dụng trong plugin;
- Chỉ nạp asset hoặc chạy logic ở trang cần thiết;
- Sửa query, thêm index sau khi đánh giá cẩn thận;
- Cache kết quả API hoặc chuyển tác vụ sang hàng đợi;
- Thay plugin bằng giải pháp nhẹ hơn;
- Gửi báo cáo có URL, caller và số liệu cho nhà phát triển;
- Loại bỏ plugin không còn dùng.
Nếu vấn đề liên quan lịch nền, bài Thay WP-Cron bằng Cron Job cho WordPress giúp bạn tách tác vụ định kỳ khỏi lượt truy cập. Với dữ liệu cache, có thể đọc thêm bài Cơ chế và các tầng cache trong hệ thống.
Không nên chỉnh trực tiếp WordPress Core hoặc file plugin đang hoạt động vì bản cập nhật tiếp theo sẽ ghi đè thay đổi. Với lỗi code, hãy sửa trong plugin riêng, child theme hoặc gửi patch cho nhà phát triển.
Khi nào nên tắt Query Monitor?
Query Monitor có mức ảnh hưởng nhỏ trong điều kiện bình thường, nhưng vẫn phải thu thập và trình bày dữ liệu. Trên trang có hàng trăm query, plugin có thể dùng thêm bộ nhớ.
Sau khi kiểm tra xong:
- Lưu lại ảnh và số liệu cần thiết;
- Tắt Query Monitor trên production;
- Xóa plugin nếu không sử dụng thường xuyên;
- Không chia sẻ ảnh chứa đường dẫn máy chủ, query nhạy cảm hoặc dữ liệu khách hàng;
- Theo dõi lại website sau khi áp dụng thay đổi.
Có thể giữ Query Monitor trên staging để phục vụ phát triển, nhưng nên cập nhật plugin và giới hạn quyền truy cập môi trường này.
Câu hỏi thường gặp
Query Monitor có làm website chậm không?
Có một mức overhead nhỏ vì plugin phải thu thập dữ liệu. Trang chính thức cho biết tác động thông thường là không đáng kể, nhưng trang có hàng trăm database query có thể dùng thêm bộ nhớ. Vì vậy chỉ nên bật khi chẩn đoán, đặc biệt trên production.
Khách truy cập có thấy Query Monitor không?
Mặc định không. Query Monitor chỉ hiển thị cho Administrator trên website đơn và Super Admin trên Multisite. Dù vậy, staging vẫn nên được bảo vệ và không nên công khai dữ liệu chẩn đoán.
Query Monitor có tự sửa plugin chậm không?
Không. Plugin cung cấp dữ liệu để xác định component, query, HTTP request, lỗi và caller. Bạn vẫn phải xác minh nguyên nhân rồi chọn cách sửa phù hợp.
Query Monitor có thay thế PageSpeed Insights không?
Không. Query Monitor tập trung vào quá trình WordPress tạo response phía máy chủ. PageSpeed Insights đánh giá thêm trải nghiệm giao diện, tài nguyên, Core Web Vitals và điều kiện mạng mô phỏng. Hai công cụ bổ sung cho nhau.
Có thể kiểm tra WooCommerce bằng Query Monitor không?
Có. Hãy kiểm tra riêng trang sản phẩm, giỏ hàng, thanh toán, tài khoản và các màn hình quản trị liên quan. Không đưa dữ liệu khách hàng hoặc thông tin thanh toán vào ảnh chụp báo cáo.
Kết luận
Kiểm tra plugin làm WordPress chậm bằng Query Monitor hiệu quả nhất khi bạn đo cùng URL trong cùng điều kiện, xem Database Queries theo Component, kiểm tra HTTP API và lỗi PHP, sau đó xác minh bằng cách chỉ thay đổi một plugin mỗi lần trên staging.
Query Monitor giúp chuyển quá trình xử lý sự cố từ phỏng đoán sang dữ liệu. Tuy nhiên, công cụ không thay thế việc hiểu luồng nghiệp vụ, cache và đặc điểm của từng trang. Hãy backup trước, ghi lại số liệu nền, rollback khi kết quả không như dự kiến và tắt công cụ sau khi hoàn thành.
