Cách tối ưu điểm số Core Web Vitals
Sơ đồ trang
Core Web Vitals là ba chỉ số hiệu suất mới sẽ sớm tác động đến xếp hạng SEO. Tìm hiểu cách đo lường và cải thiện chúng để tối đa hóa trải nghiệm người dùng!
Google đã công bố các bản cập nhật cho thuật toán xếp hạng Trải nghiệm trang vào tháng 5 năm 2020. Bản cập nhật này bao gồm hai điểm nổi bật chính:
- Ba chỉ số hiệu suất mới sẽ được sử dụng làm tín hiệu xếp hạng cho SEO
- Bây giờ không còn yêu cầu tải trang AMPHTML như trước nữa mà hiệu suất sẽ trở thành một yếu tố xếp hạng
Bản cập nhật là tin tuyệt vời cho những người yêu thích tốc độ tải trang
Cập nhật trải nghiệm bị trì hoãn do COVID-19. Các thay đổi đối với thuật toán xếp hạng sẽ được áp dụng vào tháng 5 năm 2021.
Để test hiệu suất hiện tại ở thuật toán mới, bạn có thể thử load trang thông qua công cụ PageSpeed Insights hoặc web.dev/measure.
Các công cụ này của Google sẽ cho bạn điểm hiệu suất chi tiết.
Các chỉ số hiệu suất này đã được thiết kế để trở thành các thước đo chung về tốc độ tải trang và cảm giác của trải nghiệm đối với hầu hết các trang web. Google tuyên bố rằng các chỉ số này đang được xem xét liên tục từng ngày và có thể thay đổi trong tương lai.
- Largest Contentful Paint là thước đo hiệu suất hiển thị, một sự thay thế tốt cho thời gian tải trang hoặc nội dung DOM đã sẵn sàng.
- First Input Delay là thước đo thời gian trình duyệt phản hồi đầu vào và người dùng tương tác như nhấp chuột hoặc tap trên mobile.
- Cumulative Layout Shift là thước đo mức độ không ổn định của trang, tổng hợp của tất cả các thay đổi bố cục không mong muốn trong khi tải trang.
Core Web Vitals
Các giá trị đề xuất ở trên được xác định từ phân vị thứ 75 từ trải nghiệm người dùng thực: ít nhất 75% lượt xem trang của bạn phải vượt quá Giá trị tốt để vượt qua bài đánh giá này!
Cải thiện điểm Core web vitals sẽ có tác động tích cực đến xếp hạng từ khóa SEO, và có tác động tích cực đến trải nghiệm người dùng!
Cách Google đo tốc độ
Ba chỉ số hiệu suất rất mới nên chúng hiện chỉ được hỗ trợ qua API trong các trình duyệt dựa trên Blink (Chrome, Chrome for Android, Chromium Edge). Dữ liệu mà Google sẽ sử dụng cho bản cập nhật trải nghiệm trang được lấy từ báo cáo Chrome UX (CRUX), là tập hợp thống kê hiệu suất ẩn danh được lấy từ các lần tải trang thực trong các trình duyệt Chrome trên khắp thế giới. CRUX đo lường tất cả các lần tải trang thông thường, cho cả trang đích và trang giữa phiên, bất kể trạng thái bộ nhớ cache. Nó không đo lường các điều hướng mềm (thay đổi định tuyến) trong các ứng dụng.
Điều này có nghĩa là các điều hướng mềm sẽ có khả năng bị phạt, với điểm CLS cao hơn dự kiến và các giá trị LCP cao, bị thiếu hoặc sai. Hiện tại vẫn chưa có một giải pháp nào cho vấn đề này.
Bản cập nhật đi kèm với một tập hợp các mục tiêu tốc độ, các mục tiêu này được đo ở phân vị thứ 75 trong dữ liệu CRUX, vì vậy ít nhất 75% trải nghiệm được đo phải đáp ứng hoặc vượt quá các mục tiêu này. Bộ nhớ cache và trạng thái phiên không có sẵn trong tập dữ liệu CRUX vì vậy giá trị phân vị thứ 75 được lấy từ tất cả các lần tải trang, được lưu trong bộ nhớ cache hoặc không có bộ nhớ cache.
PageSpeed Insights sẽ cung cấp cho bạn ba bộ số liệu hiệu suất:
- Field – dữ liệu từ CRUX cho URL xác định
- Origin summary – dữ liệu tổng hợp của tất cả các trang của bạn
- Lab – chạy thử nghiệm từ máy chủ của Google
Nếu trang của bạn không có đủ lưu lượng truy cập để tạo dữ liệu Field, bạn sẽ chỉ nhận được kết quả tóm tắt Origin summary. Các đề xuất và chẩn đoán trong PageSpeed Insights được tạo ra từ thử nghiệm của Lab, các chỉ số hiệu suất phải được lấy từ kết quả thực tế. Các đề xuất sẽ cung cấp cho bạn ý tưởng chung về các lĩnh vực cần cải thiện cho website của bạn.
Tối ưu hóa cho Core Web Vitals
Chẩn đoán và cải thiện từng chỉ số trong số ba chỉ số: LCP, FID và CLS là mục tiêu của mọi trang web. Hãy nhớ rằng bất kỳ tối ưu hóa nào để cải thiện các chỉ số này chắc chắn sẽ làm cho trang web của bạn hoạt động nhanh và cải thiện trải nghiệm người dùng tốt hơn!
Largest Contentful Paint (LCP)
LCP là điểm thời gian được đo khi phần tử lớn nhất trong màn hình đầu tiên được sơn lên màn hình. Đa số LCP là hình ảnh / video hoặc khối văn bản chính trên trang.
LCP là một giải pháp thay thế tốt cho “Thời gian tải trang”: nó đo lường mọi thứ cần thiết để trang web hiển thị nội dung chính trên một trang – DNS, TLS, HTML, CSS và blocking JavaScript, nhưng không bao gồm các tập lệnh không đồng bộ hoặc nội dung tải chậm .
Cách xác định LCP trên trình duyệt Chrome
LCP xảy ra sau khi hoàn tất ba giai đoạn tải trang:
- HTML được phân phối và phân tích cú pháp
- Tài nguyên quan trọng được tải xuống, phân tích cú pháp và xử lý
- Nội dung LCP được tải xuống và hiển thị (hình ảnh, video, phông chữ web, v.v.)
Critical resources đề cập đến số lượng nội dung tối thiểu mà trình duyệt phải tải xuống trước khi có thể hiển thị một trang lần đầu tiên. Những nội dung này chặn hiển thị một trang, vì vậy, hãy giữ số lượng nội dung thấp để trình duyệt có thể hiển thị trang nhanh nhất có thể.
Phân phối dữ liệu nhanh hơn là một trong những điều quan trọng nhất bạn có thể làm để cải thiện tốc độ trang, nếu bạn có thể giảm tốc độ này xuống 100 mili giây thì mọi chỉ số thời lượng khác sẽ nhanh hơn 100 mili giây! Phân phối tài liệu nhanh chóng có một số tối ưu hóa chính:
- DNS – Tối ưu hóa DNS bằng cách tăng TTL và sử dụng dịch vụ DNS phân giải càng nhanh càng tốt (Sử dụng Cloudflare để tối ưu việc này).
- TCP – Yếu tố hạn chế trong việc thiết lập kết nối TCP là thời gian phản hồi giữa người dùng và máy chủ. Sử dụng CND để giảm tỷ lệ này xuống thấp nhất có thể.
- TLS – Các trang web an toàn yêu cầu một hoặc nhiều “round-trips” để tạo kết nối an toàn. Kiểm tra xem bạn có bật OCSP trên chứng chỉ của trang web (thậm chí có thể hạ cấp từ EV xuống OV để đạt được điều này!) Và máy chủ hoặc CDN của bạn được cấu hình hỗ trợ TLSv1.3 để tăng tốc TLS.
- TTFB – Thời gian cho byte đầu tiên được phản hồi từ máy chủ. Có thể cải thiện bằng cách tạo cache trong CDN hoặc proxy ngược.
- HTML – Kích thước và cấu trúc của tài liệu HTML rất quan trọng đối với hiệu suất. Đảm bảo rằng file tĩnh HTML được nén bé hơn 50kB. Chú ý đến <head> của tài liệu để đảm bảo rằng <title> là thẻ đầu tiên và không có thẻ <script> của bên thứ ba chặn ở đây.
Khi HTML được tải xuống, trình duyệt sẽ phân tích cú pháp tài liệu theo từng dòng để tìm các tài nguyên quan trọng. CSS và JavaScript trong phần đầu được ưu tiên rất cao, sau đó đến hình ảnh trong phần nội dung được tải xuống theo thứ tự xuất hiện. Nếu trình phân tích cú pháp của trình duyệt nhìn thấy thẻ bị chặn (tức là không có thuộc tính async hoặc defer), nó sẽ dừng mọi thứ mà nó đang làm trong khi tìm nạp, phân tích cú pháp và thực thi tập lệnh đó. Do đó, các tập lệnh phải luôn không đồng bộ, khi thứ tự thực thi không quan trọng hoặc hoãn lại khi thứ tự thực hiện là quan trọng. Bạn cũng nên xem lại các tập lệnh nội tuyến để giảm tác động của chúng.
Nếu có thể, hãy chia JavaScript theo trang và sử dụng JavaScript hiện đại. Cho phép gửi theo gói nhỏ nhất có thể và sử dụng các công nghệ hiện đại nếu được hỗ trợ. Lưu ý rằng mô-đun có hành vi trì hoãn theo mặc định:
<script type=”module” src=”/app-homepage.esm.js”></script>
<script nomodule src=”/app-homepage.js”></script>
Bước tiếp theo trong đường dẫn quan trọng là tải các biểu định kiểu: nếu không có CSS, trình duyệt không biết cách hiển thị trang nên nó sẽ chặn hiển thị trên bất kỳ thẻ <link rel = “stylesheet”> nào. Đảm bảo rằng CSS được đóng gói theo trang để giảm trọng lượng không cần thiết, bạn có thể tìm nạp và lưu vào bộ nhớ cache style đầy đủ bằng cách sử dụng phương tiện media=”none” (đảm bảo rằng tệp này sẽ không gây ra sự thay đổi bố cục!):
<link rel=”stylesheet”
href=”lazy.css”
media=”none” onload=”this.media=’all'” >
LCP được đo lường độc lập với trạng thái bộ nhớ cache, vì vậy hãy đảm bảo nội dung tĩnh của bạn (JavaScript, CSS, hình ảnh và phông chữ) có thể được lưu vào bộ nhớ cache trong trình duyệt trong ít nhất một giờ với tiêu đề phản hồi như cache-control: max-age: 3600. Cũng làm đảm bảo nội dung văn bản của bạn được nén bằng gzip hoặc brotli!
Một vấn đề phổ biến là trên các trang web thương mại điện tử, là một số lượng lớn các hình ảnh không quan trọng tải sớm trong trang, chẳng hạn như trong menu. Native lazy-loading là một kỹ thuật tuyệt vời để tối ưu hóa LCP bằng cách giảm tranh chấp băng thông trong quá trình tải trang. Thuộc tính loading chưa được hỗ trợ trong Safari, nhưng nó có trong WebKit và hiện có trong iOS Safari. Nó được hỗ trợ trong tất cả các trình duyệt gửi dữ liệu tới CRUX, vì vậy hãy triển khai ngay bây giờ để mang lại lợi ích cho SEO và trải nghiệm người dùng.
<img src=”menu-img.jpg” alt=”…”
width=”200″ height=”200″
loading=”lazy” >
<img src=”hero-img.jpg” alt=”…”
width=”1024″ height=”600″
loading=”eager” >
Đảm bảo rằng phần tử hero (hero element) của bạn có thuộc tính loading=’eager’ và hình ảnh dưới màn hình đầu tiên có thuộc tính loading = ‘lazy’. Việc tối ưu hóa đơn giản này cho phép trình duyệt ưu tiên tải xuống các nội dung quan trọng sớm hơn, cải thiện LCP và trải nghiệm người dùng.
Phần tử “hero” không nên sử dụng JavaScript, tốt nhất nên thay slider hình ảnh và trình phát video bằng static images and native <video>. Nếu bạn có poster video, hãy đảm bảo rằng nó được tối ưu hóa và sử dụng thuộc tính tải trước hợp lệ hoặc sử dụng siêu dữ liệu để giảm tải băng thông trong quá trình tải trang.
First Input Delay (FID)
FID là thước đo thời gian trình duyệt bận rộn với các tác vụ khác trước khi nó có thể phản ứng với một sự kiện đầu vào riêng biệt của người dùng như một lần nhấn hoặc nhấp vào màn hình. Đây là một dấu hiệu về mức độ phản hồi của giao diện người dùng đối với người dùng và mức độ bận rộn của CPU với xử lý JavaScript.
Cách để cải thiện FID mà không làm suy giảm trải nghiệm người dùng là giảm thời gian thực thi JavaScript, cả khi tải trang và khi thực thi full trang. Một cách đơn giản để đánh lừa chỉ số này là ẩn nội dung của bạn (có thể là sau màn hình tải / xoay) cho đến khi JavaScript của bạn hoàn tất việc thực thi, vì vậy khách truy cập của bạn không cố gắng tương tác trước khi ứng dụng của bạn hoàn toàn sẵn sàng. Tuy nhiên, điều này rất có thể sẽ tác động tiêu cực đến các chỉ số LCP và CLS của bạn, vì vậy hãy cẩn thận!
Giả sử chúng tôi đang cố gắng cải thiện FID và cải thiện hiệu suất hình ảnh sẽ có một số tùy chọn:
- Trì hoãn hoặc xóa các ứng dụng của bên thứ ba
- Trì hoãn các tập lệnh không quan trọng
- Cải thiện hiệu suất JS
Nhiệm vụ đầu tiên là chạy theo dõi hiệu suất trên một trang chính để xem thời gian luồng chính được sử dụng ở đâu. Bất kỳ khối lượng lớn nào đều là nguyên nhân đáng lo ngại và cần được điều tra.
Tập trung vào các long tasks, đây là các khối thực thi đơn lẻ có nhiều khả năng gây ra độ trễ First Input Delay (FID). Nhấp vào 1 long tasks để hiển thị ngăn xếp cuộc gọi trong tab “Bottom-Up”.
Bạn có thể nhóm chế độ xem theo URL để nhanh chóng xác định tập lệnh nào đang gây ra sự cố, trong trường hợp này, banner SDK cookielaw có thời gian tự thực thi 200ms, có nghĩa là thời gian dành cho tập lệnh này thay vì do các lệnh gọi thực hiện bởi nó. Điều này có thể do bản thân tập lệnh quá chậm hoặc việc triển khai kém dẫn đến nhiều lệnh gọi hàm trùng lặp.
Một nguyên nhân tiềm ẩn khác gây ra FID cao là quá trình hydrat hóa. Nếu bạn có một ứng dụng trang đơn được hiển thị phía máy chủ, quá trình hydrat hóa sẽ thêm chức năng ứng dụng phía máy khách vào HTML tĩnh của bạn. Trong khi quá trình này dẫn đến kết xuất đầu tiên nhanh hơn (và LCP), nó có thể làm chậm quá trình tương tác và tăng khả năng bị trễ khi người dùng cố gắng tương tác. Nếu bạn đang sử dụng SSR với quá trình hydrat hóa phía máy khách, Addy có một bản viết ngắn gọn về vấn đề với một số tài nguyên về cách quản lý khoảng cách hiệu suất này.
Cumulative Layout Shift (CLS)
CLS là thước đo mức độ ổn định của giao diện người dùng khi người dùng tải và tương tác với website. Đó là tổng số các thay đổi bố cục không mong muốn trong khi tải trang, như khi một biểu ngữ quảng cáo tải và đẩy nội dung chính của trang ra xung quanh.
Điểm số của sự thay đổi bố cục được tính từ tác động của sự thay đổi đối với chế độ xem: tích số của mức độ thay đổi của chế độ xem và mức độ di chuyển của phần tử. Điểm tích lũy hoàn hảo là 0, 0,1. Xem tài liệu chính thức để biết thêm chi tiết.
Thay đổi bố cục không mong muốn có nghĩa là chúng không xảy ra ngay lập tức sau khi người dùng tương tác rời rạc, vì vậy nó có thể sẽ có tác động tiêu cực đến trải nghiệm người dùng.
CLS được CRUX đo lường trong suốt vòng đời của một trang, từ khi bắt đầu điều hướng cho đến khi người dùng rời khỏi trang. Tất cả các thay đổi bố cục đột xuất được tổng hợp trong suốt thời gian này và tổng điểm được sử dụng để đo lường; điều này khiến nó trở thành một số liệu khó đo lường trong môi trường phòng thí nghiệm. Điều này cũng có nghĩa là các công cụ như WebPageTest và mPulse sẽ báo cáo trường hợp tốt nhất cho CLS, chúng sẽ chỉ thu thập dữ liệu này trong khi trang đang tải và bỏ qua các thay đổi khác như xảy ra trong quá trình cuộn.
- Web fonts – khớp ký tự phông chữ web và khoảng cách dòng của bạn với phông chữ dự phòng
- Quảng cáo – phân bổ trước các vị trí bố cục cho quảng cáo, sử dụng hình ảnh dự phòng nếu quảng cáo không thành công hoặc bị chặn
- Late-loading CSS – đảm bảo CSS quan trọng về bố cục nằm trong đường dẫn quan trọng
- Hình ảnh – luôn thêm thuộc tính chiều rộng và chiều cao cho hình ảnh, để trình duyệt có thể phân bổ không gian trước khi tải hình ảnh xuống
- Dynamic content – nếu có thể, phân bổ trước không gian bố cục cho các yếu tố động
Các công cụ dành cho nhà phát triển của Chrome hiện có một phương pháp hữu ích để xác định những yếu tố nào đã gây ra sự thay đổi bố cục và cách chúng đóng góp vào điểm số dịch chuyển bố cục tích lũy.
Nếu bạn di chuột vào layout shift trong bản trải nghiệm, Chrome sẽ đánh dấu phần tử trên trang.
Bạn nên đặt các tùy chọn điều chỉnh mạng và CPU của mình trong tab Performance, điều này khiến nhiều khả năng bạn sẽ bắt gặp các thay đổi bố cục xảy ra tự nhiên hơn như kiểu tua chậm từng thứ 1 thì dễ nhận biết các thay đổi bố cục hơn.
Khi bạn đã xác định được các yếu tố gây ra thay đổi bố cục, đã đến lúc xác định cách giảm hoặc ngăn chặn chúng.
Trong ví dụ này từ CNN, phần tử dòng tiêu đề thay đổi nhiều lần trong quá trình tải trang. Sự thay đổi lớn là do tác giả tải hình ảnh và đẩy dòng bên phải. Một sự thay đổi khác là do phông chữ web cho dòng tiêu đề thay đổi bố cục dòng tiêu đề. Sự thay đổi hình ảnh có thể được giải quyết đơn giản bằng cách thêm các thuộc tính chiều rộng và chiều cao vào phần tử <img>!
Đối với sự thay đổi phần tử văn bản, font-face có bộ mô tả font-display: swap. Nhưng phông chữ dự phòng có chiều rộng ký tự khác với phông chữ web. Khi phông chữ web được tải, phần tử văn bản sẽ thay đổi vì các ký tự nhỏ hơn và phần tử được định kích thước để vừa với nội dung. Trong trường hợp này, đó là một sự thay đổi bố cục nhỏ nhưng tác động lên nội dung văn bản có thể lớn hơn nhiều, vì hiện tượng tràn văn bản có thể khiến phần tử nội dung thay đổi kích thước. Điều này có thể dễ dàng được khắc phục bằng cách khớp phông chữ hệ thống với phông chữ web, công cụ đối sánh phông chữ của Monica là một cách tuyệt vời để làm điều này!
Vitals khác
Trong khi bản cập nhật trải nghiệm trang đầu tiên xác định LCP, FID và CLS là phần cốt lõi trên web, những thứ này có thể thay đổi theo thời gian! Có một loạt các chỉ số khác mà bạn nên biết để tối ưu hóa website . Dưới đây là một số chỉ số chính khác mà bạn nên tìm hiểu thêm.
First Contentful Paint (FCP)
Trong khi LCP đo lớp sơn lớn nhất trên màn hình, FCP đo khi lớp sơn đầu tiên xuất hiện. Đây là một số liệu quan trọng, đặc biệt là đây là lần đầu tiên người dùng biết rằng điều hướng của họ đang thực sự hoạt động.
FCP thường giống với lớp sơn đầu tiên. First paint bao gồm các phần tử không hiển thị trong tính toán, trong khi FCP chỉ đo lường nội dung hiển thị cho người dùng. Trong trường hợp này, biểu trưng và tiêu đề của trang web:
Time to Interactive (TTI)
Thời gian tương tác (TTI) là ước tính thời điểm trang sẽ cảm thấy tương tác nếu người dùng cố gắng tương tác. Thời điểm này được đo giữa First Contentful Paint và khi luồng chính không có nhiệm vụ dài trong ít nhất năm giây. Đặt chỉ số này càng thấp càng tốt sẽ đảm bảo rằng người dùng của bạn có trải nghiệm tuyệt vời khi họ cố gắng tương tác với các trang của bạn. Sử dụng TTI với TBT để có được bức tranh tổng thể về mức độ bận rộn của trình duyệt khi tải các trang của bạn.
Total Blocking Time (TBT)
Tổng thời gian chặn (TBT) là thước đo mức độ bận rộn của CPU của trình duyệt khi tải trang, được đo bằng tổng các tác vụ dài (mỗi tác vụ dưới 50 mili giây) giữa FCP và TTI. Giảm thời gian này có thể sẽ cải thiện trải nghiệm người dùng và cũng có thể giúp cải thiện hiệu suất cảm nhận. Tìm kiếm các nhiệm vụ dài lớn trong hồ sơ JavaScript của bạn và cố gắng giảm bớt, loại bỏ hoặc trì hoãn chúng.
Cách theo dõi hiệu suất
Tất cả các công cụ của Google như PageSpeed Insights, Lighthouse và web.dev đều sẽ cung cấp cho bạn phép đo các chỉ số web cốt lõi của bạn. Tuy nhiên, dữ liệu ‘field’ có một số hạn chế: dữ liệu chỉ được thu thập từ những người dùng Google Chrome được chọn tham gia thu thập thống kê sử dụng ẩn danh và được tổng hợp hàng tháng với độ trễ một hoặc hai tuần. Vì vậy, nếu đó là tuần đầu tiên của tháng 10, bạn có thể chỉ có sẵn dữ liệu của cả tháng.
Nếu bạn muốn theo dõi các chỉ số web chặt chẽ hơn, hãy xem xét một giải pháp đo lường người dùng thực như Akamai mPulse. Các công cụ RUM có thể thu thập dữ liệu hiệu suất từ mọi trình duyệt hỗ trợ chúng và cung cấp cho bạn thông tin chi tiết theo thời gian thực về cách hiệu suất của bạn đang theo dõi. Bạn cũng có thể nhanh chóng phát hiện các vấn đề với các trang hoặc thiết bị cụ thể, giúp dữ liệu có thể xử lý được.
Kết luận
Bản cập nhật trải nghiệm trang được đề xuất rất có thể sẽ xảy ra vào giữa năm 2021. Điều này sẽ có tác động đến xếp hạng SEO. Google đã đề xuất ba chỉ số hiệu suất mới sẽ được sử dụng làm tín hiệu cho bản cập nhật SEO này, với sự lựa chọn dựa trên mức độ phù hợp với hiệu suất do người dùng cảm nhận và khả năng thu thập dữ liệu từ trình duyệt web.
Việc tối ưu hóa các chỉ số hiệu suất này được Google đo lường trong CRUX, có thể có tác động tích cực đến xếp hạng trong tương lai và trước mắt sẽ có tác động tích cực đến trải nghiệm người dùng. Chúng tôi biết rằng trải nghiệm nhanh hơn dẫn đến tỷ lệ thoát thấp hơn, thời gian cho phiên làm việc cao hơn, điểm hài lòng tốt hơn, tăng chuyển đổi, tăng lưu lượng truy cập SEO, tăng doanh thu… Còn chần chừ gì nữa mà không tối ưu ?!
Nếu bạn thấy bài viết có ích hãy sao chép link và chia sẻ bài viết
Bài viết liên quan
