Website chậm dù VPS mạnh không đủ để kết luận máy chủ thiếu tài nguyên. Tài liệu WordPress, PHP và Chrome cho thấy hiệu năng còn phụ thuộc cách ứng dụng xử lý yêu cầu, giới hạn tiến trình và tài nguyên trình duyệt phải tải. Hướng dẫn dưới đây tập trung vào WordPress dùng PHP-FPM và MySQL; các bước chỉnh dịch vụ chỉ áp dụng khi website thực sự dùng thành phần tương ứng.
1. Đo để xác định trang chậm ở giai đoạn nào
Chuẩn bị một URL đang chậm và ghi rõ trạng thái đăng nhập, thiết bị, mạng truy cập. Trong Chrome DevTools, mở Network, tải lại trang, chọn yêu cầu tài liệu rồi xem Timing. Theo tài liệu Chrome, DNS Lookup là thời gian phân giải tên miền; Initial connection liên quan việc thiết lập kết nối; Waiting (TTFB) gồm độ trễ một vòng mạng và thời gian máy chủ chuẩn bị phản hồi. Vì vậy, Waiting dài chưa chứng minh riêng CPU yếu.
Ghi lại các khoảng thời gian này làm mốc trước sửa. Nếu phản hồi tài liệu đến sớm nhưng nội dung chính xuất hiện muộn, chuyển trọng tâm sang bước ảnh và mã giao diện. Nếu thời gian chờ phản hồi chiếm phần lớn, ưu tiên ứng dụng, cache và PHP. Đây là cách phân nhánh chẩn đoán, chưa phải kết luận nguyên nhân của website cụ thể.
2. Khoanh vùng plugin hoặc giao diện gây chậm
Với WordPress, chuẩn bị bản sao thử nghiệm và bản sao lưu trước khi thay đổi. WordPress khuyến nghị vô hiệu hóa có chọn lọc plugin để đo ảnh hưởng; web.dev cũng xác định chất lượng plugin và giao diện là yếu tố tác động đến TTFB. Trên bản thử nghiệm, tắt từng plugin không thiết yếu, đo lại đúng URL rồi bật lại trước khi thử thành phần tiếp theo.
Chỉ đề xuất thay thế hoặc sửa thành phần khi kết quả lặp lại cho thấy khác biệt trong cùng điều kiện. Đồng thời kiểm tra chức năng mà plugin đảm nhiệm, như biểu mẫu hoặc giỏ hàng. Nếu tính năng hỏng hoặc thời gian không cải thiện, khôi phục trạng thái ban đầu. Tránh tắt hàng loạt rồi quy trách nhiệm cho một plugin chưa được kiểm chứng.
3. Thiết lập bộ nhớ đệm cho nội dung phù hợp
Trước tiên, xác định website đang dùng cơ chế cache nào. Tài liệu WordPress phân biệt việc tái sử dụng trang đã tạo với object cache lưu dữ liệu để giảm truy cập cơ sở dữ liệu. Khi cấu hình, chọn đúng lớp cần xử lý: page cache cho trang công khai phù hợp; persistent object cache khi ứng dụng cần tái sử dụng dữ liệu giữa các yêu cầu. Không mặc định cài thêm nhiều plugin cache.
Kiểm tra riêng khách chưa đăng nhập và người đã đăng nhập. Theo web.dev, cache dùng chung không phù hợp với nội dung cá nhân hóa; vì vậy cần cấu hình ngoại lệ cho trang tài khoản, giỏ hàng và nội dung riêng theo cơ chế của công cụ đang dùng. Xác minh cả tốc độ lẫn tính đúng của dữ liệu sau cập nhật. Nếu xuất hiện nội dung cũ hoặc sai người dùng, hoàn tác quy tắc vừa thêm và xóa cache liên quan.
4. Kiểm tra hàng đợi PHP-FPM trước khi tăng worker
Bước này cần quyền quản trị dịch vụ và bản sao cấu hình pool. Theo PHP Manual, pm.max_children giới hạn số yêu cầu được phục vụ đồng thời. Trang trạng thái FPM cung cấp listen queue, số tiến trình hoạt động và max children reached. Nếu bật pm.status_path để quan sát, hãy giới hạn truy cập nội bộ hoặc IP quản trị theo hướng dẫn PHP, rồi kiểm tra đúng pool phục vụ website.
Quan sát hàng đợi trong lúc website thực sự chậm. Chỉ cân nhắc tăng giới hạn khi dữ liệu cho thấy thiếu tiến trình và ngân sách bộ nhớ còn phù hợp; không lấy một con số worker trên mạng làm mặc định. Sau thay đổi, so sánh hàng đợi, thời gian phản hồi và bộ nhớ với mốc cũ. Nếu kết quả xấu đi, phục hồi cấu hình pool đã lưu và nạp lại dịch vụ theo quy trình của hệ thống.
5. Phân tích truy vấn trước khi sửa cơ sở dữ liệu
Nếu đã khoanh vùng thời gian xử lý vào cơ sở dữ liệu, lấy câu truy vấn liên quan từ công cụ chẩn đoán của ứng dụng. Tài liệu MySQL hướng dẫn dùng EXPLAIN để xem kế hoạch thực thi, gồm cách truy cập và kết hợp bảng. Trên môi trường thử nghiệm có dữ liệu đại diện, đối chiếu kế hoạch với điều kiện lọc và các chỉ mục hiện có trước khi đề xuất sửa.
Không thêm chỉ mục cho mọi cột hoặc xóa dữ liệu chỉ vì bảng lớn. Hãy yêu cầu một phương án cụ thể, sao lưu trước thay đổi và đo lại truy vấn cùng trang bị ảnh hưởng. Kiểm tra kết quả trả về có giữ nguyên ý nghĩa không. Nếu chưa xác định được truy vấn gây chậm, giữ bước này ở mức thu thập bằng chứng thay vì chỉnh cấu hình MySQL theo phỏng đoán.
6. Giảm dung lượng ảnh đang làm chậm nội dung chính
Khi tài liệu phản hồi nhanh nhưng ảnh hiển thị chậm, dùng mục Improve image delivery của Chrome để tìm ảnh có thể tối ưu. Tài liệu Chrome và web.dev khuyến nghị xem xét kích thước, mức nén và định dạng ảnh. Chuẩn bị bản gốc, tạo biến thể phù hợp kích thước hiển thị rồi thay trên bản thử nghiệm. So sánh dung lượng tải, độ rõ và thời điểm nội dung chính xuất hiện; khôi phục ảnh gốc nếu chất lượng không đạt.
7. Xử lý CSS và JavaScript chặn hiển thị
Nếu ảnh đã tải xong nhưng trang còn chờ hiển thị, kiểm tra nhóm Render-blocking requests. Chrome và web.dev giải thích rằng stylesheet hoặc script đồng bộ có thể trì hoãn việc vẽ nội dung. Trên bản thử nghiệm, giảm CSS không cần cho màn hình đầu hoặc trì hoãn script phù hợp với phụ thuộc thực tế. Đo lại LCP, đồng thời thử menu, biểu mẫu và bố cục trên điện thoại. Hoàn tác từng thay đổi nếu xuất hiện lỗi; không bật đồng loạt mọi tùy chọn tối ưu.
8. Đối chiếu kết quả trước khi quyết định nâng VPS
Lặp lại phép đo ban đầu với cùng URL và điều kiện truy cập; ghi riêng trường hợp có cache và không có cache. web.dev khuyến nghị dùng dữ liệu người dùng thực tế kết hợp công cụ phòng thử nghiệm để tìm nguyên nhân. Nếu PageSpeed Insights có dữ liệu thực tế cho website, dùng thêm dữ liệu đó để đối chiếu. Chỉ đề xuất nâng tài nguyên khi quan sát còn cho thấy giới hạn tương ứng sau sửa; bài viết này không cung cấp benchmark hay cam kết mức tăng tốc cho một VPS cụ thể.
