Core Web Vitals: LCP, INP Và CLS Thực Sự Đo Điều Gì?

Core Web Vitals đo ba khía cạnh khác nhau của trải nghiệm người dùng: loading, interaction responsiveness và visual stability. Largest Contentful Paint (LCP) đại diện cho loading experience, Interaction to Next Paint (INP) đại diện cho responsiveness, còn Cumulative Layout Shift (CLS) đại diện cho visual stability.

Nhưng các metric này là phép đo, không phải diagnosis. LCP kém không tự động có nghĩa hero image quá lớn. INP kém không chứng minh mọi file JavaScript đều có vấn đề. CLS kém cũng không tự cho biết element nào gây ra sự dịch chuyển.

Câu hỏi hữu ích không chỉ là “Website có pass không?” mà là: Phần nào của trải nghiệm người dùng đang có vấn đề, trong điều kiện nào và cần evidence gì để xác định responsible layer?

Core Web Vitals Là Gì?

Core Web Vitals là một tập con của Web Vitals, được thiết kế để đại diện cho những khía cạnh quan trọng, lấy người dùng làm trung tâm của page experience và có thể đo trong điều kiện sử dụng thực tế.

Core Web Vitals không đại diện cho mọi khía cạnh của performance hay toàn bộ user experience.

Chúng không phải là:

• một performance audit hoàn chỉnh;
• một hệ thống đo UX đầy đủ;
• Lighthouse Performance Score;
• một SEO score duy nhất;
• một root-cause diagnosis.

Core Web Vitals Đo Trải Nghiệm, Không Phải Root Cause

Phân biệt này là nền tảng để sử dụng Core Web Vitals đúng cách.

Giả sử field data cho thấy LCP kém.

Đây là evidence cho thấy loading experience chưa đạt ngưỡng mong muốn đối với một phần đáng kể người dùng. Nhưng nó chưa xác định nguyên nhân.

Responsible path có thể liên quan tới:

– server response time;
– late discovery of the LCP resource;
– resource loading;
– rendering delay;
– client-side behavior.

Logic tương tự áp dụng cho INP và CLS.

Largest Contentful Paint: Loading Experience

Largest Contentful Paint đo perceived loading performance bằng cách ghi nhận thời điểm image, text block hoặc video đủ điều kiện lớn nhất đang hiển thị trong viewport được render, tính từ lúc bắt đầu navigation.

Nói đơn giản, LCP trả lời câu hỏi:

Tùy page, LCP element có thể là:

• hero image;
• heading lớn hoặc text block lớn;
• content image nổi bật;
• video poster hoặc qualifying visible element khác.

LCP hữu ích vì nó gần với thời điểm người dùng cảm nhận nội dung chính của trang đã xuất hiện hơn các milestone cũ có thể xảy ra trước khi meaningful content hiển thị.

Nhưng LCP không chứng minh vì sao nội dung đó xuất hiện muộn.

Nếu LCP là metric đang có vấn đề, hãy đọc tiếp why LCP is slow. Phần resource discovery thuộc bài chuyên sâu late LCP discovery.

Interaction to Next Paint: Responsiveness

Interaction to Next Paint đánh giá mức độ responsive của page đối với tương tác người dùng như click, tap và keyboard input trong suốt vòng đời của page.

INP không phải chủ yếu là một page-load metric.

Một page có thể load nhanh nhưng vẫn phản hồi kém sau khi đã hiển thị.

Ở mức khái niệm, một interaction có thể gồm:

• input delay trước khi event processing bắt đầu;
• processing time liên quan tới interaction;
• presentation delay trước khi browser có thể paint frame tiếp theo.

Vì vậy INP trả lời câu hỏi khác với LCP:

Một site có loading experience rất tốt vẫn có thể INP kém nếu browser thường xuyên không phản hồi kịp thời với interaction.

Để diagnosis sâu hơn, đọc tiếp long tasks and INP.

Cumulative Layout Shift: Visual Stability

Cumulative Layout Shift đo visual instability bằng cách lượng hóa các unexpected layout shift ảnh hưởng tới nội dung đang hiển thị.

Vấn đề người dùng cảm nhận khá dễ nhận biết:

• text dịch chuyển khi đang đọc;
• button di chuyển ngay trước khi bạn click;
• content bị đẩy xuống khi một phần tử được chèn phía trên;
• layout thay đổi ngoài dự kiến sau initial rendering.

CLS khác LCP và INP vì nó không chủ yếu hỏi nội dung load khi nào hay interaction phản hồi nhanh đến mức nào.

Nó hỏi layout có duy trì visual stability hay không.

LCP, INP Và CLS Khác Nhau Như Thế Nào?

Các metric bổ sung cho nhau, không thay thế cho nhau.

Một site có thể LCP tốt nhưng INP kém. Có thể INP tốt nhưng CLS kém. Cải thiện một metric không tự động cải thiện các metric còn lại.

Core Web Vitals Bao Nhiêu Được Xem Là Tốt?

Ngưỡng hiện hành phân loại mỗi metric thành good, needs improvement hoặc poor.

Với field evaluation, cách đánh giá hiện hành dựa trên 75th percentile (p75) của page load, phân tách theo mobile và desktop.

Điều này quan trọng vì field performance là một distribution, không phải một average user và cũng không phải một lần test.

Threshold và field-evaluation method đã được kiểm tra theo hướng dẫn hiện hành của web.dev trước khi tạo bản này.

Field Data Và Lab Data Khác Nhau Như Thế Nào?

Core Web Vitals được thiết kế để phản ánh real-user experience, nhưng engineer vẫn cần controlled lab data để diagnose problem.

Lighthouse Score Không Phải Core Web Vitals

Lighthouse là một diagnostic tool có giá trị.

Performance Score của Lighthouse là synthetic composite score được tạo trong lab condition xác định. Nó không giống field Core Web Vitals.

Phân biệt này giúp tránh nhiều sai lầm phổ biến:

• Lighthouse score 100 không có nghĩa mọi real user đều có Core Web Vitals tốt;
• mobile Lighthouse score thấp không chứng minh mọi mobile user đều fail Core Web Vitals;
• page có thể cải thiện Lighthouse score mà chưa sửa real-user bottleneck quan trọng nhất;
• field Core Web Vitals có thể cải thiện hoặc xấu đi trong điều kiện mà một lab test không reproduce được.

Để xem so sánh chuyên sâu, đọc Lighthouse vs Core Web Vitals.

Vì Sao Website Có Thể Pass Lab Nhưng Fail Field?

Lab và field result có thể khác nhau mà không có nghĩa bộ dữ liệu nào “sai”.

Real user có thể khác nhau về:

Một controlled lab test có thể chỉ test một page trên một device profile trong một test window.

Dữ liệu thực tế tổng hợp actual visit theo thời gian.

Chiều ngược lại cũng có thể xảy ra: lab test có thể reproduce một deliberately constrained condition tệ hơn phần lớn real-user visit.

Tư Duy Page-Level Và Origin-Level

Core Web Vitals behavior không nhất thiết đồng đều trên toàn bộ site.

Performance có thể khác nhau giữa:

• template;
• URL;
• mobile và desktop;
• user population;
• geographic region;
• network condition;
• application state.

Homepage nhanh không chứng minh mọi article, product hoặc checkout flow có cùng experience.

Tương tự, một URL có vấn đề không tự động chứng minh mọi page trên origin đều hoạt động như vậy.

Đây là thêm một lý do để rời khỏi tư duy “một score đại diện toàn site”.

Core Web Vitals Tốt Không Có Nghĩa Mọi Thứ Đều Nhanh

Core Web Vitals chủ đích tập trung vào một số outcome lấy người dùng làm trung tâm.

That means a site can:

Core Web Vitals là measurement quan trọng, nhưng không thay thế một root-cause performance investigation đầy đủ.

Metric Kém Không Cho Bạn Biết Root Cause

Đây là nguyên tắc interpretation quan trọng nhất của bài.

Đây là investigation direction, không phải automatic diagnosis.

Khi LCP Kém, Nên Điều Tra Gì?

Nếu LCP kém, bước tiếp theo là điều tra loading path, không phải mặc định một optimization cụ thể.

Ở mức tổng quan, các câu hỏi hữu ích gồm:

• Initial document response đã bị delay từ đầu chưa?
• LCP resource có được discover sớm không?
• Bản thân resource có mất quá lâu để load không?
• Resource đã có nhưng rendering vẫn bị delay không?

Investigation chi tiết thuộc bài why LCP is slow.

Khi INP Kém, Nên Điều Tra Gì?

Nếu INP kém, investigation chuyển sang interaction và browser main-thread behavior.

Các câu hỏi tổng quan hữu ích gồm:

• Interaction nào chậm?
• Luồng chính đã bận khi input xảy ra chưa?
• Event processing mất bao lâu?
• Visual presentation có bị delay sau processing không?
• First-party hoặc third-party work có đóng góp không?

Phân tích sâu hơn thuộc Interaction to Next Paint và long tasks and INP.

Khi CLS Kém, Nên Điều Tra Gì?

Nếu CLS kém, investigation cần xác định layout movement nào đang đóng góp vào instability và chúng xảy ra trong điều kiện nào.

Hướng có thể gồm:

• media dimensions;
• ads hoặc embeds;
• font changes;
• dynamically inserted content;
• UI element resize hoặc xuất hiện ngoài dự kiến.

Full diagnosis thuộc bài Cumulative Layout Shift.

Core Web Vitals Diagnostic Routing

METRIC NÀO CẦN ĐƯỢC CHÚ Ý?
│
├─ LCP
│  └─ Điều tra loading path
│
├─ INP
│  └─ Điều tra interaction và main-thread responsiveness
│
└─ CLS
   └─ Điều tra visual stability
        ↓
VẤN ĐỀ XUẤT HIỆN Ở FIELD DATA, LAB DATA HAY CẢ HAI?
│
├─ CHỈ FIELD
│  └─ Điều tra biến thiên theo user / device / template / geography
│
├─ CHỈ LAB
│  └─ Kiểm tra test setup, conditions và reproducibility
│
└─ CẢ HAI
   └─ Ưu tiên root-cause diagnosis

Nếu nhiều Core Web Vitals cùng fail, không nên mặc định chúng có chung một root cause.

Một dependency có thể ảnh hưởng nhiều metric, nhưng mối quan hệ đó phải được chứng minh bằng evidence.

Những Hiểu Lầm Phổ Biến Về Core Web Vitals

Core Web Vitals Và SEO

Core Web Vitals không nên được xem như một “SEO score” độc lập.

Google cho biết các ranking system sử dụng Core Web Vitals như một phần của broader page-experience consideration, đồng thời cũng nêu rõ Core Web Vitals tốt không đảm bảo top ranking.

Tìm kiếm system xem xét nhiều signal và relevance vẫn rất quan trọng.

Performance có thể ảnh hưởng user experience và task completion, nhưng business impact như conversion hoặc revenue nên được đo bằng dữ liệu riêng của site thay vì suy đoán chỉ từ metric.

Khi Nào Cần Core Web Vitals Investigation?

Investigation sâu hơn hữu ích khi:

Khi một Core Web Vital fail, metric cho biết phần nào của user experience đang có vấn đề nhưng không nhất thiết cho biết vì sao. Investigation sâu hơn có thể cần browser trace, request dependency, field data và application evidence để isolate responsible layer.

• Largest Contentful Paint
• Why LCP Is Slow
• Late LCP Discovery
• Interaction to Next Paint
• Long Tasks and INP
• Cumulative Layout Shift
• Lighthouse vs Core Web Vitals
• Root-Cause Performance Investigation
• Core Web Vitals

Điểm Cần Nhớ

Core Web Vitals cho biết phần nào của user experience cần được chú ý.

LCP chỉ về loading experience.

INP chỉ về interaction responsiveness.

CLS chỉ về visual stability.

Chúng không cho bạn biết root cause.

Đó là khác biệt giữa score chasing và Core Web Vitals performance engineering.