Nội dung
- Dùng công cụ nào để kiểm tra tốc độ web WordPress
- Đo đúng cách trước khi kết luận web chậm
- Ngưỡng Core Web Vitals Google dùng để chấm
- Cách đọc báo cáo PageSpeed Insights cho đúng
- Khoanh vùng nguyên nhân làm WordPress chậm
- Những lỗi hay gặp khi tự đo và tự sửa tốc độ
- Sau khi kiểm tra thì xử lý theo thứ tự nào
- Khi nào nên nhờ lập trình viên
- Câu hỏi thường gặp về kiểm tra tốc độ WordPress
Muốn biết web WordPress nhanh hay chậm, chỉ cần hai công cụ miễn phí: Google PageSpeed Insights để xem người dùng thật đang trải nghiệm ra sao, và GTmetrix để xem từng file tải mất bao lâu. Phần khó không nằm ở chỗ chạy công cụ mà ở chỗ đọc kết quả cho đúng, rồi tìm ra thứ thật sự làm web chậm.
Bài này đi theo thứ tự: chọn công cụ, các ngưỡng Google dùng để chấm, cách đọc báo cáo, cách khoanh vùng nguyên nhân và lúc nào nên gọi lập trình viên. Ví dụ trong bài lấy từ chính các lần đo và sửa tốc độ của marketing365.
Dùng công cụ nào để kiểm tra tốc độ web WordPress
Có rất nhiều công cụ đo tốc độ, nhưng phần lớn chạy cùng một bộ máy là Lighthouse của Google. Khác nhau chủ yếu ở chỗ công cụ đó có dữ liệu người dùng thật hay không, và có cho xem chi tiết từng file hay không.
| Công cụ | Dùng để làm gì | Lưu ý |
|---|---|---|
| PageSpeed Insights | Xem dữ liệu người dùng thật (Core Web Vitals) và điểm Lighthouse | Dữ liệu thật lấy từ Chrome UX Report, tính trên 28 ngày gần nhất |
| GTmetrix | Xem biểu đồ thác nước: file nào tải, tải lúc nào, mất bao lâu | Chạy trên Lighthouse; cần tài khoản đã xác thực email, bản miễn phí giới hạn vị trí đo |
| Search Console (báo cáo Core Web Vitals) | Xem nhóm URL nào đang tốt, cần cải thiện hay kém | Chỉ có khi trang có đủ lượt truy cập từ Chrome |
| Chrome DevTools (tab Performance) | Đo ngay trên máy mình, xem phần tử nào là LCP | Kết quả phụ thuộc máy và mạng của bạn |
Với một web WordPress bình thường, dùng PageSpeed Insights để biết có vấn đề không và vấn đề nằm ở chỉ số nào. Dùng GTmetrix để biết vấn đề đến từ file nào. Hai công cụ trả lời hai câu hỏi khác nhau, nên đừng chỉ nhìn điểm của một bên.
Đo đúng cách trước khi kết luận web chậm
Một lần đo không nói lên nhiều. Điểm Lighthouse dao động giữa các lần chạy, và theo tài liệu của Chrome, phần lớn sự dao động đó đến từ mạng, máy chủ và điều kiện đo chứ không phải từ Lighthouse.
- Đo nhiều lần. Chạy 3 lần, lấy kết quả ở giữa, đừng lấy lần đẹp nhất hay tệ nhất.
- Đo cả mobile và desktop. PageSpeed Insights mặc định giả lập điện thoại tầm trung trên mạng di động, nên điểm mobile gần như luôn thấp hơn desktop.
- Đo đúng trang. Trang chủ, một bài viết và một trang danh mục thường có kết quả khác nhau vì dùng giao diện và plugin khác nhau.
- Biết cache đang ở trạng thái nào. Lần đo đầu sau khi xoá cache sẽ chậm hơn hẳn các lần sau.
- Không đăng nhập khi đo. Nhiều plugin cache không phục vụ bản cache cho người đang đăng nhập quản trị.
Về cache, đây là ví dụ thực tế: khi trang không có trong cache (MISS), thời gian phản hồi máy chủ của marketing365 là 1,24–1,4 giây. Khi trang có trong cache (HIT), con số này là 0,11 giây. Cùng một trang, chênh hơn 1 giây chỉ vì trạng thái cache. Nguyên nhân và cách sửa nằm trong bài cache đã bật mà web vẫn chậm vì lỗi quyền thư mục.
Ngưỡng Core Web Vitals Google dùng để chấm
Core Web Vitals là ba chỉ số Google dùng để đánh giá trải nghiệm trang. Mỗi chỉ số có ngưỡng “tốt” rõ ràng, tính ở phân vị 75 của các lượt tải trang, tách riêng mobile và desktop. Nói đơn giản: ít nhất 75% lượt truy cập phải đạt ngưỡng thì trang mới được xếp “tốt”.
| Chỉ số | Đo cái gì | Tốt | Cần cải thiện | Kém |
|---|---|---|---|---|
| LCP | Nội dung lớn nhất hiện ra lúc nào | ≤ 2,5 giây | 2,5–4 giây | > 4 giây |
| INP | Trang phản hồi nhanh cỡ nào khi bấm, gõ | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS | Bố cục có bị xô lệch khi tải không | ≤ 0,1 | 0,1–0,25 | > 0,25 |
| FCP | Thứ đầu tiên hiện ra lúc nào | ≤ 1,8 giây | 1,8–3 giây | > 3 giây |
| TTFB | Máy chủ trả byte đầu tiên sau bao lâu | ≤ 800 ms | 800–1.800 ms | > 1.800 ms |
Ba dòng đầu là Core Web Vitals. FCP và TTFB là chỉ số phụ để chẩn đoán, PageSpeed Insights vẫn hiển thị chúng; TTFB đang được ghi là chỉ số thử nghiệm. Ngưỡng lấy theo tài liệu của Google tại thời điểm 10/2026.
Cách đọc báo cáo PageSpeed Insights cho đúng
Báo cáo PageSpeed Insights có hai phần, và nhiều người chỉ nhìn phần thứ hai.
Phần trên: dữ liệu người dùng thật
Đây là dữ liệu từ Chrome UX Report, gom từ người dùng Chrome thật trong 28 ngày gần nhất. Nó cho biết trang đạt hay không đạt Core Web Vitals. Nếu trang chưa đủ lượt truy cập, công cụ sẽ hiện dữ liệu của cả tên miền thay vì riêng trang đó. Nếu cả tên miền cũng không đủ, phần này để trống.
Vì là dữ liệu 28 ngày, sửa xong hôm nay thì phần này chưa đổi ngay. Bạn cần chờ dữ liệu mới tích luỹ dần.
Phần dưới: điểm Lighthouse
Đây là kết quả đo giả lập trong phòng thí nghiệm, trên một máy điện thoại tầm trung và mạng di động giả lập. Điểm từ 0 đến 100: 0–49 là kém, 50–89 là cần cải thiện, 90–100 là tốt.
Điểm này là tổng có trọng số của năm chỉ số: TBT chiếm 30%, LCP và CLS mỗi chỉ số 25%, FCP và Speed Index mỗi chỉ số 10%. Vì TBT nặng nhất, một web nhiều JavaScript có thể điểm thấp dù nội dung hiện ra khá nhanh.
Điểm Lighthouse hữu ích để thử nghiệm trước và sau khi sửa. Nhưng thứ Google dùng để đánh giá trải nghiệm là dữ liệu người dùng thật ở phần trên.
Sửa chỉ số nào trước
Khi xem báo cáo, sửa trước chỉ số đang ở mức “kém” trong dữ liệu người dùng thật (PageSpeed Insights phần trên hoặc báo cáo Core Web Vitals trong Search Console). Sau đó mới tới chỉ số “cần cải thiện”. Không có thứ tự cứng kiểu “luôn sửa LCP trước”: trang có CLS kém và LCP tốt thì phải sửa CLS.
Khoanh vùng nguyên nhân làm WordPress chậm
Biết chỉ số nào kém rồi, bước tiếp theo là tìm thủ phạm. Làm lần lượt bốn việc dưới đây.
1. Đọc biểu đồ thác nước
Trong GTmetrix (hoặc Pingdom), mở tab thác nước. Mỗi dòng là một file: HTML, CSS, JavaScript, ảnh, font. Thanh dài nghĩa là file tải lâu. Nhìn ba thứ: dòng đầu tiên (tài liệu HTML) chờ bao lâu, file nào to nhất, và file nào đến từ tên miền bên ngoài như mã quảng cáo, chat, mạng xã hội.
2. Đo thời gian phản hồi máy chủ (TTFB)
Nếu dòng HTML đầu tiên đã chờ lâu, vấn đề nằm ở máy chủ hoặc cache, không phải ở ảnh hay CSS. Theo ngưỡng của PageSpeed Insights, TTFB trên 800 ms đã ở mức cần cải thiện. Thường gặp: cache không chạy, gói hosting yếu, cơ sở dữ liệu chậm hoặc plugin chạy truy vấn nặng mỗi lần tải trang.
3. Tắt thử từng plugin nặng
Trên một bản sao của web (staging), tắt từng plugin nghi ngờ rồi đo lại. Plugin hay gây chậm thường là trình dựng trang, slider, plugin thống kê, plugin chia sẻ mạng xã hội và plugin chèn nhiều script bên ngoài. Tắt từng cái một để biết chính xác cái nào, đừng tắt cả loạt.
4. So sánh mobile với desktop
Desktop nhanh mà mobile chậm thường do JavaScript nặng (máy yếu xử lý lâu), ảnh không có bản nhỏ cho màn hình điện thoại, hoặc cache bản mobile bị tách riêng và chưa được làm nóng. Cách sửa riêng cho điện thoại có trong bài cách tối ưu tốc độ web trên điện thoại.
Những lỗi hay gặp khi tự đo và tự sửa tốc độ
Ba ví dụ dưới đây đều có thật trên marketing365. Chúng cho thấy đo sai hoặc đọc sai còn tốn công hơn là không đo.
Nhìn nhầm phần tử LCP
Lighthouse báo phần tử LCP là chữ, nhưng thật ra là ảnh nền CSS của khối tiêu đề. LCP lúc đó là 7,8 giây, trong đó phần chờ hiển thị chiếm 6,5 giây (83%). Sửa sai chỗ suốt nhiều ngày vì tin vào nhãn. Chi tiết trong bài 11 ngày sửa nhầm chỗ vì nhãn LCP sai.
Cắt CSS mà LCP không đổi
Cắt file CSS chính của giao diện từ khoảng 1,2 MB xuống khoảng 243 KB làm điểm mobile tăng từ 57 lên 66 và TBT giảm từ 370 xuống 130 ms. Nhưng LCP gần như giữ nguyên, 7,1 giây thành 7,4 giây, vì LCP đang bị quyết định bởi ảnh đầu trang và thời gian phản hồi máy chủ. Đọc thêm: cắt CSS theme mà LCP không nhúc nhích.
Nhét quá nhiều CSS vào đầu trang
Đưa toàn bộ khoảng 325 KB CSS vào thẳng HTML để “tránh chặn hiển thị” làm điểm mobile rơi từ 38 xuống 14, TBT tăng từ 1.582 lên 4.182 ms và CLS từ 0 lên 0,724. Phần CSS thật sự cần cho trang chủ chỉ khoảng 11 KB. Bài học: nếu CSS nhúng vượt khoảng 20 KB, nhiều khả năng bạn đã lấy sai phần; luôn có đường lui. Chi tiết trong bài tối ưu CSS khiến điểm tốc độ tụt từ 38 xuống 14.
Sau khi kiểm tra thì xử lý theo thứ tự nào
- Ghi lại kết quả hiện tại: dữ liệu người dùng thật, điểm Lighthouse mobile/desktop, TTFB, ảnh chụp thác nước.
- Chọn chỉ số đang “kém” trong dữ liệu người dùng thật làm mục tiêu đầu tiên.
- Kiểm tra cache và TTFB trước, vì máy chủ chậm thì sửa ảnh hay CSS cũng không bù lại được.
- Xử lý phần tử LCP thật: xác định đúng nó là ảnh, ảnh nền hay chữ, rồi mới sửa.
- Sửa từng thay đổi một, đo lại sau mỗi lần, ghi lại kết quả.
- Chờ dữ liệu người dùng thật cập nhật trong vài tuần trước khi kết luận cách sửa có hiệu quả.
Khi nào nên nhờ lập trình viên
Bạn tự làm được phần đo, đọc báo cáo, bật cache, nén ảnh và tắt plugin không cần. Nên nhờ người có chuyên môn khi gặp một trong các trường hợp sau:
- TTFB vẫn cao dù cache đã chạy đúng: cần xem cấu hình máy chủ, PHP, cơ sở dữ liệu.
- INP kém: thường phải đọc và sửa JavaScript của giao diện hoặc plugin.
- Cần tách CSS quan trọng, hoãn tải script hoặc sửa giao diện con: làm sai dễ vỡ bố cục, như ví dụ điểm tụt từ 38 xuống 14 ở trên.
- Đã sửa hết phần dễ mà dữ liệu người dùng thật vẫn ở mức “kém” sau vài tuần.
Khi nhờ, hãy đưa họ kết quả đo trước, ảnh chụp thác nước và danh sách những gì đã thử. Việc này giúp họ không phải đo lại từ đầu.
Câu hỏi thường gặp về kiểm tra tốc độ WordPress
Điểm PageSpeed thấp có làm tụt thứ hạng Google không?
Google dùng dữ liệu người dùng thật của Core Web Vitals, không dùng điểm Lighthouse. Điểm Lighthouse thấp là tín hiệu nên xem lại, nhưng nó không phải con số Google dùng để chấm trang của bạn.
Vì sao mỗi lần đo ra một điểm khác nhau?
Vì mạng, tải của máy chủ, trạng thái cache và quảng cáo hay script bên ngoài thay đổi giữa các lần chạy. Hãy đo vài lần và xem xu hướng, không chạy theo một con số.
Phần dữ liệu người dùng thật trống thì làm sao?
Trang chưa đủ lượt truy cập từ Chrome để có dữ liệu. Khi đó dựa vào điểm Lighthouse và thác nước để tìm lỗi, rồi theo dõi báo cáo Core Web Vitals trong Search Console khi web có thêm lượt truy cập.
Có cần điểm 100 không?
Không. Mục tiêu thực tế là ba chỉ số Core Web Vitals đạt mức “tốt” trong dữ liệu người dùng thật. Chạy theo điểm 100 thường tốn công mà người dùng không cảm nhận được khác biệt.
Nguồn: Web Vitals trên web.dev, tài liệu PageSpeed Insights, cách Lighthouse tính điểm hiệu suất, hướng dẫn đọc biểu đồ thác nước GTmetrix.
Bạn có thể đọc thêm các bài cùng chủ đề trong chuyên mục SEO.
