SEO Lighthouse: Hướng dẫn kỹ thuật tăng hiệu quả

Cùng tìm hiểu cách kiểm tra hiệu quả bằng SEO Lighthouse, những chỉ số nào nằm trong điểm Hiệu quả của SEO Lighthouse và ý nghĩa.

Nếu đọc bài này có thể là vì là một người yêu thích các chỉ số. Hoặc do không biết Lighthouse là gì và quá ngại hỏi. Lựa chọn nào cũng sáng suốt. Xin chào!

Để sẵn sàng cuộc phiêu lưu làm sáng tỏ cho những đội ngũ developer, tôi đã mời được kỹ thuật viên SEO đồng thời là người hâm mộ Google Data Studio Rachel Anderson. Cùng nhau, hy vọng sẽ thực hiện các nỗ lực cải thiện hiệu suất từ “biến các con số xanh” đến một số mục hành động rõ ràng và có ý nghĩa.

Mục tiêu đề:

• Lighthouse là cái gì? (Trong trường hợp không biết và ngại hỏi.)
• Cập nhật cách tính Điểm hiệu quả (bản 6 và 7).
• Cách kiểm tra hiệu quả bằng Lighthouse.
• Các chỉ số tính điểm Hiệu quả của Lighthouse.
• Ý nghĩa.
• Cách cải thiện.

1. Lighthouse là gì?

Lighthouse là một công cụ kiểm định mã nguồn mở cung cấp điểm số được tiêu chuẩn hóa trên 5 lĩnh vực:

• Hiệu quả.
• Tiến trình ứng dụng web.
• Phương pháp thực hành tốt.
• Khả năng tiếp cận.
• SEO.

Với mục đích của bài viết này, sử dụng tên Lighthouse để chỉ chuỗi kiểm tra được thực hiện bởi repo Github được chia sẻ, bất kể phương pháp thực thi là gì. SEO Lighthouse chạy các bài kiểm tra hiệu suất bằng cách sử dụng dữ liệu giả lập, còn được gọi là dữ liệu thí nghiệm.

Đây là dữ liệu hiệu quả được thu thập trong môi trường kiểm soát bởi thiết lập mạng và thiết bị dự đoán. Dữ liệu thí nghiệm hữu ích để gỡ lỗi các vấn đề về hiệu quả. Điều đó không có nghĩa là trải nghiệm trên máy trong môi trường được kiểm soát sẽ đại diện cho trải nghiệm thực trong môi trường hoang dã.

2. Đợt cập nhật Lighthouse: Web Core Vital

Ngày 5 tháng 5 năm 2020, dự án Chromium đã công bố ba chỉ số trình duyệt nguồn mở Google sẽ đo lường hiệu suất. Các chỉ số, được gọi là Web Vitals, là một phần của sáng kiến ​​Google được thiết kế để cung cấp hướng dẫn thống nhất cho các tín hiệu chất lượng.

Mục tiêu của các chỉ số này là đo lường hiệu suất web theo cách lấy người dùng làm trung tâm. Trong vòng hai tuần, Lighthouse v6 ra mắt với phiên bản sửa đổi của Web Core Vitals là trung tâm của bản cập nhật.

Tháng 7 năm 2020 chứng kiến ​​các chỉ số thống nhất của Lighthouse v6 được áp dụng trên các sản phẩm của Google với việc phát hành Chrome 84. Bảng điều khiển Kiểm tra Chrome DevTools được đổi tên thành Lighthouse. Thông tin chi tiết về tốc độ trang và Google Search Console cũng tham khảo các chỉ số thống nhất này.

Web Core Vitals chiếm 55% điểm hiệu quả của SEO Lighthouse. Sự thay đổi về trọng tâm này đặt ra những mục tiêu mới, tinh tế hơn. Nhìn chung, hầu hết các trang đều có tác động tối thiểu với 83,32% bài kiểm tra chuyển từ điểm mười trở xuống khi chuyển sang phiên bản v6. Phiên bản 7 hiện đã ra mắt trên Github và dự kiến ​​phát hành trên quy mô lớn với bản phát hành Chrome 89 ổn định vào tháng 3 năm 2021.

3. Kiểm tra hiệu quả SEO Lighthouse

Vấn đề về phương pháp

SEO Lighthouse còn có thể kiểm tra một trang duy nhất một lần. Một điểm số trang không đại diện cho trang web và một trang chủ nhanh không có nghĩa là một trang web nhanh. Kiểm tra nhiều loại trang trong trang web. Xác định các loại trang, mẫu và điểm chuyển đổi mục tiêu chính (trang đăng ký, đăng ký và thanh toán).

Ví dụ mẫu kiểm tra trang

URL	Page Type
/	Homepage
/tools	Category Template
/tools/screwdrivers	Product Listing Page Template
/acme/deluxe-anvil	Product Detail Page Template
/cart	Cart
/checkout	Checkout
/order-confirmation	Order confirmation
/blog	Blog Root
/blog/roadrunners-101	Blog Template

Trước khi bắt đầu tối ưu hóa, chạy SEO Lighthouse trên từng trang mẫu và lưu dữ liệu báo cáo. Ghi lại điểm số và danh sách việc cần làm của các cải tiến. Ngăn mất dữ liệu bằng cách lưu kết quả JSON và sử dụng Lighthouse Viewer khi cần thông tin chi tiết về kết quả.

Sử dụng ROI để lấy Backlog phản lại

Rất khó để có được các nguồn lực phát triển để thực hiện các đề xuất SEO. SEO nội bộ có thể phá hủy tuyến tụy của họ bằng cách có một chiếc bánh sinh nhật cho mỗi sinh nhật của vé tồn đọng. Hoặc ít nhất là học cách ghét bánh ngọt.

Với tư cách là SEO trong doanh nghiệp, mẹo để các sáng kiến ​​hiệu suất được ưu tiên là có những con số để hỗ trợ đầu tư. Dữ liệu ban đầu sẽ trở thành các ký hiệu đô la dùng để biện minh và khen thưởng cho những nỗ lực phát triển.

Có thể có nhiều hơn một khu vực được gắn cờ trong quá trình kiểm tra. Không sao đâu! Nếu còn băn khoăn không biết thay đổi nào sẽ mang lại hiệu quả cao nhất, hãy xem Máy tính điểm của SEO Lighthouse.

4. Cách chạy kiểm tra SEO Lighthouse

Đây là một trường hợp của nhiều con đường dẫn đến Oz. Chắc chắn có thể đặc biệt ồn ào nhưng đó là về mục tiêu. Tìm cách tích hợp các bài kiểm tra SEO vào quá trình phát hành? Đến lúc tìm hiểu một số NPM.

Có ít hơn năm phút để chuẩn bị cho một cuộc họp khách hàng tiềm năng? Một vài báo cáo một lần sẽ thực hiện hóa được. Dù theo cách nào, mặc định là phiên bản di động trừ khi là một trường hợp đặc biệt máy tính để bàn.

Đối với báo cáo một lần: Chrome Devtools

Kiểm tra từng trang một với bảng điều khiển SEO Lighthouse trong Chrome DevTools. Bởi vì báo cáo sẽ mô phỏng trải nghiệm của người dùng bằng trình duyệt, hãy sử dụng phiên bản ẩn danh với tất cả các tiện ích mở rộng và bộ nhớ cache của trình duyệt bị tắt.

Mẹo: Tạo hồ sơ Chrome để thử nghiệm. Giữ nó cục bộ (không bật đồng bộ hóa, lưu mật khẩu hoặc liên kết với tài khoản Google hiện có) và không cài đặt tiện ích mở rộng cho người dùng.

Cách chạy SEO Lighthouse bằng Chrome DevTools

1. Mở phiên bản ẩn danh của Chrome.
2. Điều hướng đến bảng điều khiển Mạng của Chrome Dev Tools (Command + Option + I trên Mac hoặc Control + Shift + I trên Windows và Linux).
3. Đánh dấu vào hộp để tắt cache.
4. Điều hướng đến bảng panel Lighthouse.
5. Tạo Báo cáo.
6. Lưu các tập tin.

Ưu điểm chạy Lighhouse bằng DevTools

• Có thể kiểm tra các bản dựng cục bộ và các trang được xác thực.
• Có thể so sánh các báo cáo đã lưu bằng công cụ Lighthouse CI Diff.

Nhược điểm chạy Lighthouse bằng DevTool

• Chỉ được 1 báo cáo 1 lần
• Yêu cầu lưu thủ công

5. Thường xuyên kiểm tra các trang giống nhau: web.dev

Giống như DevTools nhưng không cần phải tắt tất cả các tiện ích mở rộng khó chịu đó!

• Truy cập web.dev/measure/.
• Đăng nhập bằng tài khoản Google.
• Nhập URL.
• Nhấp vào Chạy kiểm tra.

Ưu điểm của Running Lighthouse Từ web.dev

• Nắm bắt một mốc thời gian thuận tiện của kết quả! (Miễn là đã đăng nhập).
• Liên kết nhanh đến hướng dẫn để cải thiện vấn đề
• Có thể so sánh các báo cáo đã lưu bằng công cụ Lighthouse CI Diff.

Nhược điểm của Running Lighthouse Từ web.dev

• Một báo cáo tại một thời điểm.
• Cần nhớ những URL nào đang theo dõi theo thời gian.

Kiểm tra ở quy mô: Dòng lệnh

1. Cài đặt npm.
   (Mẹo dành cho Mac Pro: Sử dụng homebrew để tránh các vấn đề phụ thuộc đáng ghét.)
2. Cài đặt mô-đun nút Lighthouse
   npm install -g lighthouse
3. Chạy văn bản
   lighthouse
4. Chạy thử nghiệm trên danh sách sử dụng bằng cách chạy thử nghiệm theo chương trình.

Ưu điểm của việc chạy SEO Lighthouse từ nút

• Nhiều báo cáo có thể được chạy cùng một lúc.
• Có thể được thiết lập để chạy tự động để theo dõi sự thay đổi theo thời gian.

Nhược điểm của việc chạy SEO Lighhouse từ nút

• Yêu cầu một số kiến ​​thức mã hóa.
• Thiết lập tốn nhiều thời gian hơn.
• Giải thích các chỉ số hiệu suất của Lighthouse

6. Các chỉ số hiệu suất của Lighthouse cho các SEO kỹ thuật

Trong phiên bản 6 và 7, điểm hiệu suất của Lighthouse bao gồm bảy chỉ số với mỗi chỉ số đóng góp một tỷ lệ phần trăm trong tổng điểm hiệu suất.

Metric Name	Weight
Largest Contentful Paint (LCP)	25%
Total Blocking Time (TBT)	25%
First Contentful Paint (FCP)	15%
Speed Index (SI)	15%
Time To Interactive (TTI)	15%
Cumulative Layout Shift (CLS)	5%

Phần trăm điểm của Lighthouse Performance: 25%

Vật đo lường: Điểm trong dòng thời gian tải trang khi hình ảnh hoặc khối văn bản lớn nhất của trang hiển thị trong chế độ xem.

Cách đo lường: Lighthouse trích xuất dữ liệu LCP từ công cụ theo dõi của Chrome.

LCP có phải là cốt lõi web không? Đúng!

Chấm điểm LCP

Mục tiêu: đạt được LCP trong

LCP (giây)	Mã màu
0-2,500	Xanh (Nhanh)
2,500-4,000	Cam (Trung bình)
Hơn 4,000	Đỏ (Chậm)

Yếu tố góp thành LCP?

• Bản văn.
• Hình ảnh.
• Các video.
• Hinh nên.

Điều gì được coi là LCP trên Trang?

Tùy trường hợp! LCP thường thay đổi theo mẫu trang.Điều này có nghĩa là đo lường một số trang sử dụng cùng một mẫu và xác định LCP.

Cách xác định LCP bằng Chrome Devtools

• Mở trang trong Chrome.
• Điều hướng đến bảng Hiệu suất của Công cụ Dev (Command + Option + I trên Mac hoặc Control + Shift + I trên Windows và Linux).
• Di chuột qua điểm đánh dấu LCP trong phần Thời gian.
• Phần tử tương ứng với LCP được nêu chi tiết trong trường Nút liên quan.

Nguyên nhân nào gây ra LCP kém?

LCP kém thường xuất phát từ bốn vấn đề:

1. Thời gian phản hồi của máy chủ chậm.
2. JavaScript và CSS chặn hiển thị.
3. Thời gian tải nguồn.
4. Kết xuất phía máy khách.

Cách khắc phục LCP

Nếu nguyên nhân là do thời gian phản hồi của máy chủ chậm:

• Tối ưu hóa máy chủ.
• Hướng người dùng đến một CDN gần đó.
• Nội dung bộ nhớ đệm.
• Cung cấp bộ nhớ cache các trang HTML trước tiên.
• Thiết lập các kết nối của bên thứ ba sớm.

Nếu nguyên nhân là do JavaScript và CSS chặn:

• Giảm thiểu CSS.
• Trì hoãn CSS không quan trọng.
• Nội tuyến CSS quan trọng.
• Giảm thiểu và nén các tệp JavaScript.
• Trì hoãn JavaScript không sử dụng.
• Giảm thiểu các polyfills không sử dụng.

Nếu nguyên nhân là do thời gian tải tài nguyên:

• Tối ưu hóa và nén hình ảnh.
• Tải trước các tài nguyên quan trọng.
• Nén tệp văn bản.
• Phân phối các nội dung khác nhau dựa trên kết nối mạng (phân phát thích ứng).
• Lưu trữ nội dung vào bộ nhớ cache bằng service worker.

Nếu nguyên nhân là do hiển thị phía máy khách:

• Giảm thiểu JavaScript quan trọng.
• Sử dụng một chiến lược kết xuất khác (Xem bảng phân tích các tùy chọn kết xuất trong Hướng dẫn về góc độ).

Nguồn cải thiện LCP

• Largest Contentful Paint (LCP) web.dev.
• Optimize Largest Contentful Paint web.dev.
• Lighthouse Largest Contentful Paint web.dev.

7. ổng thời gian chặn (TBT)

Đại diện: Khả năng đáp ứng với đầu vào của người dùng

Phần trăm diểm của Lighthouse Performance: 25%

Vật đo lường: TBT đo thời gian giữa Bức tranh có nội dung đầu tiên và Thời gian để tương tác. TBT tương đương với phòng thí nghiệm của Độ trễ nhập liệu đầu tiên (FID) – dữ liệu trường được sử dụng trong Báo cáo trải nghiệm người dùng Chrome và tín hiệu xếp hạng Trải nghiệm trang sắp tới của Google.

Cách đo lường: Tổng thời gian trong đó luồng chính bị chiếm bởi các tác vụ mất hơn 50 mili giây để hoàn thành. Nếu một nhiệm vụ mất 80 mili giây để chạy, 30 mili giây thời gian đó sẽ được tính vào TBT. Nếu một nhiệm vụ mất 45ms để chạy, 0ms sẽ được thêm vào TBT.

TBT có phải là quan trọng của Web Core không? Đúng! Đây là dữ liệu phòng thí nghiệm tương đương với Độ trễ đầu vào đầu tiên (FID).

Chấm điểm TBT

Mục tiêu: đạt được điểm TBT dưới 300 mili giây.

Thời gian (Mili giây)	Mã Màu
0-300	Xanh (Nhanh)
301-600	Cam (Trung bình)
Trên 600	Đỏ (Chậm)

Thời gian (Mili giây)	Mã Màu
0-100	Xanh (Nhanh)
101-300	Cam (Trung bình)
Trên 300	Đỏ (Chậm)

Task dài hạn & Tổng thời gian chặn

TBT đo lường các nhiệm vụ dài — những nhiệm vụ kéo dài hơn 50ms. Khi một trình duyệt tải trang web, về cơ bản sẽ có một hàng đợi tập lệnh duy nhất.

Bất kỳ đầu vào nào từ người dùng phải vào cùng hàng đợi đó. Khi trình duyệt không thể phản hồi thông tin nhập của người dùng vì các tác vụ khác đang thực thi, người dùng sẽ coi đây là độ trễ.

Các task dài giống như một người ở quán cà phê yêu thích , người mất quá nhiều thời gian để gọi đồ uống. Giống như ai đó đặt mua vani 4 bơm 2% venti, mocha 5 bơm nguyên chất béo, các task kéo dài là một nguồn chính của trải nghiệm tồi tệ.

Nguyên nhân nào khiến TBT cao trên trang ?

JavaScript quá nặng. Chính nó.

Cách xem TBT bằng Chrome Devtools

1. Mở trang trong Chrome.
2. Điều hướng đến bảng Hiệu suất của Công cụ Dev (Command + Option + I trên Mac hoặc Control + Shift + I trên Windows và Linux).
3. Nhấp vào nút tải lại để bắt đầu theo dõi hiệu suất.
4. Tìm các điểm đánh dấu màu đỏ ở góc bên phải của nhiệm vụ. Chúng cho biết các tác vụ dài mất hơn 50 mili giây

Cách khắc phục TBT kém

• Chia tay Nhiệm vụ dài.
• Tối ưu hóa trang để sẵn sàng tương tác.
• Sử dụng nhân viên web.
• Giảm thời gian thực thi JavaScript.

Nguồn cải thiện TBT

• First Input Delay (FID) web.dev.
• Total Blocking Time (TBT) web.dev.
• Optimize First Input Delay web.dev.
• Lighthouse: Total Blocking Time web.dev.

8. First Contentful Paint (FCP)

Đại diện: FCP đánh dấu thời gian mà văn bản hoặc hình ảnh đầu tiên được vẽ (hiển thị).

Phần trăm điểm của Lighthouse Performance: 15%

Vật đo lường: Thời gian mà có thể thấy trang yêu cầu đang phản hồi. Ngón tay cái có thể ngừng di chuột qua nút quay lại.

Cách đo lường: Điểm FCP trong Lighthouse được đo bằng cách so sánh FCP trên trang với thời gian FCP cho dữ liệu trang web thực được Lưu trữ HTTP lưu trữ. FCP tăng nếu nó nhanh hơn các trang khác trong HTTP Archive.

First Contentful Paint có phải là Web Core Vital? Không

Chấm điểm FCP

Mục tiêu: đạt được FCP trong

Thời gian (giây)	Mã màu	Điểm (Phần trăm HTTP)
0-2	Xanh (Nhanh)	7-100
2-4	Cam (Trung bình)	50-74
4	Đỏ (chậm)	0-49

Những yếu tố nào là một phần của FCP?

Thời gian cần thiết để hiển thị phần tử hiển thị đầu tiên cho DOM là FCP. Bất kỳ điều gì xảy ra trước một phần tử hiển thị nội dung không phải màu trắng cho trang (không bao gồm iframe) đều được tính vào FCP. Vì iframe không được coi là một phần của FCP, nếu chúng là nội dung đầu tiên hiển thị, FCP sẽ tiếp tục tính cho đến khi tải nội dung không phải iframe đầu tiên, nhưng thời gian tải iframe không được tính vào FCP. Tài liệu xung quanh FCP cũng chỉ ra rằng thường bị ảnh hưởng bởi thời gian tải phông chữ và có các mẹo để cải thiện tải phông chữ.

Cách xác định FCP bằng Chrome Devtools

1. Mở trang trong Chrome.
2. Điều hướng đến bảng Hiệu suất của Công cụ Dev (Command + Option + I trên Mac hoặc Control + Shift + I trên Windows và Linux).
3. Nhấp vào điểm đánh dấu FCP trong phần Thời gian.
4. Tab tóm tắt có dấu thời gian với FCP tính bằng mili giây.

Cách cải thiện FCP

Để nội dung được hiển thị cho người dùng, trước tiên trình duyệt phải tải xuống, phân tích cú pháp và xử lý tất cả các biểu định kiểu bên ngoài mà nó gặp phải trước khi có thể hiển thị hoặc hiển thị bất kỳ nội dung nào lên màn hình của người dùng.

Cách nhanh nhất để bỏ qua sự chậm trễ của tài nguyên bên ngoài là sử dụng các kiểu nội dòng cho nội dung trong màn hình đầu tiên. Để giữ cho trang web có thể mở rộng một cách bền vững, hãy sử dụng một công cụ tự động như penthouse và Apache’s mod_pagespeed. Các giải pháp này sẽ đi kèm với một số hạn chế đối với các chức năng, yêu cầu thử nghiệm và có thể không dành cho tất cả mọi người.

Nói chung, tất cả chúng ta đều có thể cải thiện thời gian của trang web của mình lên First Contentful Paint bằng cách giảm phạm vi và độ phức tạp của các phép tính kiểu. Nếu một kiểu không được sử dụng, hãy xóa kiểu đó. Xác định CSS không sử dụng chức năng Bảo hiểm mã tích hợp của Chrome Dev Tool.

Sử dụng dữ liệu tốt hơn để đưa ra quyết định tốt hơn. Tương tự như TTI, cũng có thể nắm bắt số liệu người dùng thực cho FCP bằng việc xài Google Analytics để cải thiện tương quan với KPI.

9. Speed Index (Tạm dịch: Tốc độ Index)

Đại diện: số lượng hiển thị tại một thời điểm trong khi tải.

Trọng số điểm của Lighthouse Performance: 15%

Đại diện: Tốc độ Index là thời gian trung bình mà các phần có thể nhìn thấy của trang được hiển thị.

Cách đo lường: Đo lường Chỉ số tốc độ của Lighthouse đến từ một mô-đun nút có tên là Đường tốc độ.

Speed ​​Index có phải là Web Core Vital không? Không

Tính điểm SI

Mục tiêu: đạt được SI trong

Thời gian (Giây)	Mã Màu	Điểm FCP (Phần trăm HTTP)
0-4.3	Xanh (Nhanh)	75-100
4.4-5.8	Cam (Trung Bình)	50-74
5.8+	Đỏ (Chậm)	0-49

Đường dẫn càng dài và dày đặc, trang web cung cấp trang trực quan càng chậm. Nếu đường dẫn được tối ưu hóa, sẽ cung cấp cho người dùng nội dung nhanh hơn và đạt điểm cao hơn trên tốc độ Index.

Những ảnh hưởng tác động:

• Giảm thiểu công việc của chuỗi chính.
• Giảm thời gian thực thi JavaScript.
• Giảm thiểu độ sâu của các yêu cầu quan trọng.
• Loại bỏ tài nguyên chặn kết xuất.
• Trì hoãn hình ảnh ngoài màn hình.
• Thời gian tương tác
• Những gì nó thể hiện: Khả năng đáp ứng tải; xác định vị trí một trang trông có vẻ phản hồi nhưng chưa đáp ứng.

Phần trăm điểm của Lighthouse Performance: 15%

Vật đo lường: Thời gian từ khi trang bắt đầu tải đến khi các tài nguyên chính của nó đã tải và có thể phản hồi thông tin nhập của người dùng.

Cách đo lường: TTI đo lường thời gian một trang trở nên tương tác hoàn toàn. Một trang được coi là tương tác hoàn toàn khi:

• Trang hiển thị nội dung hữu ích, được đo lường bằng First Contentful Paint.
• Trình xử lý sự kiện được đăng ký cho hầu hết các phần tử trang hiển thị.
• Trang phản hồi các tương tác của người dùng trong vòng 50 mili giây.

Thời gian tương tác có phải là điều quan trọng nhất của Web Core không? Không

Chấm điểm TTI

Mục tiêu: đạt được điểm TTI dưới 3,8 giây.

Điểm TTI (Theo giây)	Mã màu
0-3.8	Xanh (Nhanh)
3.8-7.3	Cam (Trung bình)
7.3+	Đỏ (Chậm)

Dịch chuyển bố cục tích lũy (CLS)

Nội dung thể hiện: Nhận thức của người dùng về tính ổn định trực quan của trang.

Trọng số điểm Hiệu quảt của Lighthouse: 5% *

• Mong đợi CLS tăng trọng số khi chúng giải quyết các lỗi. Đặt cược thông minh cho biết quý 4 năm 2021.

Vật đo lường: Nó định lượng các phần tử trang thay đổi thông qua tải trang cuối.

Cách đo lường: Không giống như các chỉ số khác, CLS không được đo lường theo thời gian. Thay vào đó, đây là chỉ số được tính toán dựa trên số khung hình mà các phần tử di chuyển và tổng khoảng cách tính bằng pixel mà các phần tử đã di chuyển.

Chấm điểm CLS

Mục tiêu: đạt được điểm CLS dưới 0,1.

Điểm CLS	Mã Màu
0-0.01	Xanh (Tốt)
0.1-0.25	Cam (Cần cải thiện)
0.25+	Đỏ (Tệ)

Những yếu tố nào có thể là một phần của CLS?

Bất kỳ yếu tố hình ảnh nào xuất hiện trong màn hình đầu tiên tại một số thời điểm trong tải. Đúng vậy – nếu tải chân trang của mình trước rồi mới đến nội dung chính của trang, CLS bị ảnh hưởng.

Nguyên nhân của CLS kém

• Hình ảnh không có kích thước.
• Quảng cáo, nhúng và iframe không có thứ nguyên.
• Nội dung được tiêm động.
• Phông chữ web gây ra FOIT / FOUT.
• Các hành động chờ phản hồi mạng trước khi cập nhật DOM.

Cách xác định CLS bằng Chrome Devtools

1. Mở trang trong Chrome.
2. Điều hướng đến bảng Hiệu suất của Công cụ Dev (Command + Option + I trên Mac hoặc Control + Shift + I trên Windows và Linux).
3. Di chuột và di chuyển từ trái sang phải trên ảnh chụp màn hình của tải (đảm bảo hộp kiểm ảnh chụp màn hình được chọn).
4. Để ý các phần tử nảy xung quanh để xác định các phần tử gây ra CLS.

Cách cải thiện CLS

Sau khi xác định (các) phần tử bị lỗi, cập nhật chúng để ổn định trong quá trình tải trang.

Ví dụ: nếu quảng cáo tải chậm đang gây ra điểm CLS cao, sử dụng hình ảnh giữ chỗ có cùng kích thước để lấp đầy không gian đó khi quảng cáo tải để ngăn chuyển trang.

Một số cách phổ biến để cải thiện CLS bao gồm:

• Luôn bao gồm các thuộc tính kích thước chiều rộng và chiều cao trên hình ảnh và phần tử video.
• Dành không gian cho các vùng quảng cáo (và đừng thu gọn nó).
• Tránh chèn nội dung mới lên trên nội dung hiện có.
• Hãy cẩn thận khi đặt quảng cáo không dính ở gần đầu khung nhìn.
• Tải trước phông chữ.

Nguồn CLS

• Optimize Cumulative Layout Shift web.dev.
• Cumulative Layout Shift (CLS) web.dev.
• Cumulative Layout Shift (CLS) in AMP – The AMP Blog.
• Cumulative Layout Shift (CLS) Calculator.

Kết luận

Sự phức tạp của số liệu hiệu quả phản ánh những thách thức mà tất cả các trang web phải đối mặt. Sử dụng số liệu hiệu suất làm proxy cho trải nghiệm người dùng – điều đó có nghĩa là bao thanh toán trong một số kỳ lân. Các công cụ như Kiểm tra trang web của Google và Chi phí trang web là gì? có thể giúp đưa ra các lập luận tập trung vào chuyển đổi và khách hàng để biết tại sao hiệu suất lại quan trọng.

Hy vọng rằng khi dự án có sức hút, những định nghĩa này sẽ giúp chuyển chỉ số hiệu quả đơn lẻ của SEO Lighthouse thành vé hành động cho một nhóm kỹ sư có kỹ năng và cộng tác. Theo dõi dữ liệu và đọc từ các mái nhà. Khi Google định lượng trải nghiệm định tính, các chuyên gia SEO và developer phải giải mã. Kiểm tra, lặp lại và chia sẻ những gì đã học! Rất mong được thấy khả năng, thân chào.

Nguồn: searchenginejournal.com