CLS, viết đầy đủ là Cumulative Layout Shift, đo mức độ xê dịch bất ngờ của các thành phần đang hiển thị trong suốt vòng đời của trang. Nếu bạn đang đọc mà đoạn chữ bỗng trượt xuống, hoặc nút “Hủy” chạy khỏi ngón tay ngay lúc bấm, đó là trải nghiệm CLS đang cố gắng định lượng.
Trả lời nhanh: CLS từ 0,1 trở xuống được xem là tốt. Từ trên 0,1 đến 0,25 cần cải thiện, còn trên 0,25 là kém. Hãy đánh giá tại phân vị thứ 75, tách mobile và desktop. Muốn giảm CLS, ưu tiên khai báo kích thước ảnh, chừa chỗ cho nội dung nhúng, kiểm soát font và không chèn nội dung mới phía trên phần người dùng đang đọc.
Cumulative Layout Shift và CLS là gì?
Cumulative Layout Shift là một trong ba chỉ số Core Web Vitals. Chỉ số này không đo thời gian tải theo giây. Nó đo độ ổn định thị giác bằng cách xem bao nhiêu nội dung trong vùng nhìn bị ảnh hưởng và nội dung đó dịch chuyển xa đến đâu.
Một layout shift xảy ra khi phần tử đang nhìn thấy thay đổi vị trí từ khung hình này sang khung hình kế tiếp. Trình duyệt gom các lần dịch chuyển xảy ra gần nhau thành một session window. Một cửa sổ bắt đầu khi có dịch chuyển, kết thúc khi không còn dịch chuyển trong hơn một giây và kéo dài tối đa năm giây. CLS của trang là tổng điểm lớn nhất trong các cửa sổ đó.
| Mức CLS | Đánh giá | Ưu tiên xử lý |
|---|---|---|
| 0 đến 0,1 | Tốt | Duy trì và theo dõi dữ liệu thực tế |
| Trên 0,1 đến 0,25 | Cần cải thiện | Tìm nhóm trang và phần tử gây dịch chuyển |
| Trên 0,25 | Kém | Ưu tiên sửa template hoặc thành phần dùng chung |
Ngưỡng nên được kiểm tra tại phân vị thứ 75 của lượt tải trang. Nói đơn giản, ít nhất 75% lượt truy cập cần đạt mức mục tiêu. Một lần chạy Lighthouse đẹp chưa đủ để kết luận toàn bộ người dùng có trải nghiệm ổn định.
Vì sao CLS quan trọng với người dùng và SEO?
CLS cao khiến người dùng mất vị trí đang đọc, bấm nhầm hoặc nghi ngờ website chưa tải xong. Trên trang thương mại, một nút thay đổi vị trí có thể làm khách chọn nhầm sản phẩm. Trên blog, quảng cáo hoặc ảnh xuất hiện muộn có thể đẩy đoạn đang đọc ra khỏi màn hình.
Core Web Vitals là một phần trong tín hiệu trải nghiệm trang của Google, nhưng CLS không phải chiếc nút giúp một trang tự động lên Top. Nội dung vẫn phải đúng Search Intent, có khả năng crawl, index và đáp ứng nhu cầu tốt. Hãy sửa CLS vì người dùng trước, sau đó dùng dữ liệu Search để đánh giá ảnh hưởng.
Điểm layout shift được tính như thế nào?
Mỗi lần dịch chuyển có điểm bằng impact fraction nhân distance fraction. Impact fraction thể hiện tỷ lệ vùng nhìn bị ảnh hưởng. Distance fraction thể hiện quãng đường lớn nhất mà phần tử bất ổn đã di chuyển, tính theo kích thước vùng nhìn.
Ví dụ, một khối chiếm 50% chiều cao màn hình bị đẩy xuống một khoảng bằng 20% chiều cao màn hình. Điểm dịch chuyển xấp xỉ 0,5 × 0,2 = 0,1. Đây chỉ là ví dụ minh họa. Khi audit, bạn nên để Chrome DevTools xác định phần tử thay vì tự tính bằng mắt.
Không phải mọi chuyển động đều xấu. Dịch chuyển xảy ra ngay sau thao tác của người dùng thường được loại khỏi phép tính nếu trình duyệt xác định đó là phản hồi được mong đợi. Hoạt ảnh dùng transform cũng thường không làm thay đổi layout theo cách gây CLS.
CLS thực tế và CLS trong phòng thử nghiệm khác nhau ra sao?
Dữ liệu thực tế, hay field data, phản ánh những gì người dùng Chrome đã trải qua trong 28 ngày gần nhất khi dữ liệu CrUX đủ điều kiện. Dữ liệu phòng thử nghiệm, hay lab data, là một lần đo trong điều kiện mô phỏng. Hai nguồn phục vụ hai câu hỏi khác nhau.
| Nguồn | Dùng để làm gì | Giới hạn |
|---|---|---|
| PageSpeed Insights Field Data | Xác định người dùng thật có đạt ngưỡng hay không | Có độ trễ và có thể thiếu dữ liệu cho URL ít truy cập |
| Lighthouse | Tái hiện nhanh lỗi trong lúc tải trang | Không thấy mọi tương tác và nội dung xuất hiện muộn |
| Chrome DevTools Performance | Chỉ ra thời điểm và phần tử dịch chuyển | Cần tái hiện đúng hành vi gây lỗi |
| Thư viện web-vitals hoặc RUM | Gắn CLS với URL, thiết bị và phiên truy cập | Cần triển khai thu thập và kiểm soát dữ liệu |
Lab tốt nhưng field kém thường cho thấy lỗi xuất hiện sau khi tải, trong phiên dài hoặc chỉ xảy ra với một nhóm người dùng. Ví dụ gồm cookie banner, chat widget, quảng cáo, nội dung cá nhân hóa và font tải chậm. Khi đó, hãy truy vết bằng dữ liệu người dùng thật thay vì chạy Lighthouse lặp lại.
Cách kiểm tra CLS theo quy trình 6 bước
- Mở PageSpeed Insights và nhập đúng URL canonical cần kiểm tra.
- Đọc dữ liệu người dùng thật trước, tách mobile và desktop.
- Xem trang đang đạt hay không đạt ở cấp URL hoặc cấp nhóm URL.
- Mở Chrome DevTools, vào Performance rồi ghi lại quá trình tải và tương tác.
- Chọn các mục Layout Shift để xem phần tử bị ảnh hưởng và ảnh chụp trước sau.
- Sửa một nhóm nguyên nhân, triển khai và đo lại trong cả lab lẫn field.
Nếu toàn bộ bài blog cùng có CLS cao, hãy kiểm tra template trước khi sửa từng bài. Header, breadcrumb, ảnh đầu bài, vùng tác giả, banner và widget thường được dùng chung. Cách xử lý này tiết kiệm hơn việc tối ưu từng URL riêng lẻ.
7 nguyên nhân CLS cao thường gặp
1. Ảnh không có kích thước hoặc tỷ lệ khung hình
Khi trình duyệt chưa biết ảnh cao bao nhiêu, nó không thể chừa chỗ trước. Nội dung bên dưới được vẽ lên rồi bị đẩy xuống khi ảnh tải xong. Khai báo width và height, hoặc dùng CSS aspect-ratio phù hợp.
2. Video, iframe và bản đồ xuất hiện muộn
YouTube, Google Maps và nội dung nhúng của bên thứ ba thường tải sau. Bọc chúng trong một khung có tỷ lệ cố định. Nếu dùng lazy load, placeholder vẫn phải chiếm đúng không gian cuối cùng.
3. Quảng cáo và banner không được chừa chỗ
Kích thước quảng cáo có thể thay đổi theo thiết bị và chiến dịch. Hãy đặt chiều cao tối thiểu cho từng vị trí. Nếu không có quảng cáo để lấp, cân nhắc giữ khoảng trống có chủ đích hoặc thu gọn theo cách không đẩy nội dung đang xem.
4. Font web làm chữ đổi kích thước
Font thay thế và font chính có chiều rộng khác nhau có thể làm dòng chữ xuống hàng lại. Preload font quan trọng, dùng định dạng nén, giới hạn số biến thể và chọn fallback có metric gần font chính. Thuộc tính font-display cần được chọn theo mục tiêu trải nghiệm chứ không dùng một giá trị cho mọi font.
5. Nội dung được chèn phía trên viewport
Thông báo, khuyến mại và lời mời cài ứng dụng xuất hiện sau khi trang ổn định sẽ đẩy mọi thứ xuống. Nên chừa chỗ ngay từ đầu, dùng overlay có kiểm soát hoặc đặt nội dung mới ở vị trí không làm phần đang đọc dịch chuyển.
6. Thành phần thay đổi sau khi hydrate
Ứng dụng React hoặc Vue có thể render một bố cục ban đầu rồi thay thế bằng trạng thái khác sau khi JavaScript chạy. Skeleton phải gần đúng kích thước nội dung thật. Dữ liệu quan trọng nên được render ổn định từ initial HTML khi có thể.
7. CSS tải muộn hoặc breakpoint không nhất quán
CSS quan trọng đến sau HTML có thể làm trang đổi font, khoảng cách hoặc cột. Đưa critical CSS cần thiết vào luồng tải sớm, tránh tải stylesheet theo cách khiến giao diện chưa định dạng xuất hiện trước.
Cách giảm CLS theo thứ tự ưu tiên
Đừng bắt đầu bằng việc chỉnh từng pixel. Hãy ưu tiên phần tử tạo điểm dịch chuyển lớn nhất và xuất hiện trên nhiều URL nhất.
- Chốt kích thước media: khai báo kích thước cho ảnh, video, iframe và visual trong bài.
- Chừa vùng cho thành phần động: quảng cáo, form, đánh giá, widget và banner có khung ổn định.
- Ổn định font: preload đúng font, cắt bớt weight và điều chỉnh fallback.
- So khớp skeleton với nội dung thật: chiều cao và cấu trúc của trạng thái tải không được chênh quá lớn.
- Tránh chèn phía trên nội dung: mọi khối xuất hiện muộn cần có vùng dự phòng.
- Đo lại theo template: kiểm tra trang chủ, dịch vụ, blog và trang công cụ riêng.
Ví dụ audit bài blog tại Mạnh Digital
Với một bài như hướng dẫn PageSpeed Insights, quy trình không chỉ dừng ở điểm Performance. Trước tiên kiểm tra ảnh featured có tỷ lệ cố định hay không. Tiếp theo xem breadcrumb, tiêu đề, mục lục tự động và bảng có làm chiều cao thay đổi sau khi JavaScript chạy không. Sau đó mở Performance để tái hiện cuộn trang và các widget.
Nếu lỗi nằm ở component dùng chung, sửa tại template BlogPost sẽ có giá trị cho cả cluster. Nếu chỉ một visual thiếu kích thước, sửa dữ liệu ảnh của URL đó. Việc phân biệt lỗi template và lỗi nội dung giúp tránh chỉnh hàng chục bài nhưng CLS vẫn quay lại khi xuất bản bài mới.
CLS ảnh hưởng SEO và GEO như thế nào?
CLS không tạo một quy tắc GEO riêng. Trang vẫn cần nội dung rõ, nguồn đáng tin, canonical đúng và phần chính xuất hiện trong initial HTML. Tuy nhiên, bố cục ổn định giúp người đọc tiếp cận câu trả lời và tương tác với bảng, visual hoặc CTA mà không bị gián đoạn.
Với nội dung phục vụ AI Search, hãy giữ đoạn trả lời trực tiếp gần đầu trang, dùng heading rõ và bảo đảm các khối tải muộn không che hoặc đẩy câu trả lời. Có thể đọc thêm GEO là gì, Mobile-first Indexing và tốc độ website ảnh hưởng SEO.
Checklist giảm CLS trước khi deploy
- Ảnh và video có width, height hoặc aspect-ratio.
- Iframe, bản đồ, quảng cáo và widget có vùng dự phòng.
- Font quan trọng được preload đúng cách và fallback gần kích thước.
- Skeleton có kích thước gần nội dung thật.
- Banner không được chèn bất ngờ phía trên phần đang đọc.
- Animation ưu tiên transform và opacity.
- Đã kiểm tra mobile, desktop, mạng chậm và phiên chưa có cache.
- Đã so sánh dữ liệu lab với field data.
- Đã lưu ảnh trước sau và URL được kiểm tra.
- Đã theo dõi lại sau khi dữ liệu CrUX cập nhật.
Câu hỏi thường gặp về CLS
CLS bằng 0 có bắt buộc không?
Không. Mục tiêu chính thức là 0,1 trở xuống tại phân vị thứ 75. CLS bằng 0 là lý tưởng, nhưng việc ép mọi trang về 0 có thể tốn công hơn giá trị mang lại. Hãy ưu tiên các dịch chuyển làm người dùng mất vị trí hoặc bấm nhầm.
PageSpeed không có dữ liệu thực tế thì làm sao?
Hãy dùng Lighthouse và Chrome DevTools để tìm lỗi trước. Đồng thời có thể triển khai Real User Monitoring bằng thư viện web-vitals. Khi URL ít traffic, xem dữ liệu cấp origin hoặc nhóm template nhưng cần ghi rõ đó không phải dữ liệu riêng của URL.
Lazy loading có làm CLS tăng không?
Lazy loading không tự gây CLS. Lỗi xuất hiện khi ảnh hoặc iframe lazy load không có kích thước dự phòng. Nếu trình duyệt biết tỷ lệ khung hình từ đầu, tài nguyên có thể tải muộn mà nội dung xung quanh vẫn ổn định.
Pop-up có bị tính vào CLS không?
Overlay cố định thường không đẩy layout bên dưới, nhưng vẫn có thể gây trải nghiệm kém nếu che nội dung. Banner được chèn vào luồng trang và đẩy nội dung xuống có khả năng tạo layout shift. Cần kiểm tra hành vi thực tế bằng DevTools.
Kết luận
CLS là thước đo độ ổn định thị giác, không phải điểm tốc độ tính bằng giây. Hãy bắt đầu từ dữ liệu người dùng thật, tìm phần tử dịch chuyển lớn nhất, sửa template trước URL riêng lẻ và đo lại sau triển khai. Nếu website có nhiều lỗi Core Web Vitals cùng lúc, một SEO Audit theo template sẽ giúp xác định đúng P0, P1 và P2.