Tốc độ website và Core Web Vitals: sửa gì trước để có tác động thật
Gần như đội ngũ nào cũng từng nhận một bản báo cáo tốc độ đỏ rực rồi tự hỏi nên bắt đầu từ đâu. Bài này sắp xếp lại theo mức tác động thật: chỉ số nào Google thực sự đo, ngưỡng bao nhiêu là đạt, và việc gì đáng sửa trước.
Core Web Vitals hiện gồm ba chỉ số: LCP dưới 2,5 giây, INP dưới 200 mili giây, CLS dưới 0,1. INP đã thay thế FID từ tháng 3 năm 2024. Google chấm bằng dữ liệu người dùng thật, không phải điểm Lighthouse, nên một trang đạt 100 điểm trong phòng thí nghiệm vẫn có thể trượt ngoài thực tế. Thứ tự sửa hợp lý là dọn thứ đang chặn trước, rồi tới ảnh, phông chữ, JavaScript bên thứ ba, bộ nhớ đệm, cuối cùng mới tới các tinh chỉnh nhỏ.
Core Web Vitals gồm những chỉ số nào?
Core Web Vitals là bộ ba chỉ số Google dùng để mô tả trải nghiệm trang từ góc nhìn người dùng. LCP (Largest Contentful Paint) đo thời gian hiển thị khối nội dung lớn nhất trong khung nhìn, thường là ảnh hero hoặc khối chữ tiêu đề, và trả lời câu hỏi "trang có vẻ đã tải xong chưa". INP (Interaction to Next Paint) đo độ trễ phản hồi khi người dùng bấm, chạm hoặc gõ phím, tính tới lúc màn hình vẽ lại; chỉ số này đã chính thức thay thế FID từ tháng 3 năm 2024 và khắt khe hơn vì đo cả vòng đời tương tác chứ không chỉ lần đầu. CLS (Cumulative Layout Shift) đo mức xê dịch bố cục ngoài ý muốn, tức là hiện tượng nội dung nhảy chỗ khi người dùng đang đọc hoặc chuẩn bị bấm.
Ngưỡng "tốt" Google công bố: LCP dưới 2,5 giây, INP dưới 200 mili giây, CLS dưới 0,1. Mức bị xếp là kém: LCP trên 4 giây, INP trên 500 mili giây, CLS trên 0,25. Khoảng ở giữa được gọi là cần cải thiện. Điểm dễ bỏ sót là cách chấm: một trang chỉ được coi là đạt khi phân vị 75 của các lượt truy cập thật nằm trong vùng tốt, nghĩa là 25% người dùng chậm nhất vẫn kéo kết quả xuống.
Nguồn số liệu: ngưỡng do Google công bố cho bộ chỉ số Core Web Vitals.
Dữ liệu phòng thí nghiệm khác dữ liệu người dùng thật thế nào?
Đây là chỗ nhiều đội ngũ mất thời gian nhất. Dữ liệu phòng thí nghiệm (lab) sinh ra từ một lần chạy mô phỏng trên cấu hình máy và mạng giả định, ví dụ báo cáo Lighthouse trong Chrome DevTools. Nó lặp lại được, tiện để chẩn đoán vì chỉ rõ tài nguyên nào chặn hiển thị. Dữ liệu người dùng thật (field) thu từ trình duyệt của người dùng thật, ví dụ báo cáo trải nghiệm người dùng của Chrome, gộp theo cửa sổ 28 ngày và phản ánh đủ loại thiết bị, mạng 3G ở tỉnh lẻ, máy Android tầm thấp, trình chặn quảng cáo, tiện ích mở rộng.
Hệ quả thực tế: điểm Lighthouse 100 không đảm bảo trải nghiệm thật tốt, và ngược lại một trang điểm lab tầm thường vẫn có thể đạt Core Web Vitals nếu người dùng chủ yếu vào bằng máy khỏe và mạng nhanh. Lighthouse cũng không đo được INP theo cách người dùng tương tác thật. Quy tắc gọn: dùng dữ liệu field để quyết định có vấn đề hay không, dùng dữ liệu lab để tìm nguyên nhân.
| Khía cạnh | Dữ liệu lab | Dữ liệu người dùng thật |
|---|---|---|
| Nguồn | Lighthouse, DevTools | Báo cáo trải nghiệm người dùng của Chrome |
| Cách sinh | Mô phỏng 1 lần, cấu hình cố định | Đo từ lượt truy cập thật, gộp 28 ngày |
| Đo được INP | Không đầy đủ | Có |
| Dùng để | Chẩn đoán nguyên nhân | Đánh giá đạt hay chưa đạt |
| Thời gian phản ánh thay đổi | Ngay lập tức | Chậm, phải chờ đủ dữ liệu mới |
Vì dữ liệu field cập nhật theo cửa sổ 28 ngày, sau khi tối ưu cần chờ vài tuần mới thấy chỉ số dịch chuyển. Đừng kết luận sớm sau một ngày.
Vì sao phải sửa cái đang chặn trước rồi mới tối ưu tốc độ?
Tốc độ chỉ có giá trị khi trang được lập chỉ mục và người dùng tới được nội dung. Nếu một trang bị chặn trong robots.txt, dính thẻ noindex sót lại từ bản thử nghiệm, hoặc canonical trỏ nhầm sang trang khác thì trang đó không xuất hiện, và mọi giây tối ưu LCP đều vô nghĩa. Tương tự, một chuỗi chuyển hướng ba bốn chặng vừa làm chậm thêm vài trăm mili giây vừa làm loãng tín hiệu liên kết, còn các đường dẫn 404 nội bộ thì đẩy người dùng ra khỏi phễu ngay khi họ vừa bấm.
Thứ tự hợp lý vì vậy là: dọn khả năng lập chỉ mục, sửa 404 và chuỗi chuyển hướng, kiểm tra sơ đồ trang, rồi mới đụng tới Core Web Vitals. Chi phí nhóm việc này thường thấp, tính bằng giờ, trong khi tác động rõ hơn nhiều so với việc rút LCP từ 2,8 giây xuống 2,4 giây. Có thể tự soát nhanh bằng công cụ audit SEO và GEO miễn phí của Chạm AI trước khi mở bảng đo hiệu năng.
Nguyên nhân phổ biến và cách sửa theo thứ tự ưu tiên
Phần lớn website chậm không vì lý do bí ẩn, mà vì năm nhóm nguyên nhân lặp đi lặp lại. Xử lý theo đúng thứ tự dưới đây thường lấy lại phần lớn hiệu năng mà không cần viết lại giao diện.
- Ảnh quá nặng và không đặt kích thước. Thủ phạm số một của cả LCP lẫn CLS. Cách sửa: nén và chuyển sang định dạng hiện đại, xuất ảnh đúng khung hiển thị thay vì tải ảnh 4000 pixel cho khung 800 pixel, luôn khai báo chiều rộng và chiều cao để trình duyệt giữ chỗ, tải trễ cho ảnh dưới màn hình đầu và tải sớm cho ảnh hero.
- Phông chữ chặn hiển thị. Trình duyệt chờ tải phông rồi mới vẽ chữ, khiến tiêu đề xuất hiện muộn và hỏng LCP, hoặc vẽ bằng phông dự phòng rồi đổi khiến chữ nhảy và hỏng CLS. Cách sửa: giới hạn số biến thể phông, khai báo hiển thị theo chế độ hoán đổi, tải trước tệp phông dùng cho tiêu đề.
- JavaScript của bên thứ ba. Mã theo dõi, chat, thử nghiệm A/B, pixel quảng cáo cộng dồn lại chiếm luồng chính và đẩy INP lên. Cách sửa: kiểm kê toàn bộ đoạn mã đang gắn, xóa cái không ai đọc báo cáo, trì hoãn phần còn lại, chỉ nạp widget nặng khi người dùng cuộn tới.
- Không dùng bộ nhớ đệm. Tài nguyên tĩnh thiếu tiêu đề cache khiến khách quay lại phải tải lại từ đầu. Cách sửa: đặt thời gian lưu dài cho tệp tĩnh có gắn dấu phiên bản, bật bộ nhớ đệm ở tầng máy chủ hoặc mạng phân phối nội dung.
- Quảng cáo hoặc banner chèn vào làm xê dịch bố cục. Banner thông báo, khối quảng cáo, popup cookie chèn thêm chiều cao sau khi trang đã vẽ xong sẽ đẩy nội dung xuống đúng lúc người dùng chuẩn bị bấm. Cách sửa: giữ sẵn vùng có chiều cao cố định cho mọi khối nạp muộn, hoặc cho chúng hiển thị đè.
- Kiểm tra khả năng lập chỉ mục: robots.txt, thẻ noindex, canonical.
- Dọn 404 nội bộ và rút chuỗi chuyển hướng còn tối đa 1 chặng.
- Đọc dữ liệu người dùng thật để biết chỉ số nào đang trượt.
- Sửa ảnh trước, vì tác động lớn nhất trên cả LCP và CLS.
- Xử lý phông chữ và kiểm kê JavaScript bên thứ ba.
- Bật bộ nhớ đệm, giữ chỗ cho banner, rồi chờ 4 tuần đo lại.
Tốc độ ảnh hưởng tới thứ hạng tới mức nào?
Cần nói thẳng để tránh kỳ vọng sai: tốc độ là một trong nhiều yếu tố xếp hạng, không phải yếu tố quyết định. Google mô tả trải nghiệm trang như một tín hiệu phụ trợ, có sức nặng khi các trang cạnh tranh ngang ngửa về mức độ phù hợp với ý định tìm kiếm. Trong thực tế, một trang chậm nhưng trả lời trúng câu hỏi vẫn thường xếp trên một trang nhanh mà nội dung hời hợt. Tối ưu tốc độ không cứu được nội dung yếu.
Thiệt hại thật của trang chậm nằm ở chỗ khác: tỉ lệ rời trang và tỉ lệ chuyển đổi. Người dùng đóng tab trước khi nội dung hiện ra thì thứ hạng có tốt tới đâu cũng không thành đơn hàng. Trong ngành có lưu truyền vài con số kiểu mỗi giây chậm làm mất một tỉ lệ doanh thu nhất định, nhưng đó là con số được trích dẫn rộng rãi mà không gắn điều kiện đo cụ thể, nên tốt hơn là diễn đạt định tính: trang càng chậm, tỉ lệ bỏ ngang càng cao, mức thiệt hại phụ thuộc vào ngành và giá trị đơn hàng của chính bạn. Cách kiểm chứng đúng là so sánh dữ liệu website trước và sau khi tối ưu.
Cũng cần tách bạch phạm vi: đây là mảng SEO kỹ thuật truyền thống, phục vụ trình thu thập dữ liệu và trải nghiệm trên trình duyệt. Tối ưu để được các công cụ AI trích dẫn là bài toán khác, có tiêu chí và cách đo riêng, bàn trong bài GEO vs SEO: nên đầu tư cái nào trước. Đừng gộp chỉ số của hai hướng vào cùng một báo cáo.
Câu hỏi thường gặp
Core Web Vitals gồm những chỉ số nào và ngưỡng tốt là bao nhiêu?
Bộ chỉ số hiện hành gồm ba mục. LCP đo tốc độ hiển thị khối nội dung lớn nhất, ngưỡng tốt là dưới 2,5 giây. INP đo độ trễ phản hồi khi tương tác, ngưỡng tốt là dưới 200 mili giây. CLS đo mức xê dịch bố cục, ngưỡng tốt là dưới 0,1. Google chấm theo phân vị 75 của lượt truy cập thật.
Điểm Lighthouse 100 có nghĩa là website đã nhanh chưa?
Chưa chắc. Lighthouse là dữ liệu phòng thí nghiệm, chạy mô phỏng trên một cấu hình giả định. Google đánh giá bằng dữ liệu người dùng thật thu từ báo cáo trải nghiệm người dùng của Chrome, gộp trong 28 ngày. Điểm lab dùng để chẩn đoán nguyên nhân, dữ liệu field mới là kết quả được tính.
Tốc độ website ảnh hưởng tới thứ hạng Google nhiều không?
Tốc độ là một trong nhiều yếu tố xếp hạng, không phải yếu tố quyết định. Trang chậm nhưng đúng ý định tìm kiếm vẫn có thể xếp trên trang nhanh mà nội dung yếu. Thiệt hại rõ nhất nằm ở tỉ lệ rời trang và tỉ lệ chuyển đổi, tức mất khách ngay cả khi thứ hạng chưa đổi.