Sửa lỗi CLS giúp tăng điểm SEO

Submitted by superthin on 14/10/2020 - 06:54:46
Cumulative Layout Shift cover

CLS = Cumulative Layout Shift là một trong 3 yếu tố của Core Web Vitals có ảnh hưởng quan trọng đến thứ hạng SEO của một trang web. Google tuyên bố rõ điều này vì càng ngày họ càng chú trọng vào trải nghiệm người duyệt web. Bài viết này là sự khởi đầu giúp bạn xác định được vấn đề liên quan CLS để rồi tìm cách khắc phục.

Nguồn cơn để bài viết này ra đời

1) Đầu tiên, những khách hàng của Thin gửi qua email hàng tá những ảnh chụp màn hình đỏ lòm, tạm hiểu trong tiếng Việt là "Vấn đề/ lỗi liên quan CLS: nhiều hơn 0,25 trên điện thoại". Những thứ này đang làm họ khiếp sợ, họ cảm nhận được những website của họ dần dần biết mất khỏi những trang kết quả tìm kiếm Google. Họ còn hỏi Thin liệu trang web của Thin có bị ảnh hưởng hay không.

2) Mấy tuần gần đây Thin được một số anh em làm SEO đề nghị tập huấn cho một vài buổi giúp giải quyết vấn đề CLS này. Chuyện thật như đùa khi một người không làm SEO lại được những người làm SEO xin được tham vấn. Việc "múa rìu qua mắt thợ" đậm chất lố bịch, ngu ngốc nhưng Thin đang cóc thèm quan tâm. Được người khác tham khảo ý kiến khá thú vị, vui vui, chẳng nên ám ảnh làm gì. Các SEOer chịu hạ mình ôm laptop tới nghe Thin chém gió cho thấy họ rất cầu thị, ham học hỏi, điều đó quá tuyệt vời rồi.

Chỉnh sửa CLS
CLS cao trên 0,25 nghĩa là đáng báo động

3) Thin dùng hệ điều hành Ubuntu, mọi thứ trên máy tính đều được Thin cố tình đặt ở chế độ cập nhật thủ công. Việc này giúp cho mỗi tuần học thêm được chút ít gì đó liên quan đến "ai ti". Để giữ cho máy không lạc hậu, tuần nào cũng phải kiểm tra xem có gì cần cập nhật mới? Dẫn đến một hệ quả: luôn phải để mắt xem qua những cập nhật là gì, phần mềm có lỗi bảo mật hoặc tính năng gì mới có đáng để cập nhật hay không, hoặc phải quyết định mọi thứ đang ổn, đừng làm chúng lộn xộn cả lên. Trong quá trình đó, các trình duyệt web họ Mozilla, Chromium thường được để mắt tới. Việc này vô tình buộc Thin đọc được vài thứ, không bị lạc hậu với những công cụ dành cho người làm web mà các trình duyệt web vừa trang bị thêm. Core Web Vitals chẳng phải người xa lạ, mấy bài trên MDN của Mozilla cũng thường hay được để mắt tới.

Không thể xem thường cảnh báo về CLS trong Google Search Console

Nhìn chung, hồi giờ Thin không chú tâm mấy đến chuyện về SEO cho lắm, không cố làm sao cho trang web được lên các kết quả tìm kiếm của máy tìm kiếm. Thin làm web với tư cách là một người của thế hệ cũ, thế hệ mà những trang web còn dùng table nhưng luôn hiểu được nền tảng WWW, HTML.

CLS quá cao
CLS quá cao

Thin từng một giai đoạn khá dài theo dõi blog của Ngài Tim Berners-Lee (blog cũ trên trang MIT - không phải cái dẫn liên kết tại đây) nên những lời khuyên của ngài được Thin ghi nhớ và áp dụng vào trang web của mình. Một điều hiển nhiên, không phải mọi thứ đọc được, Thin đủ hiểu rõ để áp dụng, được phần nào trong đó là đã "mừng muốn chết" rồi.

Thin cũng từng làm những trang web phục vụ những người có thị lực kém, khiếm thị nên hiểu rõ về Web Content Accessibility. Thin luôn biết chắc 100% rằng nếu làm một trang đạt chuẩn phục vụ người mù, thêm nữa, cũng đạt chuẩn phục vụ giới nghiên cứu học thuật là yên tâm về SEO. Nói cách khác, cứ làm web như trang Wikipedia và các trang của Google làm ra là "trùm mền ngủ yên".

Công thức chung để sửa các vấn đề liên quan CLS

1) Hạn chế dùng Responsive Web Design (RWD) nếu bạn cảm thấy CLS là một vấn đề ưu tiên giải quyết trước tiên hoặc phải giải quyết cho bằng được.

Bạn sẽ thắc mắc là không dùng RWD thì làm cách nào?

Hãy áp dụng cách của Facebook, Báo Mới, tức là làm một tên miền phụ (sub domain) cho giao diện phục vụ điện thoại di động. Thử truy cập m.baomoi.com xem. Cách này gần đây không còn được nhiều website ở Việt Nam ưa chuộng bởi nó tốn công cập nhật 2 trang riêng nhưng giải quyết triệt để CLS. Kỹ thuật này được gọi là Separate URL.

Không thích dùng tên miền phụ thì bạn dùng kỹ thuật dynamic serving. Quan trọng: Pre-rendering content for crawlers like Googlebot isn't considered cloaking when set up correctly (lời của Google). Kỹ thuật này dựa trên nguyên lý khi phát hiện ra thiết bị người ta sử dụng thì server script sẽ xử lý, gửi phiên bản HTML phù hợp với thiết bị mà nó vừa phát hiện.

Responsive Web Design không phải là chìa khoá cho vấn đề hiệu suất web của bạn.

Người duyệt web bình thường khó nhận biết một website đang áp dụng RWD hay dynamic serving nếu website đó không dùng tên miền phụ cho dynamic serving.

Về mặt bản chất, separate URL và dynamic serving khá giống nhau/ cùng bản chất, tức là phục vụ riêng mã HTML và tài nguyên multimedia cho phù hợp với thiết bị của người truy cập mà trang web phát hiện được. Còn nếu separate URL mà không phục vụ tương ứng với thiết bị, có lẽ rằng người chủ trì website đó đang không hiểu việc mình làm.

RWD là ôm đồm mã HTML cho mọi thiết bị và thảy việc hiển thị cho trình duyệt người dùng xử lý. ĐÂY LÀ NGUYÊN NHÂN CHÍNH GÂY NÊN vấn đề CLS mà nếu bạn dùng RWD sẽ rất khó để khắc phục.

Trên thế giới, những công ty làm ăn đàng hoàng vẫn áp dụng, Google, Amazon, Facebook, Microsoft, Adobe,... đều ưu tiên áp dụng separate URL và/ hoặc dynamic serving hơn RWD bởi họ tin rằng họ đủ nguồn lực để làm trang web hài lòng người truy cập.

Nếu bạn là người làm web cho người khác để kiếm tiền mà bạn không biết trang nào dùng kỹ thuật nào, Thin nói hẳn "bạn hãy còn non xanh lắmlaugh

Mặc dù Google khuyến cáo nên dùng RWD hơn dùng dynamic serving. Nhiều người không biết nguyên nhân nguồn cơn đích thực vì sao như vậy, Google cũng không tiết lộ rõ mà chỉ khuyên nọ khuyên kia. Thin biết có lý do:

1. Ngày xửa ngày xưa Google bị dân làm SEO chơi khăm/ lừa bằng cái gọi là cloaking, nhất là với vụ của Experts-Exchange quá đình đám. Ngày nay, Google đã áp dụng kỹ thuật crawl trang web như có một trình duyệt xử lý thực sự (nói rõ hơn: Google thực hiện parse/ render trang web khi crawl giống hệt trình duyệt người dùng truy cập web) nên để ai đó chơi trò cloaking không phải dễ. Vì thế, bạn thoải mái + yên tâm dùng dynamic serving. Nếu bạn làm tốt, đúng cách, khách truy cập trên điện thoại sẽ rất hài lòng vì chắc chắn phiên bản tách rời chỉ cho di động sẽ tốt hơn nhiều so với bản dành cho cả di động và máy tính. Bạn có từng truy cập https://mobile.twitter.com chứ? Tốc độ thế nào trên điện thoại của bạn?

2. Khi trang web dùng RWD thì Google không phải tốn nhiều tài nguyên để lưu trữ dữ liệu index. Chỉ có một tập hợp tài nguyên (HTML + CSS + Javascript + multimedia) mà thôi. Giải thích rõ hơn: nội dung dành cho cho mobile, máy tính bảng, máy tính cá nhân đều như nhau cả. Ai mà không muốn tiết kiệm mà vẫn đạt được mục đích? Google không là ngoại lệ, họ phải đưa ra lời khuyên có lợi cho họ chứ.

Ngay từ thuở ban đầu khi kỹ thuật thiết kế web tuỳ biến RWD ra đời, Thin đã cảm thấy nó có vấn đề, đã từng chê nó như một chiếc xe mô-tô xít đờ ca, và đúng là cho đến bây giờ nhận định đó vẫn còn đúng sau cả chục năm. Biết là một chuyện, cái biết đó có mang ra dùng được hay không hồi sau sẽ rõ crying

Vì sao RWD đang chiếm ưu thế? Làm một trang web với kỹ thuật RWD phục vụ cho cả di động, máy tính bảng và máy tính màn hình rộng, retina các kiểu sẽ ít phức tạp vấn đề hơn làm hai trang web riêng biệt.

Nếu là dynamic servering thì trong mã nguồn server script sẽ phải có code xử lý luận lý "nếu thiết bị này thì làm cái này, thiết bị kia thì làm cái kia" => rách việc => mỗi lần nâng cấp, chỉnh chọc gì đó công việc nặng nhọc vô cùng. RWD không cần phải thế, giúp giảm đi 50% công sức/ tiền của, ai mà chả thích?

2) Cảm thấy không kham nổi dynamic serving, vẫn tạm dùng RWD thì sao?

Bạn đã đọc đoạn dynamic serverving ở trên, tự nhận thấy khó đủ sức để áp dụng nó, chỉ muốn dùng RWD nhưng vẫn luôn muốn cách nào đó để cải thiện vấn đề CLS. Đó là một mong muốn chính đáng. Mới đầu tìm hiểu, bạn cảm thấy mông lung, giống như một số SEOer than thở:

Bó tay CLS
Không hoặc chưa đủ trình để nghiên cứu, giải quyết vấn đề CLS

Thêm một ý kiến khác về  Cumulative Layout Shift xem có gì mới:

Chịu thua CLS
Đành chờ cao nhân giúp sức

Thin cũng đã từng lạc lối vì không rõ phải xử lý như thế nào về vấn đề này. Sau khi ngồi liệt kê lại tại sao không xử lý được vấn đề, phát hiện ra rằng mình nhận định chưa đúng vấn đề, hay nói đúng hơn đó là chưa hiểu thông suốt "tình huống có vấn đề" là như thế nào.

Một vấn đề chỉ được xem là vấn đề nếu nó được nhận diện, có nhận định/ phác thảo ra cách giải quyết, khả thi hay không tính sau nhưng thiên về hướng khả thi. Còn nếu không, nó ngoài phạm vi, đó không được xem là vấn đề nữa, hãy sớm phớt lờ nó đi, bạn sẽ đỡ bực mình hơn.

Điểm CLS tính theo cách số càng lớn càng kém, zero là tốt nhất, chứ không phải số càng lớn càng tốt, đó là cốt lõi.

Hiểu theo cách không liên quan đến thuật ngữ, kỹ thuật web thì một trang web có CLS bằng zero nghĩa là một trang web không tiềm ẩn những cái bẫy, cái ổ gà, ổ voi khiến người dùng đang "lướt trên xa lộ" có nguy cơ sụp hố.

Nghĩa là người dùng nhìn thấy trực quan, theo lối hiểu biết thông thường lâu nay họ hiểu rằng thấy đèn đỏ thì dừng, đèn xanh lá cây là đi. Khi khách truy cập web thấy nút trên trang là có thể bấm, nếu nó Yes thì phải là đồng ý gì đó, Cancel hoặc No thì phải là huỷ bỏ, không thể lẫn lộn, nhập nhằng, tối nghĩa.

Khi đang duyệt web các đối tượng trên trang phải ổn định về bố cục, không cho phép bỗng nhiên dịch chuyển "bẻ lái" bất ngờ, gây bối rối.

Từ nhận định theo phong cách bác sỹ "chẩn đoán bệnh" đó, suy ra những trang web càng có nhiều CSS, font chữ nạp ngoài, có JavaScript sẽ tiềm ẩn nguy cơ làm cho chỉ số CLS cao. Những trang web phong phú về đối tượng trên trang, bố cục phức tạp (nhiều khối, dòng, cột, float, position, chỉnh size,...) cũng ẩn chứa việc trình duyệt khi hiển thị nó sẽ méo mó, biến dạng ngoài dự định, ý đồ người thiết kế ban đầu.

Để kiểm nghiệm nhận định này, Thin làm thử 5 trang web chỉ có HTML, không có chút nào CSS (cũng không có CSS viết inline trong thuộc tính style), không JavaScript luôn. 5 trang này có nội dung khá là dài (in ra chắc cũng 20 trang A4/ trang), rất nhiều thẻ HTML nhưng bố cục thì đơn giản, không lồng nhiều lớp vào nhau. Kết quả: CLS luôn nằm ở zero hoặc ở một con số nhỏ 0.00X, luôn xanh lá cây trên công cụ kiểm tra của Google. Nhận định đã phần nào tiếp cận được vấn đề.

Tiếp theo, Thin cũng thấy rằng trong quá trình tối ưu tăng tốc web cho khách hàng có khi giảm việc nạp trang xuống rất tốt, nhưng CLS lại tăng lên cao vút. Khi phân tích sâu thêm, biết rằng khi trình duyệt web "vẽ" lại trang web, nó kết hợp các thành phần HTML + CSS + JavaScript + hình ảnh, giống như chúng ta đọc chỉ dẫn để làm bánh vậy.

Một so sánh, nếu người viết sách làm bánh viết dở tệ, không bố cục tốt, có khả năng là người mua sách về đọc, làm theo sẽ có nhiều động tác thừa, thứ tự thao tác, chuẩn bị dụng cụ cứ loạn cả lên, dẫn đến chiếc bánh thành phẩm trông đến tội nghiệp. Trang web của bạn y chang như vậy.

Việc đơn giản nhất có thể làm đó là những thuộc tính bắt buộc như độ rộng chiều cao của hình ảnh là phải có, hạn chế thấp nhất việc thiếu sót thông số để trình duyệt phải tự tính quá lâu. Chỗ nào dùng được giá trị absolute thì cũng nên áp dụng thay vì dùng giá trị relative khiến trình duyệt mất thời gian tính toán.

Cấp độ cây DOM của HTML cũng nên đơn giản, tránh lồng ghép quá nhiều. Hạn chế thấp nhất việc trộn lẫn CSS được viết trong phần head với CSS được inline trực tiếp vào thẻ HTML. Cũng né những việc dùng JavaScript xử lý thay đổi DOM, rồi thay đổi CSS, việc dùng các tính toán trong function của CSS cũng hạn chế. Mấy cái gọi là lazy load giúp tăng tốc web tải xuống vì trì hoãn, tải hình sau nhưng chính là con dao hai lưỡi đối với CLS, bạn cần hết sức cẩn thận.

Khi xử lý đúng, CLS thấp và tốc độ nạp trang web cũng nhanh. Còn nếu hai cái đó trở nên tỉ lệ nghịch với nhau thì chưa xử lý tốt, chưa nắm được luồng xử lý workflow của trình duyệt web.

Thin không đòi hỏi bạn phải đọc mã nguồn của các trình duyệt web, nghiên cứu các thứ Webkit Engine, Blink Engine, Gecko Engine để xem những engine này vận hành, xử lý mã HTML cấp độ thấp khi nạp một trang web chi tiết ra sao. Điều đó là quá sức đối với người làm SEO thông thường, ngay cả lập trình viên cũng còn ngán tận cổ.

Thin chỉ gợi ý bạn hãy tìm đọc những bài viết dạng "how to browser render a web page" để có cái nhìn nền tảng, căn bản việc này. Từ hiểu biết đó mang áp dụng vào cách bố cục trang web của bạn, chắc chắc CLS giảm xuống ngay.

Trình duyệt render trang web thế nào

Sau khi nắm vững cách thức trình duyệt gửi yêu cầu, nhận tài nguyên từ web server, rồi "vẽ lại một trang web" lên màn hình người dùng như thế nào, cái gì "vặn xoắn" với cái gì, phối hợp theo thứ tự nào, bạn chắc chắn 99,99% giải quyết thành công chỉ số CLS cao. Nếu không giải quyết nổi, tốt hơn hết là tìm sư phụ chỉ dạy mặt đối mặt vì khả năng tự học của bạn trong vấn đề này chưa đủ, nền tảng còn yếu, còn non tay.

Nếu bạn quá khó hình dung lợi ích của việc nắm được trang web được parse, được render như thế nào, Thin gợi ý bạn ra nhà sách, tiệm bán đồ chơi mua một bộ đồ chơi lắp ghép. Bạn về nhà nhìn hình trên vỏ hộp rồi tự lắp ghép so với đọc hướng dẫn các bước thứ tự xem. Nhớ bấm đồng hồ để biết được. Hay hơn nữa, bạn không xem giấy hướng dẫn mà tự viết cho người khác đọc để họ lắp ráp, rồi họ sẽ đọc giấy của bạn và tờ hướng dẫn của bộ đồ chơi. Thời gian & kết quả lắp ráp nên món đồ chơi chính là trang web đã được trình duyệt "vẽ nên" ra làm sao.

Thay lời kết luận

Vậy là xong bài rồi hén. Qua bài viết này bạn thấy thế nào? Hãy cho Thin biết cảm nghĩ bằng cách bình luận hoặc click vào biểu tượng mặt người bên dưới nhé. Xin cám ơn!

-----

Chú ý: dynamic serving đôi lúc còn được gọi là Dynamic Rendering, Dynamic Parsing.