Giải thích Core Web Vitals: LCP, INP và CLS bằng ngôn ngữ dễ hiểu

Core Web Vitals không phải là bài kiểm tra tính cách cho website của bạn

Core Web Vitals thường bị xem như một bảng điểm bí ẩn. Một trang nhận một con số màu đỏ, ai đó đăng ảnh chụp màn hình lên Slack, rồi cả nhóm bắt đầu tranh luận về các framework JavaScript.

Điều đó không thật sự hữu ích.

Cách tốt hơn để nghĩ về Core Web Vitals đơn giản hơn: đó là ba phép đo cho biết một trang có mang lại cảm giác dùng được với một người thật trên một thiết bị thật hay không. Chúng không bao quát mọi khía cạnh của hiệu năng, khả năng tiếp cận hay chất lượng. Nhưng chúng bắt được ba nguồn gây khó chịu phổ biến:

• Nội dung chính mất quá lâu để xuất hiện.
• Trang phản ứng chậm khi người dùng cố làm điều gì đó.
• Bố cục nhảy dịch trong khi người dùng đang đọc hoặc chạm.

Đó là ba Core Web Vitals: LCP, INP và CLS.

Google dùng chúng như một phần của các tín hiệu trải nghiệm trang, nhưng góc nhìn SEO không phải là lý do tốt nhất để quan tâm. Lý do tốt hơn là các trang chậm, hay nhảy và thiếu phản hồi làm lãng phí thời gian của người dùng. Chúng cũng thường chuyển đổi kém hơn, hỗ trợ kém hơn và xuống cấp nhanh hơn theo thời gian.

Ba chỉ số trong mỗi câu ngắn gọn

Trước khi đi vào chi tiết, đây là phiên bản dễ hiểu:

• LCP, hay Largest Contentful Paint, đo thời gian cần để nội dung chính đang hiển thị tải xong.
• INP, hay Interaction to Next Paint, đo tốc độ trang phản hồi với các tương tác của người dùng trong suốt lượt truy cập.
• CLS, hay Cumulative Layout Shift, đo mức độ trang di chuyển ngoài dự kiến.

Các ngưỡng thường dùng là:

| Metric | Good | Needs improvement | Poor | |---|---:|---:|---:| | LCP | 2.5s hoặc nhanh hơn | 2.5s–4.0s | Trên 4.0s | | INP | 200ms hoặc nhanh hơn | 200ms–500ms | Trên 500ms | | CLS | 0.1 hoặc thấp hơn | 0.1–0.25 | Trên 0.25 |

Những con số này thường được đánh giá ở phân vị thứ 75 của các lượt truy cập người dùng thực. Điều đó quan trọng. Bạn không cố tạo ra một lần chạy thử hoàn hảo trong phòng thí nghiệm. Bạn đang cố làm cho trải nghiệm tốt với phần lớn người dùng, bao gồm cả những người dùng điện thoại chậm hơn và mạng kém ổn định hơn.

Nếu bạn đang nhìn một báo cáo tự động và không chắc nên bắt đầu từ đâu, hãy tách chẩn đoán khỏi hoảng loạn. Chúng tôi có một hướng dẫn riêng về cách đọc báo cáo Lighthouse mà không hoảng loạn, trình bày quy trình đó chi tiết hơn.

LCP: khi nào trang tạo cảm giác đã tải xong?

Largest Contentful Paint đo thời gian render của phần tử nội dung hiển thị lớn nhất trong viewport. Trên thực tế, đó thường là:

• một ảnh hero,
• một tiêu đề lớn,
• một ảnh bài viết nổi bật,
• một ảnh sản phẩm,
• một khối văn bản lớn.

LCP không hỏi khi nào mọi script, tracking pixel và ảnh bên dưới màn hình đầu tiên tải xong. Nó hỏi: khi nào thứ chính mà người dùng đến để xem trở nên hiển thị?

Điều đó khiến LCP trở thành một chỉ số gần với con người hơn so với “thời gian tải trang” kiểu cũ. Một trang có thể hoàn tất tải về mặt kỹ thuật khá muộn nhưng vẫn tạo cảm giác nhanh nếu nội dung chính xuất hiện sớm. Điều ngược lại cũng đúng: một trang có thể kích hoạt sự kiện load trong khi khu vực hero vẫn trống, bị làm mờ hoặc bị chặn bởi độ trễ render.

Các nguyên nhân phổ biến khiến LCP kém

Phần lớn vấn đề LCP tệ đến từ vài nơi khá dễ đoán:

1. Phản hồi máy chủ chậm

Nếu tài liệu HTML đến muộn, mọi thứ khác cũng bắt đầu muộn.

1. CSS hoặc JavaScript chặn render

Trình duyệt đã có nội dung nhưng chưa thể vẽ nội dung đó.

1. Ảnh hero chưa được tối ưu

Phần tử lớn nhất quá nặng, sai định dạng, không được ưu tiên, hoặc bị lazy-load do nhầm lẫn.

1. Web fonts làm chậm việc render văn bản

Một tiêu đề lớn có thể là phần tử LCP, và việc tải font có thể làm chậm hoặc thay đổi thị giác của nó.

1. Độ trễ render phía client

Nếu trang cần một bundle JavaScript lớn trước khi có thể hiển thị nội dung có ý nghĩa, LCP sẽ bị ảnh hưởng.

Cách cải thiện LCP

Hãy bắt đầu với chính phần tử LCP thực tế. Đừng tối ưu các tài nguyên ngẫu nhiên cho đến khi bạn biết trình duyệt đang đo gì.

Các cách sửa thực tế gồm:

• Phục vụ HTML nhanh: cache khi phù hợp, giảm công việc backend, tránh redirect chậm.
• Tối ưu ảnh LCP: dùng đúng kích thước, mức nén và định dạng.
• Không lazy-load ảnh hero nằm above-the-fold.
• Dùng fetchpriority="high" một cách cẩn trọng cho ảnh chính khi nó thực sự là ưu tiên.
• Inline critical CSS chỉ khi việc đó giảm độ trễ render một cách đáng kể.
• Giảm JavaScript cần thiết trước lần render có ý nghĩa đầu tiên.
• Dùng font-display: swap hoặc một chiến lược font có chủ đích khác.

Ảnh và font là thủ phạm thường gặp. Với ảnh, đánh đổi không chỉ là “tệp nhỏ là tốt”. Lựa chọn định dạng, công sức mã hóa và hỗ trợ trình duyệt đều quan trọng, đó là lý do chúng tôi duy trì một cây quyết định thực tế cho khi nào AVIF vượt WebP và khi nào thì không. Với các trang nhiều chữ, web fonts vẫn là một trong những cải thiện hiệu năng dễ nhất vì nhiều website gửi nhiều tệp font hơn mức chúng thực sự dùng.

INP: trang có phản hồi khi được chạm vào không?

Interaction to Next Paint đo khả năng phản hồi. Cụ thể hơn, nó xem xét độ trễ giữa một tương tác của người dùng và lần cập nhật thị giác tiếp theo sau khi trình duyệt đã xử lý tương tác đó.

Các tương tác bao gồm những việc như:

• nhấp vào một nút,
• chạm vào một menu,
• chọn một checkbox,
• nhập vào một trường biểu mẫu,
• mở một accordion.

INP đã thay thế First Input Delay trong vai trò Core Web Vital vào năm 2024. Đó là một thay đổi tốt. First Input Delay chỉ xem xét tương tác đầu tiên. INP rộng hơn: nó xét các tương tác trong suốt lượt truy cập trang và báo cáo một tương tác có độ trễ cao làm điểm khả năng phản hồi của trang.

Nói đơn giản: INP phát hiện những trang trông như đã tải xong nhưng lại có cảm giác bị kẹt.

Có lẽ bạn đã từng dùng một trang như vậy. Nó có vẻ sẵn sàng. Bạn chạm vào menu. Không có gì xảy ra trong nửa giây. Bạn chạm lại. Rồi hai việc xảy ra cùng lúc. Đó là vấn đề INP.

Các nguyên nhân phổ biến khiến INP kém

INP thường là vấn đề của main thread. Trình duyệt muốn phản hồi, nhưng JavaScript, công việc render hoặc tính toán layout đang cản đường.

Các nguyên nhân điển hình gồm:

• bundle JavaScript lớn,
• event handler tốn kém,
• công việc hydration trên các ứng dụng render phía client,
• script bên thứ ba cạnh tranh main thread,
• tác vụ chạy lâu sau khi tải trang,
• cập nhật DOM phức tạp do các tương tác nhỏ kích hoạt,
• layout thrashing, khi code liên tục đọc và ghi các giá trị layout.

Marketing tags, analytics, chat widgets và consent banners đều có thể góp phần. Điều này không có nghĩa là “xóa mọi thứ”. Nó có nghĩa là mỗi script trên trang đều có chi phí, và độ trễ tương tác thường là nơi chi phí đó trở nên nhìn thấy được.

Cách cải thiện INP

Cải thiện INP không nằm ở một thuộc tính thần kỳ duy nhất, mà nằm ở việc giảm tranh chấp trên main thread.

Các hướng tiếp cận hữu ích gồm:

• Chia các tác vụ JavaScript dài thành những phần nhỏ hơn.
• Trì hoãn công việc không thiết yếu cho đến sau khi trang đã dùng được.
• Loại bỏ JavaScript không dùng thay vì chỉ minify nó.
• Giữ event handler nhỏ và dễ dự đoán.
• Tránh re-render các phần lớn của giao diện chỉ vì những thay đổi trạng thái nhỏ.
• Dùng CSS cho các trạng thái thị giác đơn giản khi có thể.
• Kiểm tra script bên thứ ba và chỉ tải chúng ở nơi cần thiết.

Cũng hãy nhìn vào thiết kế tương tác. Một nút cung cấp phản hồi thị giác ngay lập tức có thể tạo cảm giác phản hồi tốt hơn, ngay cả khi công việc tiếp theo mất nhiều thời gian hơn. Đó không phải là thứ thay thế cho hiệu năng, nhưng là một phần của kỹ thuật giao diện tốt. Checklist của chúng tôi về các nút web có khả năng tiếp cận có phần giao nhau với điều này: trạng thái rõ ràng, ngữ nghĩa đúng và hành vi dễ dự đoán giúp ích cho cả người dùng lẫn trình duyệt.

CLS: trang có ở yên nơi người dùng kỳ vọng không?

Cumulative Layout Shift đo chuyển động ngoài dự kiến của các phần tử đang hiển thị. Nếu người dùng bắt đầu đọc một đoạn văn và một quảng cáo, ảnh hoặc banner tải phía trên nó, đẩy văn bản xuống, điều đó sẽ góp vào CLS.

CLS không được đo bằng giây. Nó là một điểm số dựa trên lượng nội dung đã di chuyển và quãng đường nó di chuyển. Càng thấp càng tốt.

Từ khóa là ngoài dự kiến. Các thay đổi layout do hành động của người dùng gây ra thường không được tính theo cùng cách. Nếu ai đó chạm vào “hiển thị thêm” và nội dung mở rộng, đó là điều được kỳ vọng. Nếu một newsletter banner xuất hiện ở đầu trang sau ba giây và đẩy mọi thứ xuống, thì không.

Các nguyên nhân phổ biến khiến CLS kém

Các lỗi CLS thường rất đời thường:

• ảnh không có thuộc tính width và height,
• quảng cáo hoặc embed không có khoảng trống được dành trước,
• cookie banner được chèn phía trên nội dung,
• web fonts thay thế với metrics khác,
• thanh khuyến mãi tải muộn,
• nội dung được chèn động gần đầu trang.

Cách sửa thường là dành trước không gian trước khi nội dung đến. Trình duyệt nên biết hình dạng của trang càng sớm càng tốt.

Cách cải thiện CLS

Hãy bắt đầu với các dịch chuyển nhìn thấy được. Xem bản ghi hoặc dùng công cụ trình duyệt để xác định phần tử nào di chuyển.

Sau đó áp dụng những cách sửa nhàm chán:

• Thêm thuộc tính width và height rõ ràng cho ảnh.
• Dùng CSS aspect-ratio cho các container media responsive.
• Dành trước không gian cố định hoặc tối thiểu cho quảng cáo, embed và iframe.
• Tránh chèn banner phía trên nội dung hiện có sau khi tải.
• Chọn font fallback có metrics tương tự font cuối cùng.
• Tránh animation làm thay đổi các thuộc tính layout như top, left, width hoặc height; ưu tiên transform.

CLS là một trong số ít chỉ số hiệu năng nơi kỷ luật thắng sự khéo léo. Nếu trang có các hộp ổn định, nó thường đạt điểm tốt.

Field data và lab data đều hữu ích, nhưng chúng trả lời các câu hỏi khác nhau

Một nguồn gây nhầm lẫn phổ biến là các công cụ khác nhau hiển thị các con số khác nhau. Điều đó là bình thường.

Field data đến từ người dùng thực. Nó phản ánh thiết bị, mạng, vị trí và điều kiện trình duyệt thực tế. Chrome User Experience Report của Google là một ví dụ về field data.

Lab data đến từ một môi trường kiểm thử được kiểm soát. Lighthouse là ví dụ quen thuộc. Nó có thể lặp lại và hữu ích để debug, nhưng không giống với trải nghiệm sống thực của người dùng bạn.

Dùng field data để quyết định liệu người dùng có đang gặp vấn đề thật hay không. Dùng lab data để tái hiện và debug vấn đề đó.

Cũng cần nhớ rằng Core Web Vitals thường được đánh giá theo từng URL hoặc nhóm URL, chứ không phải như một thuộc tính trừu tượng duy nhất của thương hiệu bạn. Trang chủ, bài blog, trang giá và checkout có thể có những nút thắt rất khác nhau.

Một thứ tự công việc hợp lý

Nếu cả ba chỉ số đều kém, cám dỗ là bắt đầu ở mọi nơi. Hãy cưỡng lại điều đó.

Một thứ tự thực tế là:

1. Sửa các vấn đề CLS rõ ràng trước

Thiếu kích thước ảnh và banner không ổn định thường là những cải thiện nhanh.

1. Cải thiện LCP cho các template quan trọng

Tập trung vào các trang quan trọng: trang sản phẩm, landing page, bài viết, luồng đăng ký.

1. Điều tra INP bằng các tương tác thực

Nhấp vào những thứ người dùng thực sự nhấp. Menu, bộ lọc, biểu mẫu và điều khiển checkout thường hé lộ nhiều hơn so với trace tải ban đầu.

1. Kiểm tra script bên thứ ba

Giữ lại những script chứng minh được chi phí của chúng là xứng đáng. Xóa hoặc trì hoãn những script không làm được điều đó.

1. Đặt performance budget

Nếu không có budget, các cải thiện hiệu năng sẽ suy giảm. Script, ảnh và component thiết kế mới sẽ âm thầm đảo ngược công sức đã làm.

Điểm quan trọng: đừng tối ưu để lấy huy hiệu. Hãy tối ưu cho hành trình người dùng. Một cải thiện điểm số nhỏ trên trang ít lưu lượng có thể kém quan trọng hơn một tương tác checkout nhanh hơn nhiều dù chưa hoàn hảo.

<!-- tool-cta:start -->

💡 Thử cách này: Vì LCP thường là vấn đề về hình ảnh, hãy thu nhỏ hero asset của bạn bằng Image Compressor như một chiến thắng dễ dàng đầu tiên.

<!-- tool-cta:end -->

Core Web Vitals không cho bạn biết điều gì

Core Web Vitals hữu ích, nhưng không đầy đủ.

Chúng không cho bạn biết nội dung của bạn có tốt hay không. Chúng không cho bạn biết điều hướng của bạn có hợp lý hay không. Chúng không đảm bảo khả năng tiếp cận. Chúng không đo quyền riêng tư, bảo mật, niềm tin, khả năng đọc hoặc liệu trang có trả lời câu hỏi của người dùng hay không.

Chúng cũng không thay thế phán đoán. Một trang có thể đạt Core Web Vitals nhưng vẫn gây khó chịu. Một ứng dụng phức tạp có thể trượt một ngưỡng trong khi vẫn được xây dựng có trách nhiệm trong các ràng buộc của nó.

Hãy xem LCP, INP và CLS như chuông báo khói. Khi chúng kêu, hãy điều tra. Khi chúng im lặng, hãy tiếp tục bảo trì tòa nhà.