Google đang thực hiện sứ mệnh cải thiện hiệu suất web với Core Web Vitals. Tại sao? Bởi vì hoạt động kinh doanh của Google chủ yếu dựa trên web – các trang web và ứng dụng web chậm đẩy người dùng quay lại các ứng dụng gốc.
Vị trí của bạn trong kết quả tìm kiếm của Google phần lớn được xác định bởi các từ khóa của cụm từ tìm kiếm, việc sử dụng các từ khóa đó trong trang của bạn và mức độ phổ biến của trang tùy theo số lượng (và chất lượng) của các liên kết từ nơi khác. Từ tháng 8 năm 2021, Google cũng đang nỗ lực đánh giá các trang dựa trên hiệu suất.
Bài viết này sẽ chỉ cho bạn cách bạn có thể tối ưu hóa trang web của mình cho các chỉ số Core Web Vitals của Google.
Tại sao Core Web Vitals?
Nội dung vẫn quan trọng. Nhưng nếu bạn so sánh hai trang web có văn bản và mức độ phổ biến tương tự nhau, trang nào mang lại trải nghiệm web tốt nhất sẽ được ưu tiên cao hơn trong kết quả tìm kiếm của Google.
Cũng như xếp hạng trang được cải thiện, các trang web hiệu suất cao đủ điều kiện để đưa vào băng chuyền tìm kiếm trên điện thoại di động. Điều này trước đây được dành riêng cho các Trang trên thiết bị di động được tăng tốc (AMP), yêu cầu bạn chuyển nội dung vào một trang web được lưu trữ riêng biệt do Google lưu trữ. AMP đã bị chỉ trích, đặc biệt là vì các trang không phải lúc nào cũng nhanh hơn một trang web tĩnh hoặc WordPress được tối ưu hóa tốt. Tuy nhiên, đó không phải là một yêu cầu nữa.
Bất kể bạn đã chọn gì, trang web của bạn càng nhanh và phản hồi nhanh thì càng có cơ hội xếp hạng cao hơn trong kết quả tìm kiếm của Google.
Khi bạn xem xét trang trung bình khoảng 2 MB, thực hiện hơn 60 yêu cầu HTTP và mất 16 giây để hiển thị đầy đủ trên thiết bị di động, bạn sẽ thấy có một số phạm vi để cải thiện trang web của mình. Chúng tôi sẽ chỉ cho bạn những cách tốt nhất để đạt được những cải tiến đó.
Các yếu tố xếp hạng chính của Google
Có bốn yếu tố xếp hạng chính cần kiểm tra trước khi bạn bắt đầu đánh giá hiệu suất:
- HTTPS: HTTPS là điều cần thiết. Trang web của bạn có thiết lập kết nối an toàn giữa trình duyệt của người dùng và máy chủ web không?
- Thân thiện với thiết bị di động: Trang web của bạn phải hoạt động tốt trên thiết bị di động. Trang web của bạn có thể sử dụng được trên các thiết bị màn hình nhỏ không? Nó có hiển thị mà không bị tràn nội dung không? Văn bản có đủ lớn không? Các khu vực có thể nhấp có đủ để điều khiển cảm ứng không?
- Không có quảng cáo xen kẽ: Tránh các quảng cáo xen kẽ xâm nhập yêu cầu một lượng không gian màn hình không hợp lý. Nội dung của bạn luôn có thể đọc được? Nó có bị che khuất một phần bởi quảng cáo chuyển tiếp hoặc biểu ngữ bật lên không? Các chương trình khuyến mãi quảng cáo hoặc tiếp thị của bạn có khiến trang web khó sử dụng không?
- Duyệt web an toàn: Trang web của bạn phải không có phần mềm độc hại, vi rút, lừa đảo, gian lận và các trò gian lận khác.
Khi bạn đáp ứng các yêu cầu này, trang web của bạn sẽ được đánh giá về hiệu suất.
Google đánh giá hiệu suất web như thế nào?
Làm cho trang web của bạn tải nhanh, hiển thị nhanh và phản hồi sớm hơn là điều quan trọng. Nhưng nó có cảm thấy nhanh cho người dùng không?
Các ứng dụng đo lường hiệu suất như DevTools của trình duyệt báo cáo các phép đo kỹ thuật như:
- Thời gian chặn: Thời gian chờ đợi bắt đầu tải xuống, thường là do các nội dung khác như bảng định kiểu và tập lệnh có mức độ ưu tiên cao hơn.
- Độ phân giải DNS: Thời gian phân giải tên máy chủ thành địa chỉ IP để truy xuất nội dung.
- Thời gian kết nối: Thời gian khởi tạo kết nối TCP.
- Time to First Byte (TTFB): Tổng thời gian giữa yêu cầu và byte đầu tiên của phản hồi.
- Thời gian nhận: Thời gian lấy toàn bộ tài sản.
- Thời gian tải DOM: Thời gian tải xuống và hiển thị Mô hình đối tượng tài liệu HTML. Đây thường là điểm đầu tiên mà tại đó các tập lệnh phân tích hoặc sửa đổi DOM có thể chạy một cách đáng tin cậy.
- Thời gian tải trang: Thời gian tải trang và tất cả nội dung như hình ảnh, bảng định kiểu, tập lệnh, v.v.
- Tổng trọng lượng trang: Tổng kích thước của tất cả nội dung. Nó thường được báo cáo ở cả kích thước nén (tải xuống) và kích thước không nén.
- Số lượng phần tử DOM: Tổng số phần tử HTML trên trang. Càng nhiều phần tử, thời gian xử lý trang càng lâu.
- Sơn nội dung đầu tiên (FCP): Thời gian thực hiện trước khi trình duyệt hiển thị pixel nội dung đầu tiên.
- Bức tranh có ý nghĩa đầu tiên (FMP): Thời gian thực hiện trước khi nội dung trang chính hiển thị cho người dùng.
- Thời gian tương tác (TTI): Thời gian thực hiện trước khi một trang hoàn toàn tương tác và có thể phản hồi thông tin người dùng nhập một cách đáng tin cậy.
- CPU đầu tiên không hoạt động: Thời gian để CPU hiển thị trang và chạy tất cả các tập lệnh khởi tạo, chờ đầu vào thêm.
- Sử dụng CPU: Hoạt động xử lý cần thiết trong khi hiển thị trang và phản hồi thông tin nhập của người dùng.
- Bố cục mỗi giây: Tốc độ trình duyệt phải tính toán lại các kiểu và bố cục trang.
Chúng có thể được sử dụng để xác định các tắc nghẽn cụ thể như tải máy chủ, bộ nhớ đệm CMS, bộ nhớ đệm của trình duyệt, tốc độ tải xuống và hiệu quả JavaScript. Nhưng họ không thể xác định liệu một trang cung cấp trải nghiệm người dùng tốt hay xấu. Ví dụ:
- Một ứng dụng có thể tải xuống và xuất hiện nhanh chóng nhưng không phản hồi sau lần tương tác đầu tiên vì nó đang thực thi một lượng lớn mã JavaScript chưa được tối ưu hóa.
- Một ứng dụng trò chuyện có thể liên tục tải xuống dữ liệu khi người dùng đăng tin nhắn. Một công cụ đánh giá có thể cho rằng nó chưa bao giờ tải xong, mặc dù trang có cảm giác phản hồi.
Core Web Vitals là nỗ lực của Google để giải quyết những tình huống khó xử này.
Core Web Vitals là gì?
Core Web Vitals (CWV) của Google là ba chỉ số hiệu suất đánh giá trải nghiệm người dùng trong thế giới thực:
- Sơn có nội dung lớn nhất (LCP): Hiệu suất tải
- Độ trễ đầu vào đầu tiên (FID): Hiệu suất tương tác
- Dịch chuyển bố cục tích lũy (CLS): Hiệu suất ổn định hình ảnh
Bản cập nhật thuật toán mới này của Google đã bắt đầu triển khai trên toàn cầu vào cuối tháng 8 năm 2021. Các chỉ số Core Web Vitals chủ yếu ảnh hưởng đến kết quả tìm kiếm trên thiết bị di động, nhưng các tính năng tương đương trên máy tính để bàn sẽ tuân theo nếu thử nghiệm thành công.
Điểm số LCP, FID và CLS của một trang dựa trên số liệu người dùng thực trong 28 ngày qua được thu thập ẩn danh thông qua trình duyệt Chrome. Các phép đo này có thể thay đổi do thiết bị, kết nối và các hoạt động đồng thời khác của người dùng, vì vậy phân vị thứ 75 được tính thay vì trung bình.
Nói cách khác, các chỉ số từ tất cả người dùng được sắp xếp từ tốt nhất đến kém nhất và con số ở điểm ba phần tư được lấy. Do đó, ba trong số bốn khách truy cập trang web sẽ trải nghiệm mức hiệu suất đó hoặc tốt hơn.
Bất kỳ trang nào đạt được điểm tốt (màu xanh lá cây) cho cả ba chỉ số Core Web Vitals sẽ nhận được xếp hạng cao hơn trong kết quả tìm kiếm và được đưa vào băng chuyền “Tin bài hàng đầu” trong ứng dụng Google Tin tức.
Trong các phần sau, chúng tôi sẽ mô tả thuật toán được sử dụng để tính toán một số liệu, các công cụ bạn có thể sử dụng để xác định điểm của một trang, nguyên nhân điển hình của điểm thấp và các bước bạn có thể thực hiện để giải quyết các vấn đề về hiệu suất.
Sơn có nội dung lớn nhất (LCP)
Sơn có nội dung lớn nhất đo lường hiệu suất tải. Về bản chất, nội dung có thể sử dụng được hiển thị trên trang nhanh như thế nào?
LCP phân tích mất bao lâu để hình ảnh hoặc khối văn bản lớn nhất hiển thị trong chế độ xem của trình duyệt (trong màn hình đầu tiên). Trong hầu hết các trường hợp, mục nổi bật nhất sẽ là hình ảnh anh hùng, biểu ngữ, tiêu đề hoặc khối văn bản lớn.
Bất kỳ yếu tố nào sau đây đều đủ điều kiện để phân tích Sơn có nội dung lớn nhất:
- hình ảnh (phần tử
<img>
) - hình ảnh bên trong đồ họa vector (một
<image>
được nhúng vào<svg>
) - hình thu nhỏ video (thuộc tính áp phích được đặt thành URL hình ảnh trong phần tử
<video>
) - các phần tử có hình nền (thường được tải bằng thuộc tính CSS
background-image url()
) - các phần tử cấp khối có chứa văn bản
Các trang trong đó Sơn có nội dung lớn nhất được hoàn thành trong vòng 2,5 giây đầu tiên khi tải trang được coi là tốt (màu xanh lá cây). Các trang vượt quá 4,0 giây được coi là kém (màu đỏ):
Công cụ phân tích sơn có nội dung lớn nhất
LCP là chỉ số Core Web Vital dễ hiểu nhất, nhưng có thể không rõ phần tử nào sẽ được chọn để phân tích.
Bảng điều khiển DevTools Lighthouse được cung cấp trong các trình duyệt dựa trên Chromium như Chrome, Edge, Brave, Opera và Vivaldi. Mở DevTools từ menu trình duyệt – thường ở Công cụ khác > Công cụ dành cho nhà phát triển hoặc phím tắt Ctrl | Cmd + Shift + i hoặc F12 – sau đó điều hướng đến tab Lighthouse (các phiên bản cũ hơn có thể đặt tên là Audit ).
Tạo báo cáo Hiệu suất trên thiết bị di động, sau đó kiểm tra phần Hiệu suất kết quả. Thời gian Sơn có nội dung lớn nhất được hiển thị với phần có thể mở rộng, xác định phần tử đã chọn:

Bạn có thể tạo thông tin giống hệt nhau trong Công cụ đo tốc độ trang trực tuyến và công cụ đo lường web.dev nếu bạn không có quyền truy cập vào trình duyệt dựa trên Chromium:

Bảng Hiệu suất DevTools cũng hiển thị chỉ báo LCP. Để bắt đầu, hãy nhấp vào biểu tượng Bản ghi hình tròn, tải lại trang của bạn, sau đó nhấp vào nút Dừng để xem báo cáo. Nhấp vào biểu tượng LCP trong phần Thời gian để xác định phần tử và xem tóm tắt thống kê.

Tiện ích mở rộng Web Vitals có sẵn cho Google Chrome nhưng có thể được cài đặt trên hầu hết các trình duyệt dựa trên Chromium. Nó tính toán các chỉ số Core Web Vitals cho mỗi trang web bạn truy cập và biểu tượng của nó chuyển sang màu xanh lục, cam hoặc đỏ tùy thuộc vào kết quả. Bạn cũng có thể nhấp vào biểu tượng tiện ích mở rộng để xem thêm chi tiết LCP:

Search Console của Google hiện cung cấp phần Core Web Vitals nếu trang web của bạn được thêm vào làm thuộc tính. Báo cáo minh họa các chỉ số CWV đã thay đổi như thế nào theo thời gian. Lưu ý rằng nó không xác định các số liệu LCP cụ thể và chỉ các trang web có lưu lượng truy cập hợp lý mới có sẵn:

Báo cáo trải nghiệm người dùng Chrome cho phép bạn truy vấn số liệu thống kê sử dụng thực, bao gồm LCP trên các quốc gia, kết nối và thiết bị khác nhau, cho một URL cụ thể. Đây là một dự án công khai trên Google BigQuery, vì vậy bạn phải đăng ký tài khoản Google Cloud Platform và cung cấp chi tiết thanh toán. Một lần nữa, báo cáo sẽ chỉ hữu ích khi URL có mức lưu lượng truy cập hợp lý.
Cuối cùng, thư viện JavaScript web-vitals là một tập lệnh nhỏ 1 kB có thể tính toán LCP và các chỉ số Core Web Vital khác cho người dùng thực trên trang web trực tiếp của bạn. Vì nó có thể được tải xuống từ CDN, bạn có thể thêm tập lệnh sau vào HTML <head>
của mình:
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>My page</title> <script type="module"> import { getLCP } from 'https://unpkg.com/web-vitals?module'; getLCP(console.log); </script> <!-- rest of page -->
getLCP()
là một hàm không đồng bộ được chuyển qua một lệnh gọi lại được kích hoạt khi giá trị LCP đã được tính toán (mặc dù nó có thể không bao giờ kích hoạt nếu trang tải trong tab nền). Hàm gọi lại được truyền vào một đối tượng có chứa:
name
: tên của chỉ số (“LCP” trong trường hợp này)-
value
: giá trị được tính toán -
id
: một ID duy nhất đại diện cho số liệu này cho trang hiện tại -
delta
: delta giữa giá trị hiện tại và giá trị được báo cáo cuối cùng -
entries
: một mảng các mục được sử dụng để tính toán giá trị
Tập lệnh ở trên xuất đối tượng ra bảng điều khiển, mặc dù việc gửi dữ liệu đến máy chủ hoặc Google Analytics để phân tích thêm sẽ thực tế hơn.
Đăng kí để nhận thư mới
Nguyên nhân phổ biến của điểm sơn có nội dung lớn nhất kém
Điểm LCP kém thường do các trang tải chậm khiến khối lớn nhất không xuất hiện nhanh chóng:
- Phản hồi của máy chủ có thể chậm vì nó quá tải hoặc làm quá nhiều việc để hiển thị một trang. Đây có thể không nhất thiết là lỗi của trang web của bạn – có thể là do các hạn chế của máy chủ nếu bạn đang sử dụng dịch vụ lưu trữ được chia sẻ.
- CSS và JavaScript chặn hiển thị có thể trì hoãn việc tải trang nếu chúng được tham chiếu trong HTML phía trên nội dung chính.
- Các tài nguyên khác như hình ảnh và video lớn có thể làm giảm băng thông khả dụng và mất nhiều thời gian hơn để hiển thị.
- Nội dung trang được tạo trên máy khách thay vì máy chủ cũng mất nhiều thời gian hơn để xuất hiện.
Cách cải thiện điểm số sơn có nội dung lớn nhất
Việc kiểm tra kỹ lưỡng có thể xác định các vấn đề về tải, nhưng nói chung là vấn đề giảm số lượng dữ liệu được gửi đến trình duyệt. Các mẹo sau đây sẽ giúp đạt được điểm LCP lành mạnh hơn:
- Nâng cấp máy chủ và / hoặc dịch vụ lưu trữ của bạn. Đảm bảo tốc độ tải xuống vẫn nhanh ngay cả ở những thời điểm sử dụng nhiều.
- Kích hoạt nén máy chủ và HTTP / 2 +. Không có lý do gì để không!
- Giảm nỗ lực của máy chủ. Xóa mã và các plugin CMS không sử dụng, sau đó kích hoạt bộ nhớ đệm hiệu quả.
- Đảm bảo trình duyệt có thể lưu trữ các tệp một cách hiệu quả. Đặt các hàm băm Expires, Last-Modified và / hoặc ETag thích hợp trong tiêu đề HTTP, để các tệp không được yêu cầu lại.
- Sử dụng Mạng phân phối nội dung (CDN) để phân chia tải và lưu trữ nội dung trên các máy chủ gần người dùng hơn về mặt địa lý.
- Tăng cường tối ưu hóa tổng thể của bạn bằng cách sử dụng tính năng thu nhỏ mã được tích hợp trong bảng điều khiển MyKinsta.
- Tối ưu hóa hình ảnh của bạn. Giảm chúng xuống kích thước nhỏ nhất và sử dụng định dạng thích hợp để giảm thiểu kích thước tệp. Đảm bảo bất kỳ hình ảnh nào trong khối nội dung lớn nhất được yêu cầu sớm nhất có thể; tải trước có thể hữu ích.
- Lazy-load hình ảnh bằng cách thêm thuộc tính
loading="lazy"
. Thêm thuộc tính chiều rộng và chiều cao để đảm bảo không gian thích hợp được dành riêng trên trang trước khi hình ảnh hoàn tất tải. - Giảm thiểu yêu cầu của bên thứ ba và cân nhắc chuyển nội dung sang miền chính của bạn để tránh tra cứu DNS không liên quan.
- Giảm thiểu số lượng và kích thước của các tệp được yêu cầu, đặc biệt là ở đầu HTML của bạn.
- Đảm bảo bạn chỉ tải các phông chữ web bắt buộc. Chuyển sang phông chữ an toàn cho web để có hiệu suất tối đa.
- Loại bỏ các tệp JavaScript và CSS không sử dụng.
- Kết hợp và rút gọn các tệp JavaScript và CSS của bạn.
- Tránh các câu lệnh CSS @import – chúng chặn hiển thị và tải các kiểu theo chuỗi.
- Tránh mã hóa Base64 – nó làm tăng kích thước tệp và yêu cầu xử lý bổ sung.
- Xem xét CSS nội tuyến quan trọng. Nhúng CSS “trong màn hình đầu tiên” cần thiết vào khối
<link>
ở đầu trang, sau đó tải không đồng bộ các biểu định kiểu khác. - Sử dụng JavaScript mô-đun ES không đồng bộ, hoãn lại hoặc ES để chạy các tập lệnh sau này. Thực thi các quy trình JavaScript chạy dài trong một service worker.
Độ trễ đầu vào đầu tiên (FID)
Độ trễ nhập liệu đầu tiên đo lường khả năng đáp ứng của trang của bạn. Về bản chất, nó phản hồi nhanh như thế nào đối với các hành động của người dùng như nhấp, chạm và cuộn?
Chỉ số FID được tính bằng thời gian giữa tương tác của người dùng và trình duyệt xử lý yêu cầu của họ. Nó không đo thời gian để chạy hàm xử lý, hàm này thường xử lý đầu vào và cập nhật DOM.
Các trang có thời gian FID từ 100 mili giây trở xuống được coi là tốt (màu xanh lục). Các trang vượt quá 300 mili giây được coi là kém (màu đỏ):

Công cụ phân tích độ trễ đầu vào đầu tiên
Không thể mô phỏng độ trễ đầu vào đầu tiên vì nó chỉ có thể được đo khi trang được phân phát cho người dùng thực tương tác với trang. Do đó, kết quả phụ thuộc vào tốc độ và khả năng xử lý của từng thiết bị.
FID không được tính toán trong bảng điều khiển DevTools Lighthouse hoặc PageSpeed Insights. Tuy nhiên, họ có thể xác định Tổng thời gian chặn (TBT). Đây là một giá trị gần đúng hợp lý cho Độ trễ đầu vào đầu tiên. Nó đo lường sự khác biệt về thời gian giữa:
- Bức tranh có nội dung đầu tiên (FCP) hoặc thời gian mà nội dung trang bắt đầu hiển thị, và
- Thời gian tương tác (TTI) hoặc thời gian trang có thể phản hồi thông tin nhập của người dùng. TTI được giả định khi không có tác vụ chạy dài nào hoạt động và có ít hơn ba yêu cầu HTTP chưa hoàn thành.

Tiện ích mở rộng Web Vitals cho Google Chrome cũng có thể hiển thị số liệu FID sau khi tương tác với trang bằng cách cuộn hoặc nhấp. Nhấp vào biểu tượng của tiện ích mở rộng để hiển thị thêm thông tin:

Giống như LCP, Báo cáo trải nghiệm người dùng Chrome cho phép bạn truy vấn thống kê FID thực được ghi lại trên các quốc gia, kết nối và thiết bị khác nhau cho một URL cụ thể.
Thư viện JavaScript web-vitals cũng có thể tính toán các chỉ số FID cho người dùng thực trên trang web trực tiếp của bạn. Bạn có thể thêm tập lệnh sau vào HTML <head>
của mình để xuất số liệu FID cho hàm gọi lại:
Bạn cảm thấy mệt mỏi với việc hỗ trợ lưu trữ WordPress cấp độ 1 phụ mà không có câu trả lời? Hãy thử nhóm hỗ trợ đẳng cấp thế giới của chúng tôi! Kiểm tra các kế hoạch của chúng tôi
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>My page</title> <script type="module"> import { getFID } from 'https://unpkg.com/web-vitals?module'; getFID(console.log); </script> <!-- rest of page -->
Nguyên nhân phổ biến của điểm chậm trễ đầu vào đầu tiên kém
Điểm FID và TBT kém thường do mã phía máy khách làm hỏng bộ xử lý, chẳng hạn như:
- Số lượng đáng kể CSS và JavaScript chặn hiển thị, tạm dừng tải trang khi mã được tải xuống và phân tích cú pháp
- Các tập lệnh lớn, đòi hỏi nhiều quy trình, chạy ngay lập tức khi tải trang
- Các tác vụ JavaScript chạy lâu hoặc được tối ưu hóa kém
Theo mặc định, các trình duyệt chạy trên một luồng duy nhất, chỉ có thể xử lý một tác vụ tại một thời điểm. Nếu một hàm JavaScript mất một giây để thực thi, tất cả các quá trình hiển thị khác sẽ bị chặn trong giây đó. Trang không thể phản ứng với đầu vào của người dùng, cập nhật DOM, hiển thị hoạt ảnh, v.v. Ngay cả ảnh động GIF cũng có thể bị chặn trong các trình duyệt cũ hơn.
Cách cải thiện điểm số độ trễ đầu vào đầu tiên
Kiểm tra JavaScript phía máy khách có thể xác định các vấn đề, nhưng nói chung là vấn đề loại bỏ mã thừa và đảm bảo các tác vụ được thực thi nhanh chóng.
Các mẹo sau đây sẽ giúp đạt được điểm FID tốt hơn:
- Tạo và lưu vào bộ đệm càng nhiều nội dung HTML tĩnh trên máy chủ càng tốt. Cố gắng không dựa vào các khung JavaScript phía máy khách để hiển thị cùng một HTML cho mọi người.
- Đảm bảo trình duyệt có thể lưu trữ các tệp một cách hiệu quả. Đặt các hàm băm Expires, Last-Modified và / hoặc ETag thích hợp trong tiêu đề HTTP, để các tệp không được yêu cầu lại.
- Áp dụng các kỹ thuật nâng cao tiến bộ, do đó, giao diện có thể sử dụng được trong HTML và CSS trước khi JavaScript chạy.
- Loại bỏ các tệp JavaScript và CSS không sử dụng.
- Kết hợp và rút gọn các tệp JavaScript và CSS của bạn.
- Tránh sử dụng quá nhiều các thuộc tính CSS đắt tiền như hộp bóng và bộ lọc.
- Sử dụng JavaScript mô-đun ES không đồng bộ, hoãn lại hoặc ES để chạy các tập lệnh sau này.
- Giảm thiểu các yêu cầu JavaScript của bên thứ ba cho phân tích, tiện ích truyền thông xã hội, diễn đàn thảo luận, v.v. Những yêu cầu này có thể nhanh chóng gắn kết tới vài megabyte JavaScript.
- Không tải các thành phần JavaScript theo yêu cầu, ví dụ: tiện ích trò chuyện, trình phát video, v.v.
- Trì hoãn tải các tập lệnh ít quan trọng hơn như phân tích, quảng cáo và các công cụ truyền thông xã hội.
- Chia nhỏ các tác vụ JavaScript đang chạy dài thành một loạt các công việc nhỏ hơn thực thi sau một thời gian ngắn requestIdleCallback, setTimeout hoặc requestAnimationFrame.
- Xem xét việc thực thi các quy trình JavaScript chạy dài trong trình nhân viên web, sử dụng một chuỗi nền.
Dịch chuyển bố cục tích lũy (CLS)
CLS đo độ ổn định trực quan của trang. Về bản chất, nội dung trang có di chuyển hoặc nhảy bất ngờ, đặc biệt là trong lần tải đầu tiên không?
CLS tính điểm khi các phần tử di chuyển mà không có cảnh báo hoặc tương tác của người dùng. Bạn có thể đã gặp phải trường hợp này khi đọc một bài báo trên thiết bị di động – văn bản đột nhiên nhảy ra khỏi màn hình và bạn bị mất vị trí của mình. Các ví dụ tồi tệ nhất có thể khiến bạn nhấp vào một liên kết không chính xác.
Các vấn đề CLS nổi bật nhất khi một hình ảnh hoặc quảng cáo lớn tải phía trên vị trí cuộn hiện tại và không gian chiều cao bằng không ngay lập tức tăng thêm vài trăm pixel.
Điểm số Thay đổi bố cục tích lũy được tính bằng cách nhân các chỉ số sau với nhau:
- Phần tác động: Đây là tổng diện tích của tất cả các phần tử không ổn định trong chế độ xem, tức là những phần tử sẽ “nhảy”. Nếu các phần tử bao phủ 60% khung nhìn bị dịch chuyển trong quá trình tải trang, thì phần tác động là 0,6. Lưu ý rằng các yếu tố gây ra sự thay đổi đó, chẳng hạn như hình ảnh hoặc quảng cáo, được coi là ổn định vì chúng không nhất thiết phải di chuyển sau khi được hiển thị.
- Phần khoảng cách: Đây là khoảng cách lớn nhất được di chuyển bởi bất kỳ phần tử không ổn định nào trong khung nhìn. Nếu độ dịch chuyển lớn nhất xảy ra trên một phần tử di chuyển từ 0,100 đến 0,800, thì phần tử đó đã dịch chuyển 700 pixel theo chiều dọc. Nếu khung nhìn thiết bị có chiều cao 1.000 px, thì phần khoảng cách là 700 px / 1000 px = 0,7. Do đó, điểm số Dịch chuyển Bố cục Tích lũy được tính toán là 0,6 x 0,7 = 0,42.
Google đã thực hiện các thay đổi đối với chỉ số CLS để phù hợp với các trường hợp sau:
- Thay đổi bố cục được nhóm thành “phiên” kéo dài trong năm giây nhưng đóng sau một giây nếu không có thay đổi bố cục nào xảy ra. Nếu hai hoặc nhiều ca thay đổi xảy ra trong vòng một giây, điểm của họ sẽ được cộng.
- Thay đổi bố cục không được ghi lại trong 500 mili giây sau khi người dùng tương tác, chẳng hạn như một cú nhấp chuột. Trong một số trường hợp, điều này kích hoạt cập nhật DOM (ví dụ: mở menu, hiển thị thông báo lỗi, hiển thị hộp thoại phương thức, v.v.).
- Các ứng dụng một trang vẫn mở trong thời gian dài hơn và thực hiện nhiều bản cập nhật DOM sẽ không bị ảnh hưởng bất lợi.
Các trang có điểm CLS từ 0,1 trở xuống được coi là tốt (màu xanh lá cây). Các trang vượt quá 0,25 được coi là kém (màu đỏ):

Công cụ phân tích dịch chuyển bố cục tích lũy
Các chỉ số CLS được tính toán trong bảng điều khiển DevTools Lighthouse , PageSpeed Insights và các công cụ đo lường web.dev:

Tiện ích mở rộng Web Vitals cho Google Chrome cũng hiển thị số liệu CLS:

Giống như LCP và FID, Báo cáo trải nghiệm người dùng Chrome cho phép bạn truy vấn thống kê CLS thực được ghi lại trên các quốc gia, kết nối và thiết bị khác nhau cho một URL cụ thể.
Thư viện JavaScript web-vitals cũng có thể tính toán các chỉ số CLS cho người dùng thực trên trang web trực tiếp của bạn, giống như với LCP và FID. Tập lệnh sau có thể được thêm vào HTML <head>
của bạn để xuất số liệu CLS cho một hàm gọi lại:
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>My page</title> <script type="module"> import { getCLS } from 'https://unpkg.com/web-vitals?module'; getCLS(console.log); </script> <!-- rest of page -->
Nguyên nhân phổ biến của điểm thay đổi bố cục tích lũy kém
Điểm CLS kém thường do nội dung trang tải chậm và các phần tử DOM động hoặc chưa được kích thước:
- Không gian trên trang không được dành riêng cho hình ảnh, khung nội tuyến, quảng cáo, v.v.
- Nội dung được đưa động vào DOM, thường là sau khi có yêu cầu mạng về quảng cáo, tiện ích truyền thông xã hội, v.v.
- Việc tải phông chữ trên web gây ra hiện tượng nhấp nháy Văn bản ẩn (FOIT) hoặc Văn bản không định kiểu (FOUT) đáng chú ý.
Cách cải thiện điểm số dịch chuyển bố cục tích lũy
Kiểm tra phía khách hàng có thể xác định các vấn đề, nhưng nói chung là vấn đề đảm bảo rằng nội dung được dành riêng cho nội dung trước khi tải xuống. Các mẹo tối ưu hóa máy chủ được đề xuất cho Sơn có nội dung lớn nhất sẽ có một số lợi ích, nhưng có thể cải thiện thêm:
- Thêm thuộc tính chiều rộng và chiều cao vào các thẻ HTML
<img>
và<iframe>
hoặc sử dụng thuộc tính tỷ lệ khung hình CSS mới để đảm bảo dành không gian thích hợp trên trang trước khi tải nội dung xuống. - Đặt kích thước thích hợp cho các phần tử vùng chứa chứa nội dung của bên thứ ba tải chậm hơn như quảng cáo và tiện ích.
- Đảm bảo hình ảnh và các nội dung khác xuất hiện ở đầu trang được yêu cầu sớm nhất có thể – tải trước có thể hữu ích.
- Giảm thiểu việc sử dụng phông chữ web và cân nhắc sử dụng các phông chữ hệ điều hành phổ biến có sẵn khi có thể.
- Tải phông chữ web và đặt hiển thị phông chữ CSS thành tùy chọn hoặc hoán đổi. Đảm bảo bạn sử dụng phông chữ dự phòng có kích thước tương tự để giảm thiểu sự thay đổi bố cục.
- Tránh chèn các phần tử lên đầu trang trừ khi nó phản hồi lại một hành động của người dùng, chẳng hạn như một cú nhấp chuột.
- Đảm bảo các tương tác của người dùng hoàn tất trong vòng 500 mili giây kể từ khi kích hoạt đầu vào.
- Sử dụng biến đổi CSS và độ mờ để có các hoạt ảnh hiệu quả hơn mà không phải bố trí lại.
- Xem xét CSS nội tuyến quan trọng. Nhúng CSS “trong màn hình đầu tiên” cần thiết vào khối
<link>
ở đầu trang, sau đó tải các biểu định kiểu bổ sung một cách không đồng bộ. - Khi cần thiết, hãy xem xét tính năng ngăn chặn, một tính năng CSS mới cho phép bạn xác định các cây con riêng biệt của một trang. Trình duyệt có thể tối ưu hóa quá trình xử lý bằng cách hiển thị – hoặc không hiển thị – các khối nội dung DOM cụ thể.
Bản tóm tắt
Các nhà phát triển không phải lúc nào cũng muốn nhảy theo giai điệu của Google. Công ty có quyền lực đáng kể và các bản cập nhật công cụ tìm kiếm nhỏ có thể ảnh hưởng xấu đến năng suất và lợi nhuận của các tổ chức dựa trên web.
Điều đó nói rằng, Core Web Vitals sử dụng cách tiếp cận “củ cà rốt” hơn là cách tiếp cận “cây gậy”. Các trang web có thể sử dụng, được tối ưu hóa tốt, loại bỏ các mô hình tối có cơ hội thành công cao hơn so với các trang web chuyên sâu về cửa sổ bật lên cung cấp giao diện người dùng di động kém.
Core Web Vitals cung cấp một cách có thể đo lường để đánh giá trải nghiệm người dùng nhằm giúp bạn tập trung vào những cải tiến quan trọng nhất. Những thay đổi đối với các chỉ số quan trọng của bạn có thể không làm tăng doanh thu, nhưng người dùng của bạn sẽ hạnh phúc hơn và trung thành hơn.
Bạn có mẹo nào khác về việc cải thiện Core Web Vitals không? Chia sẻ chúng trong phần bình luận!
Tiết kiệm thời gian, chi phí và tối đa hóa hiệu suất trang web với:
- Trợ giúp tức thì từ các chuyên gia lưu trữ WordPress, 24/7.
- Tích hợp Cloudflare Enterprise.
- Tiếp cận khán giả toàn cầu với 34 trung tâm dữ liệu trên toàn thế giới.
- Tối ưu hóa với Giám sát Hiệu suất Ứng dụng được tích hợp sẵn của chúng tôi.
Tất cả những điều đó và hơn thế nữa, trong một kế hoạch không có hợp đồng dài hạn, hỗ trợ di chuyển và đảm bảo hoàn tiền trong 30 ngày. Kiểm tra các kế hoạch của chúng tôi hoặc nói chuyện với bộ phận bán hàng để tìm ra kế hoạch phù hợp với bạn.