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ả.

Bài này ghi lại hai thứ: cái thực sự đổi trong 2026, và thứ tự việc cần làm cho một website WordPress.

Google nâng cấp Lighthouse 13

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ác nhóm chẩn đoán như 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. Nếu quy trình của bạn có checklist bám theo tên audit, phần đó cần viết lại.

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

Đây mới là thứ đáng chú ý. Lighthouse 13.3.0 ra ngày 7/5/2026 bổ sung một hạng mục hoàn toàn 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. Nó hiện tỷ lệ dạng phân số: bao nhiêu mục kiểm tra được thông qua
• Nó không ảnh hưởng tới điểm Performance quen thuộc
• Google đánh dấu rõ 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
• Thiếu file llms.txt thì mục đó ghi Not Applicable, không phải điểm trừ — file này hiện là tuỳ chọn

Nói cách khá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à cũng chưa phải chuẩn chính thức.

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

Ba ngưỡng 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 từ tháng 3/2024, không phải 2026.

Điểm Lighthouse và dữ liệu xếp hạng là hai thứ khác nhau, ngừng đánh đồng!

Đây là hiểu lầm tốn công giải thích nhất mà tôi gặp ở khách hàng.

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 — một lượt chạy Lighthouse mô phỏng máy tầm trung (Moto G4) 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 có thể đạt 95 điểm lab mà dữ liệu thực tế vẫn đỏ, 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 cái tab đang mở.

Trọng số: đã sửa đúng chỗ

Đ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.3 trở lên, OPcache bật sẵn. Vẫn còn rất nhiều site chạy PHP 7.4 đã hết hạn hỗ trợ
• 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. Rất 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. Dùng link CDN của Google Fonts lại thêm một kết nối tới tên miền khác

Nếu ảnh nằm trong slider của page builder, LCP còn phải đợi JavaScript của slider chạy xong. Trường hợp đó cách sửa nhanh nhất thường là bỏ slider — trang chủ có một ảnh tĩnh chạy nhanh hơn và cũng chuyển đổi tốt 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 là chỉ số dễ sửa nhất trong ba chỉ số, và cũng là chỉ số 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. Nếu main thread đang bận chạy JavaScript, 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 thường khuyên khách chọn theme custom riêng thay vì mua theme đa năng về cài đặt: theme bán sẵn phải hỗ trợ nhiều lĩnh vực, phục vụ nhiều đối tượng để tạo lợi thế cạnh tranh, nên phải nạp mọi thứ.

Thứ tự tôi làm

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, đây là 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 gì

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. Tôi có viết bài cách dựng dashboard giám sát website theo hướng đó.

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

Không.

Tối ưu từ 50 lên 90 điểm là nơi khách hàng và người dùng cảm nhận được: trang tải nhanh hơn, bấm là chạy, chữ không "loading..". Mốc điểm từ 95 lên 100 thường phải hy sinh những thứ bắt buộc phải có trên Website — bỏ ảnh, bỏ công cụ đo lường, bỏ tính năng — để đổi lấy mấy điểm 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, up facebook, không phải mục tiêu kinh doanh.