Tối ưu PageSpeed cho WordPress — cái gì thật sự đổi trong 2026

Mỗi lần Google nhúc nhích một chút là lại có một đợt bài viết tiếng Việt lẫn tiếng Anh giật tít "Google đổi luật Core Web Vitals". Tôi đọc mấy bài đó rồi đối chiếu với tài liệu gốc: phần lớn con số trong đó không tồn tại ở đâu cả.

Đổi thật trong 2026 có hai thứ: Lighthouse 13 thay audit bằng insights, và PageSpeed Insights thêm mục Agentic Browsing. Ngưỡng Core Web Vitals thì không đổi.

Lighthouse 13 thay audit bằng insights, xoá 8 audit cũ

Lighthouse 13 thay hệ thống audit cũ bằng insights, cùng bộ phân tích với tab Performance của Chrome DevTools. Thay vì một danh sách audit rời rạc, bạn nhận các nhóm chẩn đoán: LCP Discovery & Phases, Render Blocking, Third-Parties, Network Dependency Tree.

Đi kèm là việc xoá hẳn tám audit cũ: First Meaningful Paint, Font Size, No Document Write, Offscreen Images, Preload Fonts, Third-Party Facades, Uses Passive Event Listeners, Uses Rel Preload. Quy trình nào có checklist bám theo tên audit thì phần đó cần viết lại. Con số tám lấy từ release notes v13.0.0; bài blog của Chrome chỉ kể sáu cái thuộc nhóm Performance, thiếu Font Size và Preload Fonts.

Mục mới trong PageSpeed Insights: Agentic Browsing

Lighthouse 13.3.0 ra ngày 7/5/2026 bổ sung một hạng mục mới bên cạnh Performance, Accessibility, Best Practices và SEO: Agentic Browsing, đo mức độ website sẵn sàng cho các tác nhân AI đọc và thao tác.

Vài điểm cần nắm cho đúng:

• Hạng mục này không chấm 0–100. Tài liệu chấm điểm ghi rõ nó trả về tỷ lệ dạng phân số: qua bao nhiêu mục trên tổng số
• Nó nằm riêng, không cộng vào điểm Performance quen thuộc
• Google đánh dấu rõ hạng mục này và phần WebMCP là thử nghiệm, dựa trên các chuẩn còn ở dạng đề xuất
• Cần Chrome 150 trở lên; riêng phần WebMCP còn phải đăng ký origin trial
• Một trong ba mục kiểm mặc định là sự hiện diện của llms.txt ở gốc tên miền. Chuẩn này còn ở dạng đề xuất, chưa phải thứ bắt buộc phải có

Thấy mục này đỏ cũng đừng hoảng. Nó chưa phải tín hiệu xếp hạng và chưa phải chuẩn chính thức.

Ngưỡng Core Web Vitals không thay đổi

Ba ngưỡng trong tài liệu Core Web Vitals vẫn nguyên như cũ, đo ở phân vị 75 của người dùng thật, tách riêng mobile và desktop:

Thay đổi lớn gần nhất về chỉ số là INP thay FID, và chuyện đó diễn ra ngày 12/3/2024, không phải 2026.

Điểm Lighthouse (lab) khác dữ liệu CrUX (field)

Đây là chỗ tôi phải giải thích lại nhiều nhất với khách. PageSpeed Insights hiển thị hai khối dữ liệu trông rất giống nhau:

• Dữ liệu thực tế (field) lấy từ Chrome User Experience Report, gộp trải nghiệm của người dùng thật trong 28 ngày gần nhất. Đây mới là thứ liên quan tới xếp hạng.
• Dữ liệu phòng lab là một lượt chạy Lighthouse mô phỏng máy tầm trung (Moto G Power, đổi từ Moto G4 kể từ Lighthouse 10) trên mạng di động chậm. Con số 0–100 màu mè nằm ở khối này.

Điểm lab dùng để chẩn đoán, không phải để báo cáo. Một trang đạt 95 điểm lab mà dữ liệu thực tế vẫn đỏ là chuyện bình thường, vì khách của bạn dùng máy yếu hơn, mạng tệ hơn, và có thêm cả chục tab đang mở.

Trọng số điểm Performance: TBT 30%, LCP 25%, CLS 25%

Điểm Performance không chia đều cho các chỉ số:

Ba chỉ số đầu chiếm 80% điểm. Đây là lý do việc nén thêm vài KB CSS gần như không làm điểm thay đổi, trong khi gỡ một plugin JavaScript nặng có thể nhảy hai chục điểm.

TTFB: WordPress thua từ vạch xuất phát

Trước khi bàn tới ảnh hay JavaScript, hãy nhìn thời gian phản hồi byte đầu tiên. WordPress phải khởi động PHP, gọi database, chạy qua toàn bộ hook của theme và plugin cho mỗi lượt truy cập, trừ khi bạn chặn nó lại.

• Cache toàn trang ở tầng server: NGINX FastCGI cache hoặc LiteSpeed cache. Cache bằng plugin PHP vẫn phải khởi động PHP mới trả được cache, chậm hơn hẳn
• Object cache bằng Redis cho phần không cache được: trang giỏ hàng, tài khoản, kết quả tìm kiếm
• PHP 8.4 trở lên, OPcache bật sẵn. 8.3 đã hết hỗ trợ bảo mật từ 31/12/2025, mà ngoài kia vẫn còn nhiều site chạy 7.4
• Hosting đặt gần người dùng. Khách ở Việt Nam mà server ở Mỹ thì riêng độ trễ mạng đã ăn mất vài trăm mili giây, không kỹ thuật nào bù lại được
• CDN cho tài nguyên tĩnh, và cho cả HTML nếu trang không cá nhân hoá

Với dự án website catalogue B2B có hàng nghìn sản phẩm, phần lớn thời gian tối ưu đổ vào đúng tầng này chứ không phải front-end.

LCP: gần như luôn là ảnh hero/slider/banner

Trên website WordPress điển hình, phần tử LCP là ảnh hero/slider/banner đầu trang. Vài lỗi sai kinh điển dev thường dính phải:

• Đừng lazy-load ảnh LCP. Nhiều plugin WordPress bật lazy-load cho tất cả ảnh, kể cả ảnh hiện ngay trong khung nhìn đầu tiên, thành ra tự làm chậm chính chỉ số đang muốn cải thiện
• Thêm fetchpriority="high" cho ảnh hero/slider/banner để trình duyệt tải nó trước
• Cắt ảnh đúng kích thước hiển thị. Ảnh 3000px hiển thị trong khung 800px là lãng phí băng thông của khách
• Dùng AVIF hoặc WebP, giữ JPEG làm dự phòng
• Font tự host, kèm font-display: swap và preload đúng file thật sự dùng. Link CDN của Google Fonts thêm một kết nối tới tên miền khác

Ảnh nằm trong slider của page builder thì LCP còn phải đợi JavaScript của slider chạy xong. Cách sửa nhanh nhất thường là bỏ slider: một ảnh tĩnh ở trang chủ tải nhanh hơn hẳn.

CLS: gần như luôn là thiếu kích thước

• Mọi ảnh phải có width và height trong HTML để trình duyệt giữ chỗ trước khi ảnh tải xong
• Đặt chiều cao cố định cho quảng cáo, iframe, embed block. Chúng tải muộn và đẩy toàn bộ nội dung xuống
• Đừng chèn banner, thanh thông báo hay popup cookie phía trên nội dung sau khi trang đã vẽ
• Font dự phòng phải cùng kích cỡ với font chính, dùng size-adjust để chữ không nhảy khi font thật tải xong

CLS dễ sửa nhất trong ba chỉ số mà vẫn chiếm 25% điểm. Sửa nó trước.

INP: chỗ WordPress thiệt thòi nhất

INP đo khoảng thời gian từ lúc người dùng bấm tới lúc màn hình phản hồi. Main thread đang bận chạy JavaScript thì cú bấm phải xếp hàng chờ.

WordPress hay dính chỉ số này vì mỗi plugin lại nạp thêm JavaScript của riêng nó, và page builder thì nạp cả bộ thư viện dù trang chỉ dùng một block.

• Check các plugin. Mỗi plugin nạp bao nhiêu JavaScript, có thật sự cần trên mọi trang không. Nạp có điều kiện theo từng trang tiết kiệm rất nhiều
• Trì hoãn script không thiết yếu tới lúc người dùng thao tác lần đầu: chat widget, pixel quảng cáo, bản đồ nhúng
• Xem lại tag của bên thứ ba. Google Tag Manager với hai chục thẻ bên trong là một trong những thủ phạm phổ biến nhất
• Chia nhỏ tác vụ dài và nhường ưu tiên cho trình duyệt thay vì chạy một mạch
• Bỏ jQuery nếu theme không thật sự cần. Nhiều theme nạp nó chỉ để chạy một hiệu ứng sticky, scroll hay "go to top"

Đây cũng là lý do tôi khuyên khách viết theme riêng thay vì mua theme đa năng: theme bán sẵn phải phục vụ hàng trăm ngành nên nạp mọi thứ, kể cả phần trang của bạn không dùng.

Thứ tự tối ưu: TTFB, CLS, LCP, rồi INP

1. Đo dữ liệu thực tế trước, đừng đo lab. Nếu CrUX chưa đủ dữ liệu thì trang còn quá ít truy cập để lo chuyện này
2. Sửa TTFB: cache tầng server, PHP mới, hosting đúng khu vực
3. Sửa CLS: rẻ nhất, nhanh nhất, 25% điểm
4. Sửa LCP: ảnh hero, font, thứ tự tải
5. Sửa INP: kiểm kê JavaScript, phần tốn công nhất
6. Đo lại sau 28 ngày, vì dữ liệu thực tế tính theo mốc 28 ngày

Đo bằng PageSpeed Insights, Search Console và web-vitals

PageSpeed Insights cho từng trang, báo cáo Core Web Vitals trong Search Console cho toàn site, và nếu muốn thấy vấn đề trước khi Google thấy thì gắn thư viện web-vitals để lấy số liệu từ chính khách của bạn. Cách dựng dashboard giám sát website tự động theo hướng đó tôi viết ở bài riêng.

Điểm PageSpeed 100 có đáng theo đuổi không

Không đáng. Tối ưu từ 50 lên 90 điểm là chỗ khách và người dùng cảm nhận được: trang tải nhanh hơn, bấm là chạy, chữ không đứng chờ. Từ 95 lên 100 thường phải hy sinh thứ bắt buộc phải có trên website, như bỏ ảnh, bỏ công cụ đo lường, bỏ tính năng, để đổi lấy mấy điểm không ai ngoài bạn nhìn thấy.

Ngưỡng cần quan tâm là dữ liệu thực tế xanh cả ba chỉ số. Con số 100 màu xanh lá trong ảnh chụp màn hình là thứ để khoe, không phải mục tiêu kinh doanh.