Core Web Vitals: Tối ưu LCP, CLS và INP cho website

Ba chỉ số cần theo dõi là LCP cho tốc độ xuất hiện nội dung chính, CLS cho độ ổn định của bố cục và INP cho độ phản hồi khi người dùng tương tác. Khi hiểu chúng hoạt động thế nào trong trình duyệt, bạn sẽ biết cần ưu tiên phần nào trước khi đầu tư tối ưu website.

Ba chỉ số Core Web Vitals đo điều gì?

Chỉ số	Trải nghiệm phản ánh	Mục tiêu nên hướng tới
LCP	Nội dung lớn và quan trọng nhất xuất hiện nhanh đến đâu	Dưới 2,5 giây
CLS	Bố cục có bị nhảy bất ngờ khi tải nội dung hay không	Dưới 0,1
INP	Giao diện phản hồi nhanh thế nào sau thao tác bấm, chạm hoặc gõ	Dưới 200 mili giây

Ba số liệu này không thay thế toàn bộ hoạt động đo hiệu năng, nhưng chúng tạo ra một ngôn ngữ chung giữa chủ doanh nghiệp, đội marketing và đội kỹ thuật. Bạn không chỉ hỏi website có nhanh hay không, mà có thể hỏi chính xác: nội dung chính có đến sớm không, giao diện có làm khách hàng bấm nhầm không, và thao tác có bị chậm hay không.

LCP: Đưa nội dung quan trọng nhất lên màn hình sớm hơn

LCP, viết tắt của Largest Contentful Paint, ghi nhận thời điểm phần tử hiển thị lớn nhất trong vùng màn hình hoàn tất việc hiển thị. Phần tử đó thường là ảnh giới thiệu đầu trang, tiêu đề lớn hoặc khối nội dung chính của trang bán hàng.

Điểm khác biệt quan trọng là LCP không quan tâm đơn thuần lúc website bắt đầu tải. Nó hỏi một câu hữu ích hơn: khi nào khách hàng thực sự nhìn thấy phần nội dung chính mà họ cần?

Vì sao JavaScript có thể làm LCP chậm?

Một lỗi phổ biến là đặt tệp JavaScript tải chậm trong phần đầu trang mà không có cơ chế trì hoãn. Trình duyệt phải dừng việc phân tích HTML để tải và chạy tệp đó, bởi JavaScript có khả năng thêm, xóa hoặc thay đổi cấu trúc DOM.

Hệ quả là trình duyệt chưa thể đi đến vị trí chứa ảnh đầu trang. Yêu cầu tải ảnh quan trọng chỉ bắt đầu sau khi JavaScript chạy xong, khiến LCP xấu đi dù bản thân ảnh không có vấn đề.

Cách ưu tiên phần tử LCP

• Trì hoãn script không quan trọng bằng thuộc tính defer. Trình duyệt có thể tiếp tục phân tích HTML và xây dựng DOM trong khi tải script song song. Script chỉ chạy sau khi quá trình phân tích HTML hoàn tất.
• Tải trước ảnh đầu trang bằng preload. Cách này cho trình duyệt biết cần gửi yêu cầu tải ảnh quan trọng càng sớm càng tốt.
• Đặt mức ưu tiên tải cao cho ảnh chính. Thuộc tính ưu tiên tải cao giúp trình duyệt hiểu đây là tài nguyên quan trọng cho trải nghiệm đầu tiên.
• Trì hoãn mọi tài nguyên chưa cần thiết. Các nội dung không quyết định trải nghiệm ban đầu không nên cạnh tranh với ảnh, tiêu đề hoặc khối nội dung chính.

Trong ví dụ thực tế, chỉ cần chuyển script chặn sang defer, kết hợp preload và ưu tiên tải cao cho ảnh đầu trang, nội dung chính đã xuất hiện sớm hơn đáng kể. Nguyên tắc là rất đơn giản: đừng để công việc phụ ngăn trình duyệt tải phần tạo ra giá trị đầu tiên cho khách hàng.

CLS: Giữ bố cục ổn định khi nội dung tải dần

CLS, hay Cumulative Layout Shift, đo tổng mức độ dịch chuyển bất ngờ của nội dung đang hiển thị. Đây là tình huống bạn đang đọc một đoạn chữ, rồi hình ảnh hoặc khối nội dung phía trên tải xong và đẩy toàn bộ trang xuống dưới.

Sự dịch chuyển đó không chỉ gây khó chịu. Nó có thể làm khách hàng bấm nhầm nút, mất vị trí đang đọc hoặc cảm nhận website thiếu tin cậy.

Nguyên nhân thường gặp của layout shift

Hình ảnh không khai báo chiều rộng và chiều cao là nguyên nhân điển hình. Khi HTML được đọc lần đầu, trình duyệt chưa biết ảnh sẽ chiếm bao nhiêu không gian nên không thể giữ sẵn chỗ trống.

Khi ảnh tải xong, nó xuất hiện với kích thước thật và đẩy phần nội dung bên dưới xuống. Mỗi lần dịch chuyển như vậy đều đóng góp vào điểm CLS, đặc biệt khi nó xảy ra ngay trong vùng màn hình đang hiển thị.

Cách giữ giao diện không bị nhảy

• Khai báo width và height cho ảnh. Trình duyệt sẽ tính được tỷ lệ khung hình và dành sẵn đúng không gian trước khi ảnh hoàn tất tải.
• Dành chỗ trước cho nội dung tải muộn. Nguyên tắc này áp dụng cho ảnh, nội dung nhúng và các thành phần được chèn động sau khi trang mở.
• Đánh giá trên nhiều kích thước màn hình. Mức độ dịch chuyển phụ thuộc vào tỷ lệ của phần tử so với vùng hiển thị, nên kết quả có thể khác nhau giữa màn hình lớn và nhỏ.

Khi ảnh đã có kích thước được xác định, website vẫn có thể tải chậm nhưng bố cục không cần thay đổi. Nội dung giữ nguyên vị trí, ảnh chỉ xuất hiện trong khoảng trống đã được chuẩn bị sẵn, vì vậy CLS có thể ở gần bằng không.

INP: Không để thao tác của khách hàng bị treo

INP, hay Interaction to Next Paint, đo thời gian từ khi người dùng tương tác đến khi họ thấy một cập nhật trực quan tiếp theo. Tương tác có thể là bấm nút, nhấn phím hoặc chạm vào màn hình.

Một nút có thể nhận được sự kiện bấm, nhưng nếu giao diện không đổi ngay thì khách hàng vẫn có cảm giác website không phản hồi. Vì vậy, INP quan tâm đến phản hồi nhìn thấy được, không chỉ quan tâm mã xử lý sự kiện đã bắt đầu chạy hay chưa.

Vấn đề của tác vụ dài trên luồng chính

JavaScript trong trình duyệt chạy trên một luồng chính. Nếu một lần bấm nút khởi động tác vụ tính toán nặng, luồng chính bị chiếm dụng và trình duyệt không thể vẽ lại giao diện hoặc xử lý tương tác khác trong khoảng thời gian đó.

Trong trường hợp này, người dùng có thể bấm tăng bộ đếm nhiều lần nhưng không thấy phản hồi. Chỉ sau khi việc xử lý dữ liệu hoàn tất, giao diện mới cập nhật hàng loạt. Đó là nguyên nhân dẫn đến INP cao và trải nghiệm ì ạch.

Chia nhỏ công việc để giao diện luôn phản hồi

• Cập nhật giao diện ngay khi thao tác bắt đầu. Hãy hiển thị trạng thái đang xử lý để người dùng biết hệ thống đã nhận yêu cầu.
• Chia tác vụ lớn thành các phần nhỏ. Thay vì xử lý 10.000 phần tử trong một lượt, bạn có thể xử lý từng nhóm nhỏ, chẳng hạn 500 phần tử.
• Trả quyền điều khiển lại cho trình duyệt giữa các phần xử lý. Bạn có thể áp dụng kỹ thuật như setTimeout hoặc vòng lặp được chia khối để trình duyệt có cơ hội vẽ lại giao diện.
• Giữ luồng chính rảnh khi có thể. Đây là điều kiện để website tiếp tục nhận thao tác mới trong khi công việc nền vẫn đang tiến hành.

Khi công việc được chia thành từng đoạn, trình duyệt có các khoảng ngắn để hiển thị thay đổi và xử lý những thao tác tiếp theo. Người dùng nhận được phản hồi sớm hơn, còn toàn bộ công việc vẫn được hoàn thành.

Đặt Core Web Vitals thành ba ràng buộc thiết kế

Đừng coi đây là một điểm số duy nhất để chạy theo. LCP, CLS và INP đại diện cho ba áp lực kỹ thuật khác nhau: phân phối tài nguyên quan trọng, bố cục có thể dự đoán và khối lượng công việc trên luồng chính.

Vì vậy, cách tiếp cận tốt là kiểm tra từng chỉ số theo đúng nguyên nhân của nó. Khi LCP kém, hãy xem tài nguyên quan trọng có bị chặn hay không. Khi CLS cao, hãy tìm phần tử chưa được dành sẵn không gian. Khi INP chậm, hãy tìm các tác vụ dài đang chiếm luồng chính.

Chrome DevTools có thể giúp bạn quan sát các chỉ số và so sánh trạng thái trước, sau khi tối ưu. Đây là cách thực tế để xác nhận thay đổi kỹ thuật có thật sự cải thiện trải nghiệm trên trang hay chỉ tạo ra cảm giác nhanh hơn trong điều kiện lý tưởng.

FAQ

LCP kém có phải luôn do ảnh lớn không?

Không. Ảnh lớn thường là phần tử LCP, nhưng nguyên nhân làm nó xuất hiện chậm có thể là JavaScript chặn việc phân tích HTML. Khi ảnh đầu trang chỉ được yêu cầu sau khi script chạy xong, LCP sẽ bị ảnh hưởng rõ rệt.

Tại sao thêm kích thước cho ảnh lại cải thiện CLS?

Chiều rộng và chiều cao giúp trình duyệt biết trước tỷ lệ ảnh và chừa sẵn không gian trong bố cục. Khi ảnh tải xong, nó lấp vào không gian đó thay vì đẩy nội dung khác di chuyển.

Có phải mọi tác vụ xử lý đều cần chia nhỏ để cải thiện INP?

Bạn nên ưu tiên chia nhỏ các tác vụ nặng có thể chặn luồng chính trong lúc người dùng đang thao tác. Mục tiêu là tạo cơ hội để trình duyệt cập nhật giao diện và phản hồi tương tác giữa các phần xử lý.

Nếu bạn cần biến các nguyên tắc về tải tài nguyên, bố cục ổn định và phản hồi giao diện thành một website vận hành hiệu quả, dịch vụ thiết kế website và tối ưu SEO của MintStack có thể đồng hành cùng bạn.