Khi ai đó nói website WordPress của họ chậm, họ thường đi tới hai kết luận giống nhau: mua hosting mạnh hơn, hoặc cài một plugin cache rồi cầu may. Cả hai đều có thể giúp. Nhưng phần thắng lớn nhất gần như luôn nằm ở chỗ trang gửi gì về cho trình duyệt và theo thứ tự nào — mà mấy thứ đó không tốn gì ngoài sự để ý.
Đây là số liệu trước–sau thật trên chính blog này: 700 bài, theme Astra có tuỳ biến nhẹ, chạy trên phần cứng bình thường. Mọi con số dưới đây là phép đo Lighthouse, cấu hình mobile, đo theo cách trung thực — lấy trung vị của năm lần chạy, đã tắt output debug. Mình đưa số mobile vì mobile mới là nơi website thật sự chậm; desktop vốn đã nhanh và vẫn nhanh.
Điểm khởi đầu
Perf LCP A11y
home mobile 63 7.7s 86
post mobile 71 4.7s 97
page mobile 79 3.7s 95Template bài viết — đúng cái trang phần lớn khách từ tìm kiếm rơi vào — đang ở 71 điểm với Largest Contentful Paint 4,7 giây. Google coi bất cứ mức nào trên 2,5s là “cần cải thiện”, và trên 4s là điểm trượt. Trên mobile, nơi nhiều người đọc vào bằng đường mạng chập chờn, 4,7s là khác biệt giữa một người đọc và một lần thoát trang.
Điều then chốt: không có phần nào trong đây là vấn đề hosting. Server đang trả lời dưới 200ms. Thời gian bị mất hoàn toàn ở phía trình duyệt, sau khi HTML đã về — mà đó đúng là nơi hiệu năng WordPress thật sự nằm.
Tìm ra nút thắt thật
Lighthouse rất cụ thể nếu bạn đọc quá phần điểm số. Mục chẩn đoán chỉ vào bốn thứ, xếp đại khái theo mức ảnh hưởng:
- Ảnh hero là
background-imagetrong CSS. Phần tử lớn nhất trên trang — đúng cái thứ mà LCP đo — lại được nạp qua CSS. Trình duyệt không thể thấy một background trong CSS trước khi tải và phân tích xong file stylesheet, nên tấm ảnh quan trọng nhất của trang cũng là một trong những thứ cuối cùng trình duyệt mới biết là cần tải.
- Google Fonts chặn render. Một thẻ
<link rel="stylesheet">trơn trỏ tới stylesheet font trong<head>sẽ ngăn trang vẽ ra cho tới khi font tải xong. Người đọc ngồi nhìn khoảng trắng trong lúc một file font đi qua đường mạng.
- ~30 KB JavaScript không ai dùng. Bộ polyfill emoji (
wp-emoji) vàwp-embedđược nạp mặc định trên mọi trang WordPress. Blog này không dùng cái nào.
- ~50 KB CSS không dùng.
wp-block-librarymang theo style cho hàng chục block Gutenberg. Mấy bài này dùng đoạn văn với tiêu đề, vốn hiển thị tốt mà không cần nó, cộng thêm một khối “global styles” nội tuyến cũng không cần thiết.
Không có thứ nào trong đây là lạ lẫm. Mỗi thứ đều đang hiện diện trên một tỷ lệ lớn website WordPress ngay lúc này.
Các thay đổi
Mình làm theo từng đợt, đo lại sau mỗi đợt để quy được phần tăng cho đúng thay đổi — và để bắt những chỗ bị hỏng thêm, mà có một chỗ như vậy.
Đợt 1 — sửa đúng thứ mà LCP đo.
- Đổi ảnh hero từ background trong CSS sang thẻ
<img>thật, để trình duyệt phát hiện nó khi đang đọc HTML, chứ không phải sau khi đọc xong CSS. - Thêm
fetchpriority="high"cho ảnh hero và một<link rel="preload">cho nó trong head, để trình duyệt tải nó trước tiên thay vì theo thứ tự tài liệu. - Ở carousel trang chủ, chỉ để slide đầu nạp ngay và hoãn các slide từ 2 trở đi tới sau khi trang tải xong.
Đợt 2 — thôi chặn lần vẽ đầu tiên.
- Nạp Google Fonts theo kiểu không chặn (
preload+ đổi khionload) để chữ hiện ngay bằng font dự phòng rồi đổi sang font thật khi nó về. - Cắt font Lora từ sáu độ đậm xuống ba. Ba là tất cả những gì thiết kế dùng; ba cái còn lại là dung lượng tải thuần.
Đợt 3 — xoá thứ trang chưa bao giờ dùng.
- Bỏ nạp
wp-emojivàwp-embed(~30 KB JS). - Bỏ nạp CSS front-end của
wp-block-librarycùng khối global styles nội tuyến (~50 KB cả hai). - Bỏ nạp CSS và JS của Contact Form 7 trên mọi trang không có form liên hệ — thêm ~29 KB mà nó đang nạp toàn site chỉ vì một cái form ở một trang.
Chỗ hỏng đáng thừa nhận: mình cũng thử nội tuyến stylesheet lõi của Astra để bỏ một request chặn render. Nó làm hỏng layout ở vài template. Mình trả lại như cũ. Không phải “tối ưu” nào cũng là tối ưu, và nước đi trung thực là đo, thấy thiệt hại, rồi lùi lại — cũng chính là lý do mọi thay đổi ở đây đều được làm và đo riêng từng cái.
Kết quả
Perf LCP A11y
home mobile 63 → 73 7.7s → 4.9s 86 → 96
post mobile 71 → 90 4.7s → 2.9s 97 → 100
page mobile 79 → 98 3.7s → 1.9s 95 → 100Template bài viết đi từ 71 lên 90, và LCP của nó từ 4,7s xuống 2,9s — ra khỏi vùng trượt, vào vùng “cần cải thiện”, đi được gần hết đường tới vùng xanh. Template trang tĩnh đạt 98 với LCP 1,9s. Điểm tiếp cận (accessibility) cũng lên, vì vài thay đổi giống nhau (thẻ <img> thật có alt, tương phản đúng chuẩn, cấu trúc tiêu đề rõ ràng) giúp cả hai điểm cùng lúc. Desktop vốn đã mạnh, chốt ở 99–100 trên toàn bộ.
Con số duy nhất mình chưa sửa trọn, và vì sao
Trang chủ vẫn đang ở 73 điểm trên mobile, LCP quanh 4,9s, và mình muốn nói thẳng chuyện đó chứ không im lặng để nó ra ngoài bảng.
Nguyên nhân là môi trường, không phải code. Blog này chạy trên server phát triển tích hợp của PHP, đơn luồng, phục vụ HTML và từng file CSS, JS lần lượt từng cái một. Ở trang chủ — trang nặng nhất, có carousel — kiểu phục vụ tuần tự đó làm First Contentful Paint dao động từ 1,7s tới 4,0s giữa các lần chạy. Khi FCP nhanh, LCP trang chủ về mức 3,8s và đạt. Độ dao động là do server, không phải do trang.
Mình biết đó là môi trường chứ không phải code vì bằng chứng nằm ngay trong cùng phép đo: trang chủ bản desktop đạt 99 điểm, và template trang nhẹ hơn đạt 98 với LCP 1,9s. Phần việc tối ưu đã xong. Trên hosting production thật — nginx hoặc Apache phục vụ file tĩnh song song qua HTTP/2, có cache và CDN — First Contentful Paint ổn định quanh 1,5s và trang chủ sẽ theo các template khác vượt mốc 90.
Đoạn cuối đó là phần rất nhiều case study bỏ ra ngoài. Một con số hiệu năng chỉ đáng tin đúng bằng mức trung thực về thứ đã tạo ra nó.
Nếu website WordPress của bạn tải chậm, mình nhận kiểm tra tốc độ: đo Lighthouse làm mốc, một danh sách xếp thứ tự những thứ đang thật sự làm bạn mất thời gian, và phần triển khai — kèm số liệu trước–sau bạn tự kiểm chứng được. Liên hệ với mình.