Góc Kiến Thức

Core Web Vitals: Các chỉ số “mới mẻ” cần biết trong SEO 2022

Core Web Vitals là một trong những chỉ số đo lường trải nghiệm người dùng. Thông số này có liên quan đến nhiều vấn đề kỹ thuật và các chỉ số như (LCP), (CLS), (FID)… Để tìm hiểu rõ ràng và cụ thể hơn về các chỉ số ở trên, mọi người có thể tham khảo ngay bài viết dưới đây của SEODO nhé.

1. Core Web Vitals là gì?

Core Web Vitals là chỉ số thiết yếu về trang web ảnh hưởng đến SEO website như thế nào khi Google thông báo có những cập nhật ảnh hưởng đến xếp hạng từ khóa. Core Web Vitals là một trong những chỉ sổ để đo lường trải nghiệm người dùng, thông số này liên quan rất nhiều đến vấn đề kỹ thuật của một trang website.

Trải nghiệm trang trên thiết bị di động và các chỉ số Core Web Vital đã chính thức được sử dụng để xếp hạng các trang kể từ tháng 5 năm 2021. Các tín hiệu trên máy tính để bàn cũng đã được sử dụng kể từ tháng 2 năm 2022.

core web vitals
Tìm hiểu về Core Web Vitals

Cách dễ nhất để xem các chỉ số cho trang web của bạn là sử dụng báo cáo Core Web Vitals trong Google Search Console. Với báo cáo này, bạn có thể dễ dàng xem được các trang của mình có được phân loại là “URL kém”, “URL cần cải thiện” hay “URL tốt”.

2. Những trường hợp thực tế về Core Web Vitals

Những trường hợp thực tế về Core Web Vitals như sau.

  • Sự thật 1: Các chỉ số được phân chia giữa máy tính để bàn và thiết bị di động. Tín hiệu di động được sử dụng cho xếp hạng trên thiết bị di động và tín hiệu trên máy tính để bàn được sử dụng cho xếp hạng desktop.
  • Sự thật 2: Dữ liệu đến từ báo cáo trải nghiệm người dùng Chrome (CrUX), báo cáo này ghi lại dữ liệu từ những người dùng Chrome đã chọn tham gia. Các chỉ số được đánh giá ở vị thứ 75 của người dùng. Vì vậy, nếu 70% người dùng của bạn thuộc danh mục “tốt” và 5% thuộc danh mục “cần cải thiện”, thì trang của bạn sẽ vẫn được đánh giá là “cần cải thiện”.
  • Sự thật 3: Các chỉ số được đánh giá cho mỗi trang. Nhưng nếu không có đủ dữ liệu, Nhà phân tích sẽ có xu hướng quản trị trang web của Google. John Mueller tuyên bố rằng các tín hiệu từ các phần của trang web hoặc toàn bộ trang web có thể được sử dụng.

Trích: “Trong nghiên cứu dữ liệu Core Web Vitals của chúng tôi, chúng tôi đã xem xét hơn 42 triệu trang và nhận thấy rằng chỉ 11,4% số trang có các chỉ số liên quan đến chúng.”

  • Sự thật 4: Với việc bổ sung các chỉ số mới này, các trang trên thiết bị di động được tăng tốc (AMP) đã bị loại bỏ theo yêu cầu của tính năng. Vì các câu chuyện mới sẽ không thực sự có dữ liệu về chỉ số tốc độ, nên có thể các chỉ số từ một danh mục trang lớn hơn hoặc thậm chí toàn bộ miền có thể được sử dụng.
  • Sự thật 5: Ứng dụng không đo lường một số chỉ số như FID và LCP. Thông qua chuyển đổi trang, có một số thay đổi được đề xuất gồm API lịch sử ứng dụng và có thể là chỉ số được sử dụng để đo lường mức độ tương tác được gọi là “Khả năng đáp ứng”.
  • Sự thật 6: Các chỉ số có thể thay đổi theo thời gian và các mức để tính. Google đã đổi mới các chỉ số được sử dụng để đo tốc độ trong các công cụ của mình trong những năm qua. Các ngưỡng của đo cũng có nhiều thay đổi được đề xuất hơn đối với các chỉ số.

Trích: “Tôi sẽ không quá ngạc nhiên nếu kích cỡ của một trang web được mở rộng. Bạn có thể vượt qua các chỉ số hiện tại bằng cách ưu tiên nội dung mà vẫn có một trang cực kỳ lớn.”

core web vitals
Sự thật về Core Web Vitals

3. Core Web Vitals có quan trọng với SEO

Khi nói về Core Web Vitals, các đại diện của Google đã gọi đây là những yếu tố xếp hạng nhỏ hoặc thậm chí là yếu tố quyết định. Hiện đã có các tiêu chí xếp hạng nhắm mục tiêu vào số liệu tốc độ trong nhiều năm.

Do vậy, các tác động sẽ hiển thị khi bản cập nhật trải nghiệm trang dành cho thiết bị di động được triển khai. Thật không may, cũng có một vài bản cập nhật cốt lõi của Google ở trong khung thời gian với bản cập nhật trải nghiệm trang. Điều này khiến việc xác định tác động trở nên quá phức tạp và khó đưa ra kết luận.

core web vitals
Core Web Vitals là yếu tố quan trọng với SEO

Một vài nghiên cứu đã tìm thấy một số mối tương quan tích cực giữa việc vượt qua Core Web Vitals và xếp hạng tốt hơn. Điều này giống như rằng một trang web tập trung vào SEO có xu hướng xếp hạng tốt hơn. Nếu trang web đã hoạt động trên Core Web Vitals, có thể cũng đã làm tốt nhiều việc khác.

4. Tìm hiểu 3 thành phần “cốt lõi” của Web Vitals

Dưới đây là ba thành phần hiện tại của Core Web Vitals và những gì mà 3 phần tử này đo lường:

4.1. Largest Contentful Paint

LCP là thành phần hiển thị lớn duy nhất được tải trong chế độ xem. Phần tử lớn nhất thường là một hình ảnh nổi bật hoặc có thể là thẻ <h1>. Nhưng phần này cũng có thể là bất kỳ cái nào trong số này:

  • Phần tử <img>.
  • Phần tử <image> bên trong phần tử <svg>.
  • Hình ảnh bên trong phần tử <video>.
  • Hình nền được tải bằng hàm url () Các khối  văn bản <svg> và <video> có thể được thêm vào trong tương lai.
core web vitals
Core web vitals – LCP là phần tử hiển thị lớn nhất được tải trong chế độ xem

4.1.1. Cách kiểm tra LCP như thế nào?

Thông tin chi tiết về tốc độ trang, phần tử LCP sẽ được chỉ định trong phần “Chẩn đoán”. Ngoài ra, hãy lưu ý rằng chỉ có một tab để chọn LCP và sẽ chỉ hiển thị các vấn đề liên quan. Để kiểm tra LCP, trong Chrome DevTools, bạn sẽ làm theo các bước sau:

  • Ở phần hiệu suất, bạn chọn “Ảnh chụp màn hình”.
  • Bạn nhấp vào “Bắt đầu lập hồ sơ và tải lại trang” LCP nằm trên biểu đồ thời gian
  • Nhấp vào nút; đây là yếu tố cho LCP.
core web vitals
Kiểm tra Core web vitals  –  LCP

4.1.2. Cách cải thiện chỉ số LCP

Như chúng ta đã thấy trong PageSpeed Insights, có rất nhiều vấn đề cần được giải quyết khiến LCP trở thành chỉ số khó cải thiện nhất. Nghiên cứu đã chỉ ra hầu hết các trang web dường như không cải thiện LCP theo thời gian. Dưới đây là một số khái niệm cần ghi nhớ và một số cách bạn có thể cải thiện LCP.

Nhỏ hơn là nhanh hơn

Nếu bạn có thể loại bỏ bất kỳ tệp nào hoặc giảm kích thước của chúng, thì trang của bạn sẽ tải nhanh hơn. Điều này có nghĩa là bạn có thể muốn xóa bất kỳ tệp nào hay các phần của mã không được sử dụng 

Để thực hiện điều này sẽ phụ thuộc rất nhiều vào thiết lập của bạn, quá trình này được gọi là tree shaking. Điều này thường được tiến hành thông qua một số quy trình tự động. Nhưng trong một số hệ thống, bước này có thể không có giá trị. Ngoài ra còn có tính năng nén, giúp kích thước tệp nhỏ hơn. Khá nhiều loại tệp được sử dụng để xây dựng trang web có thể được nén gồm CSS, JavaScript, Hình ảnh và HTML.

Gần hơn là nhanh hơn

Thông tin cần có thời gian để đến với người tiếp nhận. Bạn càng ở xa máy chủ, thì càng mất nhiều thời gian để truyền dữ liệu. Trừ khi bạn phục vụ ở một khu vực địa lý nhỏ. Bạn có mạng phân phối nội dung (CDN) – một phát hiện hay. thì CDN sẽ cung cấp cho bạn cách để kết nối và phân chia trang web của bạn đến gần hơn với người dùng. Việc này giống như tạo bản sao máy chủ của bạn ở các vị trí khác nhau trên thế giới.

Sử dụng cùng một máy chủ nếu có thể

Khi bạn lần đầu tiên kết nối với máy chủ. Điều này đồng nghĩa sẽ có một quy trình điều hướng web và thiết lập kết nối an toàn giữa bạn và máy chủ. Quá trình này mất một khoảng thời gian. Mỗi kết nối mới bạn cần thực hiện sẽ làm tăng thêm độ trễ trong khi hoạt động này diễn ra theo cùng một quy trình. Nếu bạn lưu trữ tài nguyên của mình trên cùng một máy chủ, bạn có thể khắc phục những sự chậm trễ đó.

Nếu không thể sử dụng cùng một máy chủ, bạn có thể dùng kết nối trước hoặc tìm nạp trước DNS để bắt đầu kết nối sớm hơn. Một trình duyệt thường sẽ đợi HTML tải xong trước khi bắt đầu kết nối. Nhưng với kết nối trước hoặc tìm nạp trước DNS, nó bắt đầu sớm hơn bình thường. Xin lưu ý rằng DNS-prefetch hỗ trợ tốt hơn so với Preconnect.

core web vitals
Cải thiện chỉ số LCP – core web vitals
Lưu vào bộ nhớ cache những gì bạn có thể

Khi bạn lưu các tài nguyên vào bộ nhớ cache, chúng sẽ được tải xuống lần xem trang đầu tiên nhưng không cần tải xuống cho các lần xem trang tiếp theo. Với các tài nguyên đã có sẵn, việc tải trang bổ sung sẽ nhanh hơn nhiều. Bạn cần kiểm tra số lượng tệp được tải xuống trong lần tải trang thứ hai.

Ưu tiên các nguồn lực khác

Để vượt qua kiểm tra LCP, bạn nên ưu tiên cách tải tài nguyên của mình trong đường dẫn hiển thị quan trọng. Bạn muốn sắp xếp lại thứ tự các thứ được tải xuống và xử lý. Trước tiên, bạn cần tải các tài nguyên cần thiết để người dùng xem nội dung ngay lập tức, sau đó tải phần còn lại.

Nhiều trang web có thể đạt được thời gian dành cho LCP bằng cách chỉ cần thêm một số câu lệnh tải trước cho những thứ như hình ảnh chính, cũng như các biểu định kiểu và phông chữ cần thiết.

Hình ảnh sớm

Nếu bạn không cần hình ảnh, giải pháp hiệu quả nhất là loại bỏ nó. Nếu trang web của bạn phải có hình ảnh, thì nên tối ưu hóa kích thước và chất lượng để giữ cho nó càng nhỏ càng tốt. Đầu tiên, bạn có thể muốn tải trước hình ảnh. Thao tác này sẽ bắt đầu tải xuống hình sớm hơn một chút. Điều này có nghĩa là nó sẽ hiển thị trước. Câu lệnh tải trước này có dạng như sau:

<link rel = “preload” as = “image” href = “cat.jpg” imagesrcset = “cat_400px.jpg 400w, cat_800px.jpg 800w, cat_1600px.jpg 1600w “ imagesizes = “50vw”>

HÌnh ảnh trễ

Bạn nên tải bất kỳ hình ảnh nào mà bạn không cần ngay lập tức. Bạn có thể sử dụng loading = “lazy” như thế này: <img src = “cat.jpg” alt = “cat” loading = “lazy”>

core web vitals
Cải thiện chỉ số LCP về các yếu tố khác nhau
CSS sớm

Chúng ta đã nói về việc loại bỏ CSS không sử dụng và giảm thiểu CSS bạn có. Điều quan trọng khác bạn nên làm là nội tuyến CSS quan trọng. Đây là việc thực hiện lấy một phần CSS cần thiết để tải nội dung mà người dùng nhìn thấy ngay lập tức và sau đó áp dụng trực tiếp vào HTML. Khi HTML được tải xuống, tất cả CSS cần thiết để tải những gì người dùng thấy đã có sẵn.

CSS trễ

Với bất kỳ CSS bổ sung nào không quan trọng, bạn sẽ muốn áp dụng CSS đó sau. Bạn có thể tiếp tục tải xuống CSS với câu lệnh tải trước nhưng không áp dụng CSS cho đến khi sự kiện  được tải lên. Điều này giống như: <link rel = “preload” href = “stylesheet.css” as = “style” onload = “this.rel = ‘stylesheet'”>

JAVASCRIPT sớm

Chúng tôi đã nói về việc loại bỏ JavaScript không sử dụng và giảm thiểu những gì bạn có. Nếu bạn đang sử dụng khung JavaScript, thì bạn có thể muốn hiển thị trước hoặc hiển thị cùng phía máy chủ (SSR) của trang. Các tùy chọn khác là nội dung của JavaScript cần thiết sớm. Tương tự như những gì chúng ta đã thảo luận về CSS, đây là nơi bạn tải các phần của mã trong HTML hoặc tải trước các tệp JavaScript. Điều này chỉ nên được thực hiện cho các nội dung cần thiết.

JAVASCRIPT muộn
Bất kỳ JavaScript nào bạn không cần tải sau ngay lập tức. Có hai cách để làm điều đó là dùng các thuộc tính trì hoãn và không đồng bộ hóa. Các thuộc tính này có thể được thêm vào các thẻ script của bạn. Thông thường, một tập lệnh đang được tải xuống sẽ chặn trình phân tích cú pháp trong khi tải xuống và thực thi.
Async sẽ cho phép phân tích cú pháp và tải xuống diễn ra cùng một lúc nhưng vẫn chặn phân tích cú pháp trong quá trình thực thi tập lệnh. Defer sẽ không chặn phân tích cú pháp trong quá trình tải xuống và chỉ thực thi sau khi HTML hoàn tất quá trình phân tích cú pháp.

4.2. Cumulative Layout Shift

CLS đo lường cách các phần tử di chuyển xung quanh hoặc mức độ ổn định của bố cục trang. CLS tính đến kích thước của nội dung và khoảng cách di chuyển. Google đã cập nhật cách đo CLS. Trước đây, nó sẽ tiếp tục đo lường ngay cả sau khi tải trang đầu tiên. Nhưng giờ đây, phần này đã bị giới hạn trong khung thời gian năm giây.
Sẽ rất khó chịu nếu bạn cố gắng nhấp vào thứ gì đó trên một trang thay đổi và cuối cùng bạn lại chọn vào thứ gì đó mà mình không có ý định. Mọi người nhấn vào một thứ và đột nhiên không được ở trên cùng một trang web. Là một người dùng, tôi thấy điều đó thật khó chịu.
Các nguyên nhân phổ biến của CLS bao gồ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.
  • Chèn nội dung bằng JavaScript.
  • Áp dụng phông chữ hoặc kiểu trễ trong quá trình tải.

4.2.1. Cách kiểm tra CLS

Trong PageSpeed Insights, nếu bạn chọn CLS, có thể thấy tất cả các vấn đề liên quan. Điều chính cần chú ý ở đây là “Tránh thay đổi bố cục lớn.” Hệ thống đang sử dụng WebPageTest. Trong Chế độ xem cuộn phim, hãy sử dụng các tùy chọn sau:

  • Đánh dấu sự thay đổi của bố cục
  • Kích thước hình thu nhỏ: Lớn
  • Khoảng thời gian hình thu nhỏ: 0,1 giây
core web vitals
Kiểm tra CLS

Lưu ý cách phông chữ của hệ thống khởi động lại từ 5,1 giây đến 5,2 giây. Việc thay đổi bố cục khi phông chữ tùy chỉnh của được áp dụng. Tạp chí Smashing cũng có một kỹ thuật thú vị trong đó nó phác thảo mọi thứ bằng một đường thẳng màu đỏ 3px và ghi lại một đoạn video tải trang để xác định vị trí thay đổi bố cục đang diễn ra.

4.2.2. Cách cải thiện chỉ số CLS

Trong hầu hết các trường hợp, để tối ưu hóa CLS, bạn sẽ giải quyết các vấn đề liên quan đến hình ảnh, phông chữ hoặc có thể là nội dung được chèn vào. Hãy xem xét từng trường hợp như sau.

Hình ảnh

Đối với hình ảnh, những gì bạn không nhất thiết phải tìm cách để làm lấp đầy khoảng trắng thông qua sự thay đổi hình ảnh. Điều này có nghĩa là việc thiết lập chiều cao và chiều rộng của hình ảnh được thực hiện bằng cách chỉ định chúng trong thẻ <img>.

Đối với hình ảnh đáp ứng, bạn cần sử dụng srcset như sau: <img width = “1000” chiều cao = “1000” src = “cún con-1000.jpg” srcset = “cún-1000.jpg 1000w, cún-2000.jpg 2000w, cún-3000.jpg 3000w” alt = “Cún con với bóng bay” />. Bên cạnh đó bạn nên dành không gian tối đa cần thiết cho bất kỳ nội dung động nào được thêm vào như là quảng cáo.

core web vitals
Cải thiện CLS thông qua việc thiết lập hình ảnh
Phông chữ

Mục tiêu của bạn là đưa phông chữ trên màn hình càng nhanh càng tốt và sự thay đổi một phông chữ khác. Khi một phông chữ được tải hoặc thay đổi, bạn sẽ có thấy phông chữ đáng để thay đổi như Flash of Invisible Text (FOIT) hoặc Flash of Unstyled Text (FOUT).

Nếu bạn có thể sử dụng phông chữ hệ thống, bạn sẽ không cần phải tải những kiểu phông chữ khác nữa. Nếu bạn phải sử dụng phông chữ tùy chỉnh, phương pháp tốt nhất hiện tại để giảm thiểu CLS là kết hợp <link rel = ”preload”> (sẽ cố gắng lấy phông chữ của bạn càng sớm càng tốt) và Font-display: option (sẽ cung cấp cho phông chữ của bạn một khoảng thời gian nhỏ để tải).

Nếu phông chữ chưa kịp hiển thị, lần tải trang đầu tiên sẽ chỉ có một phông chữ mặc định. Phông chữ tùy chỉnh của bạn sau đó sẽ được lưu vào bộ nhớ đệm và hiển thị khi tải trang tiếp theo.

Nội dung được đưa vào

Khi nội dung được chèn động vào bên trên nội dung hiện có, điều này gây ra sự thay đổi bố cục. Nếu bạn định làm điều này, hãy chú ý dành đủ chỗ để chèn cho nội dung trước.

4.3. First Input Delay

FID là thời gian từ khi người dùng tương tác với trang của bạn đến khi trang phản hồi. Bạn cũng có thể coi đó là khả năng đáp ứng.

Các tương tác mẫu:

  • Nhấp vào một liên kết hoặc nút
  • Nhập văn bản vào trường trống
  • Chọn menu thả xuống Nhấp vào hộp kiểm
  • Một số sự kiện như cuộn hoặc thu phóng không được tính.

FID có thể khiến bạn khó chịu khi cố gắng nhấp vào một thứ gì đó mà không có gì xảy ra trên trang.

Không phải tất cả người dùng sẽ tương tác với một trang, vì vậy trang có thể không có giá trị FID. Đây cũng là lý do tại sao các công cụ kiểm tra trong phòng thí nghiệm sẽ không có giá trị vì chúng không tương tác với trang. Những gì bạn có thể xem cho các bài kiểm tra trong phòng thí nghiệm là Tổng thời gian chặn (TBT). Trong Thông tin chi tiết về tốc độ trang, bạn có thể sử dụng tab TBT để xem các vấn đề liên quan.

4.3.1. Nguyên nhân nào gây ra sự chậm trễ?

Chỉ có một luồng chính và JavaScript cạnh tranh để chạy các tác vụ trên. Hãy nghĩ về điều này giống như việc JavaScript phải thay phiên nhau để chạy. Trong khi tác vụ chạy, một trang không thể phản hồi thông tin nhập của người dùng. Đây là sự chậm trễ được cảm nhận. Tác vụ càng dài, người dùng trải qua thời gian trễ càng dài. Thời gian nghỉ giữa các tác vụ là cơ hội mà trang phải chuyển sang tác vụ người dùng nhập và phản hồi lại.

core web vitals
Nguyên nhân gây chậm trễ

4.3.2. Tối ưu hóa FID

Hầu hết các trang đều vượt qua kiểm tra FID. Nhưng nếu bạn cần làm việc trên FID, chỉ có một số mục bạn có thể làm việc. Nếu bạn có thể giảm số lượng JavaScript đang chạy, thì hãy làm điều đó.
Nếu bạn đang sử dụng khung JavaScript, thì cần có rất nhiều JavaScript để tải trang. JavaScript đó có thể mất một lúc để xử lý trong trình duyệt và điều đó có thể gây ra sự chậm trễ. Nếu bạn sử dụng kết xuất trước hoặc (SSR), bạn chuyển gánh nặng này từ trình duyệt sang máy chủ.
Một tùy chọn khác là chia nhỏ JavaScript để nó chạy trong thời gian ngắn hơn. Bạn thực hiện các nhiệm vụ dài làm trì hoãn phản hồi đối với thông tin nhập của người dùng và chia chúng thành các tác vụ nhỏ hơn có thời gian ngắn hơn. Điều này được thực hiện bằng cách tách mã, chia nhỏ các nhiệm vụ thành các phần nhỏ hơn.

Ngoài ra còn có tùy chọn chuyển một số JavaScript sang Service worker. Tôi đã đề cập rằng JavaScript cạnh tranh cho một luồng chính trong trình duyệt, nhưng đây là một giải pháp giúp cung cấp một nơi khác để hoạt động.

core web vitals
Tối ưu hóa FID
Có một số sự đánh đổi trong quá trình lưu vào bộ nhớ đệm. Nhân viên dịch vụ không truy cập được vào DOM, vì vậy không thể thực hiện bất kỳ cập nhật hoặc thay đổi nào. Nếu bạn định chuyển JavaScript sang nhân viên dịch vụ, bạn thực sự cần có một nhà phát triển để biết phải làm gì.

5. Các công cụ đo lường Core Web Vitals

Nhiều công cụ giúp bạn có thể sử dụng để kiểm tra và giám sát. Nói chung, bạn muốn xem dữ liệu trường thực tế, là dữ liệu bạn sẽ được đo lường. Nhưng dữ liệu phòng thí nghiệm hữu ích hơn cho việc thử nghiệm.

Sự khác biệt giữa dữ liệu phòng thí nghiệm và dữ liệu hiện trường là dữ liệu hiện trường xem xét người dùng thực, điều kiện mạng, thiết bị, bộ nhớ đệm, v.v. Nhưng dữ liệu phòng thí nghiệm được kiểm tra nhất quán dựa trên cùng các điều kiện để làm cho kết quả thử nghiệm có thể lặp lại.

Nhiều công cụ trong số này sử dụng Lighthouse làm cơ sở cho các bài kiểm tra trong phòng thí nghiệm của họ. Ngoại lệ là WebPageTest, mặc dù bạn cũng có thể chạy thử nghiệm Lighthouse với nó.

Trường dữ liệu

Có một số công cụ bổ sung mà bạn có thể sử dụng để thu thập dữ liệu giám sát người dùng thực (RUM) của riêng mình. Bên cạnh đó, công cụ còn cung cấp phản hồi tức thì hơn về cách cải thiện tốc độ ảnh hưởng đến người dùng thực tế của bạn (thay vì chỉ dựa vào các bài kiểm tra trong phòng thí nghiệm).

core web vitals
Trường dữ liệu
Dữ liệu thí nghiệm

PageSpeed Insights là công cụ để kiểm tra dữ liệu từng trang một. Nhưng nếu bạn muốn xem cả dữ liệu phòng và dữ liệu trường trên quy mô lớn, thì cách dễ nhất để có được điều đó là thông qua API. Bạn có thể kết nối dễ dàng với Công cụ quản trị trang web của Ahrefs (miễn phí) hoặc Kiểm tra trang web của Ahrefs và nhận báo cáo chi tiết hiệu suất của bạn.

Core Web Vitals là một chỉ số quan trọng góp phần giúp cho Google xác định được số người dùng tham gia vào web. Từ đó hệ thống sẽ đưa ra những đánh giá chính xác nhất về bài viết của mọi người. Hy vọng sau khi tham khảo bài viết của SEODO, bạn đọc sẽ có thêm nhiều kiến thức chỉ số đo lường trải nghiệm người dùng được Google rất tin tưởng này.

Cùng tìm hiểu thêm về những yếu tố liên quan về Thuật toán SEO của bạn qua các bài viết :

Đánh giá 5 sao

Viết một bình luận

Website này sử dụng Akismet để hạn chế spam. Tìm hiểu bình luận của bạn được duyệt như thế nào.