Core Web Vitals là chỉ số tốc độ nằm trong tín hiệu Trải nghiệm trang của Google được sử dụng với mục đích đo trải nghiệm của người dùng. Các chỉ số đo tải hình ảnh với Largest Contentful Paint (LCP), độ ổn định hình ảnh với Cumulative Layout Shift (CLS) và tương tác với First Input Delay (FID).
Được cập nhật vào tháng 6 năm 2021, nhưng không phải ai cũng biết tới Core Web Vitals và tầm quan trọng của nó đối với SEO.
Vậy nên trong bài viết này, chúng ta sẽ cùng nhau tìm hiểu xem Core Web Vitals là gì? Tại sao Core Web Vitals lại quan trọng đối với SEO? Cũng như cách đánh giá và sửa lỗi chúng.
Core Web Vitals là gì?
Core Web Vitals là một tập hợp các chỉ số được chuẩn hóa từ Google, giúp các nhà phát triển web hiểu được cách người dùng trải nghiệm trên một trang web. Mặc dù Core Web Vitals được tạo ra để dành cho các nhà phát triển, tuy nhiên những công cụ này hoàn toàn có thể được sử dụng bởi tất cả các chủ sở hữu trang web vì chúng có khả năng ‘phá vỡ’ mọi trải nghiệm trong thế giới thực của người dùng trên một trang web.
Core Web Vitals có khả năng xác định được các vấn đề liên quan tới trải nghiệm người dùng thông qua cách tạo số liệu dành cho ba lĩnh vực chính của trải nghiệm người dùng, bao gồm:
- Hiệu suất tải trang.
- Dễ tương tác.
- Tính ổn định trực quan của một trang xét từ góc nhìn của người dùng.
Mỗi chỉ số này sẽ cung cấp những quan điểm riêng của họ về các yếu tố khác nhau, ảnh hưởng tới cách người dùng tương tác với trang web. Trong khi đó, các nhà phát triển cần suy nghĩ về ‘trải nghiệm người dùng’ từ góc nhìn tổng thể, các chỉ số độc lập này sẽ giúp các nhà phát triển chia nhỏ các biến khác nhau thành các phần nhỏ hơn để chủ sở hữu trang web có thể xác định và khắc phục các vấn đề liên quan tới kỹ thuật trên trang web của họ.
Điều quan trọng mà bạn cần lưu ý rằng, các chỉ số này không thể diễn tả hết toàn bộ câu chuyện về trải nghiệm của người dùng trên một trang web, nhưng mỗi chỉ số lại có thể ghép được với nhau để giúp các nhà phát triển khắc phục được sự cố một cách hiệu quả và có phương pháp.
Tại sao Core Web Vitals lại quan trọng?
Google đang có kế hoạch biến những trải nghiệm trên trang web trở thành một yếu tố xếp hạng chính thức của họ.
Trải nghiệm trang sẽ là một tập hợp các yếu tố mà Google coi là quan trọng đối với trải nghiệm của người dùng, bao gồm:
- HTTPS
- Độ thân thiện với thiết bị di động.
- Thiếu các tab bật lên xen kẽ
- “Trình duyệt web an toàn” (về cơ bản có thể hiểu là không có bất kỳ phần mềm độc hại nào trên trang của bạn).
Và Core Web Vitals sẽ là một phần siêu quan trọng trong số các yếu tố đó.
Trên thực tế, đánh giá dựa trên thông báo và chính tên gọi của chúng, thật công bằng khi nói rằng các quan điểm về ‘web cốt lõi’ sẽ chiếm phần lớn nhất trong điểm số trải nghiệm trang của bạn.
Điều quan trọng đã chỉ ra rằng điểm số trải nghiệm trang ‘tuyệt vời’ sẽ không phải là tất cả để có thể đưa bạn lên vị trí số một trong Google một cách kỳ diệu. Google đã nhanh chóng chỉ ra rằng, trải nghiệm trang là một trong số (khoảng 200) các yếu tố mà họ sử dụng để xếp hạng các trang web trong tìm kiếm.
Điều đó có nghĩa rằng, bạn không cần phải lăn tăn. Google cho biết bạn phải cải thiện điểm số Core Web Vitals cho trang web của mình tới tận sang năm.
Nhưng nếu bạn muốn cải thiện điểm Core Web Vitals của mình trước đó, thì thật tuyệt.
Bởi vì trong phần sau, tôi sẽ chia nhỏ cả ba số liệu chính trong Core Web Vitals. Và chỉ cho bạn cách cải thiện từng thứ đó.
Các thành phần của Core Web Vitals
Dưới đây là ba thành phần hiện tại của Core Web Vitals:
- Largest Contentful Paint (LCP).
- First Input Delay (FID).
- Cumulative Layout Shift (CLS).
Largest Contentful Paint (LCP)
LCP là thời gian tải một trang theo quan điểm của người dùng thực tế.
Nói theo cách khác: đó là thời gian từ việc nhấp vào một liên kết để có thể nhìn thấy được toàn bộ nội dung trên màn hình.
LCP khác với các phép đo tốc độ trang khác. Nhiều chỉ số tốc độ trang khác (như TTFB và First Contextual Paint) đều không nhất thiết đại diện cho việc người dùng sẽ mở một trang web như thế nào.
Mặt khác, LCP sẽ tập trung vào những gì thực sự quan trọng khi nói tới tốc độ trang: Khả năng xem và tương tác trên trang của bạn.
Cách xem LCP
Trong PageSpeed Insights, phần tử LCP sẽ được chỉ định trong phần chẩn đoán. Đối với trang đã thử nghiệm, LCP chính là hình ảnh nổi bật của chúng tôi ở trên các bài đăng của blog.
Trong Chrome DevTools, hãy thực hiện các bước sau:
1. Performance > chọn “Screenshots”
2. Nhấp vào ‘Start profiling and reload page’
3. LCP nằm trên biểu đồ thời gian
4. Nhấp vào nút; đây chính là yếu tố cho LCP
Bạn có thể kiểm tra điểm LCP trang web của mình bằng Google PageSpeed Insights.
Cái nào thực sự hữu ích? Đặc biệt là khi nói tới các khu vực đốm cần cải thiện. Một điều thú vị khi sử dụng Google PageSpeed Insights ở trên một công cụ như webpagetest.org là bạn có thể xem trang của mình hoạt động như thế nào trong thế giới thực (dựa trên dữ liệu trình duyệt Chrome).
Điều đó thể hiện rằng, bạn nên xem cả dữ liệu LCP của mình trong Google Search Console.
Tại sao?
Cũng giống như Google PageSpeed Insights, dữ liệu ở trong GSC đến từ Báo cáo trải nghiệm người dùng trên Chrome.
Nhưng không giống PageSpeed Insights ở chỗ, bạn có thể xem dữ liệu LCP ở trên toàn bộ trang web của mình. Vì vậy, thay vì việc bạn đi phân tích từng trang ngẫu nhiên, bạn sẽ có được danh sách các URL tốt – xấu … hay đâu đó là ở giữa.
Nói đến Google thì họ có các nguyên tắc LCP cụ thể. Họ chia tốc độ LCP ra thành ba nhóm: Tốt, Cần cải thiện và Kém.
Tóm lại, điều bạn muốn là mọi trang trên trang web của mình đạt được LCP trong vòng 2,5 giây? Đây có thể là một thử thách thực sự đối với các trang web lớn hay các trang có nhiều tính năng.
Ví dụ: Trang này từ website của backlinko.com có hàng chục hình ảnh với độ phân giải cao.
Đó là lý do vì sao LCP trên trang đó là 5,1 giây (bị coi là ‘kém’).
Đây hoàn toàn không phải là một cái cớ. Nhưng nó cho thấy rằng việc cải thiện LCP không hề đơn giản như cài đặt một CDN. Trong trường hợp này, chúng tôi có thể sẽ phải xóa đi một số hình ảnh ra khỏi trang và làm sạch mã của trang.
Công việc này khó khăn? Chắc chắn là như vậy. Nhưng giá trị mà nó đem lại cũng chắc chắn không kém.
Cùng với đó, dưới đây là một số điều mà bạn có thể làm để cải thiện LCP trên trang web của mình:
- Xóa mọi tập lệnh của bên thứ ba không cần thiết: nghiên cứu tốc độ trang gần đây của chúng tôi cho thấy mỗi tập lệnh của bên thứ ba làm chậm một trang 34 mili giây.
- Nâng cấp máy chủ lưu trữ web của bạn: Máy chủ lưu trữ tốt hơn = tổng thời gian tải nhanh hơn (bao gồm cả LCP).
- Thiết lập tải chậm: Tải chậm khiến hình ảnh chỉ tải khi ai đó cuộn xuống trang của bạn. Có nghĩa là bạn có thể đạt được LCP nhanh hơn đáng kể.
- Xóa các phần tử trang lớn: Google PageSpeed Insights sẽ cho bạn biết liệu trang của bạn có phần tử làm chậm LCP của trang hay không.
- Giảm thiểu CSS của bạn: CSS cồng kềnh có thể trì hoãn đáng kể thời gian LCP.
First Input Delay (FID)
Tiếp theo, chúng ta hãy cùng xem xét thành phần thứ hai của Core Web Vitals trên Google: First Input Delay (FID).
FID là thời gian từ khi người dùng tương tác với trang của bạn cho tới khi trang có thể phản hồi lại. Bạn cũng có thể coi đây là khả năng đáp ứng của trang và điều này sẽ không bao gồm việc cuộn trang hay thu phóng trang.
Có thể nói tại thời điểm hiện tại, trang của bạn đã đạt được FCP. Nhưng câu hỏi được đặt ra là: người dùng có thể tương tác với trang của bạn không?
Đó chính xác là những gì mà FID đo lường: thời gian người dùng thực sự tương tác với trang của bạn.
Nguyên nhân của FID
JavaScript sẽ cạnh tranh cho luồng chính và chỉ có một luồng chính với JavaScript cạnh tranh nhau để có thể chạy các tác vụ trên đó.
Trong khi các tác vụ đang chạy, một trang sẽ không thể phản hồi thông tin đăng nhập của người dùng. Đây là sự chậm trễ có thể cảm nhận được. Tác vụ càng dài, người dùng sẽ trải qua thời gian trễ càng dài. Khoảng nghỉ giữa các tác vụ chính là cơ hội mà trang có để chuyển tác vụ người dùng nhập và phản hồi những gì mà họ muốn.
Ví dụ về các tương tác bao gồm:
- Chọn một tùy chọn từ menu.
- Nhấp vào một liên kết điều hướng của trang web.
- Nhập email tương tác, để lại bình luận, nhận thông tin sau này.
- Mở “accordion text” ở trên thiết bị di động.
Google coi FID là quan trọng vì nó tính đến cả cách mà người dùng thực tế tương tác với các trang web.
Và cũng giống như FCP, họ sẽ có các tiêu chí cụ thể về những gì tạo nên FID có thể chấp nhận được.
Về mặt kỹ thuật, FID sẽ đo lường thời gian ‘xuất hiện những hành động’ trên một trang. Vì vậy, có thể hiểu đây là điểm tốc độ trang. Nhưng nó sẽ vượt xa hơn điểm tốc độ trang ở chỗ, nó sẽ đo cả thời gian mà người dùng thực sự làm điều gì đó trên trang của bạn.
Đối với một trang có 100% là nội dung (như một bài đăng trên blog hay các bài báo), FID có lẽ thực sự không phải là một vấn đề lớn. Sự ‘tương tác’ thực sự duy nhất ở đây là cuộn xuống trang hay chụm / click để phóng to và thu nhỏ.
Trên thực tế, Search Console của tôi thậm chí còn không báo cáo FID cho trang web của tôi.
Tôi đoán là do tôi thực sự không có bất kỳ trang ‘đăng nhập’ nào hay những trang mà ai đó sẽ cần phải nhập nội dung vào đó ngay lập tức.
Nhưng đối với các trang đăng nhập, trang đăng ký hay các trang khác mà người dùng cần nhanh chóng nhấp vào một thứ gì đó thì FID rất LỚN.
Ví dụ: Hãy thử nghĩ về trải nghiệm cho một trang kiểu dạng như thế này:
Với một trang đăng nhập như vậy, thời gian tải nội dung không phải là điều quan trọng nhất. Điều quan trọng là bạn có thể nhập chi tiết thông tin đăng nhập của mình nhanh như thế nào.
Cùng với đó, đây là một số điều mà bạn có thể làm để cải thiện điểm FID trên trang web của mình:
- Giảm thiểu (hoặc trì hoãn) JavaScript: Người dùng gần như không thể tương tác với một trang trong khi trình duyệt đang tải JS lên. Vì vậy, giảm thiểu hoặc trì hoãn JS trên trang của bạn là chìa khóa cho FID.
- Xóa mọi tập lệnh của bên thứ ba không quan trọng: Cũng giống như với FCP, các tập lệnh của bên thứ ba (như Google Analytics, bản đồ nhiệt, v.v.) có thể tác động tiêu cực đến FID.
- Sử dụng bộ nhớ cache của trình duyệt: Điều này giúp tải nội dung trên trang của bạn nhanh hơn. Điều này giúp trình duyệt của người dùng của bạn vượt qua các tác vụ tải JS nhanh hơn.
Cumulative Layout Shift (CLS)
Cumulative Layout Shift là mức độ ổn định của một trang khi nó tải (hay còn gọi là “mức độ ổn định về hình ảnh”). CLS đo lường cách mà các phần tử di chuyển xung quanh hay còn gọi là mức độ ổn định trên bố cục trang. Nó sẽ tính tới kích thước của nội dung và khoảng cách mà nó di chuyển.
Một vấn đề chính với số liệu là nó sẽ tiếp tục việc đo lường ngay cả sau khi tải trang đầu tiên. Google đang lấy ý kiến phản hồi về các số liệu cụ thể này, vì vậy chúng tôi có thể thấy được một số thay đổi về số liệu này trong tương lai.
Nói cách khác: Nếu các phần tử trên trang của bạn di chuyển xung quanh khi trang đang tải, thì bạn đang có CLS cao. Điều này là không tốt.
Sẽ là rất khó chịu nếu bạn đang cố gắng nhấp vào một cái gì đó trên một trang đang tải và cuối cùng bạn lại nhấp phải vào một mục gì đó mà bạn không có chủ định vào đó. Điều này thường xảy ra với tôi ở mọi lúc, khi tôi nhấp vào một thứ và đột nhiên thứ tôi nhấp phải là một quảng cáo và thậm chí chúng không phải là ở trên cùng một trang web. Với tư cách là một người dùng, thật khó chịu khi gặp phải vấn đề này.
Thay vào đó, bạn sẽ muốn các phần tử trên trang của mình ở mức ổn định khi tải trang lên. Bằng cách đó, người dùng sẽ không phải nhớ lại vị trí của các liên kết, hình ảnh và lĩnh vực khi trang được tải đầy đủ, giúp cho người dùng tránh phải việc bấm nhầm vào một cái gì đó.
Các nguyên nhân phổ biến của CLS bao gồm:
Dưới đây là các tiêu chí cụ thể mà Google đưa ra cho CLS:
Như bạn có thể thấy, đây là những điều mà tôi cần phải thực hiện để có thể đạt tới. Đặc biệt là ở trên thiết bị di động.
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 muộn khi tải
Cách xem CLS
Trong PageSpeed Insights, bên dưới phần chẩn đoán, bạn sẽ tìm thấy một danh sách các yếu tố đang thay đổi.
Sử dụng WebPageTest, trong chế độ Filmstrip View, 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
Lưu ý: Cách chúng tôi định lại phông chữ sẽ vào khoảng giữa 5,1 giây – 5,2 giây, bố cục sẽ thay đổi khi phông chữ tùy chỉnh của chúng tôi được áp dụng.
Dưới đây là một số điều đơn giản bạn có thể làm để giảm thiểu CLS
- Sử dụng thứ nguyên thuộc tính kích thước đặt cho bất kỳ phương tiện nào (video, hình ảnh, GIF, đồ họa thông tin, v.v.): Bằng cách đó, trình duyệt của người dùng biết chính xác phần tử đó sẽ chiếm bao nhiêu dung lượng trên trang đó. Và sẽ không thay đổi nó ngay lập tức khi trang tải đầy đủ.
- Đảm bảo các phần tử quảng cáo có không gian dành riêng: Nếu không, chúng có thể đột ngột xuất hiện trên trang, đẩy nội dung xuống dưới, lên trên hoặc sang một bên.
- Thêm các phần tử giao diện người dùng mới dưới màn hình đầu tiên: Bằng cách đó, chúng không đẩy nội dung xuống mà người dùng “mong đợi” ở nguyên vị trí của nó.
Công cụ đo lường Core Web Vitals
Sự khác biệt giữa dữ liệu thử nghiệm và dữ liệu thực tế là dữ liệu thực tế sẽ được xem xét bởi người dùng thực, điều kiện kết nối, thiết bị hay bộ nhớ đệm,v.v. và dữ liệu thử nghiệm sẽ được kiểm tra dựa trên sự nhất quán của các điều kiện tương tự như dữ liệu thực tế với hy vọng rằng các kết quả thử nghiệm có thể phản hồi đúng với thực tế.
Trường dữ liệu
Dữ liệu thử nghiệm
Tôi thích báo cáo từ Google Search Console vì tôi có thể xem dữ liệu cho nhiều trang trong cùng một lúc, nhưng dữ liệu thường hơi bị trễ và luân phiên trong khoảng 28 ngày, vì vậy các thay đổi có thể sẽ mất chút thời gian để có thể hiển thị trong báo cáo.
Trong Chrome 88, Google đang thêm Core Web Vitals trong DevTools.
Ngoài ra, bạn cũng có thể tìm ‘trọng số’ được tính điểm cho Lighthouse bất kỳ lúc nào và xem các thay đổi trong lịch sử.
Đánh giá Core Web Vitals của bạn
Một trong những cách đánh giá Core Web Vitals của bạn đó là sử dụng Google Search Console nhằm giải quyết nhiều trang ở trên một trang web lớn.
Cụ thể: GSC có một phần trong mục Enhancements, nơi mà bạn có thể xem số lượng trang trên trang web của mình đang bị ảnh hưởng bởi mỗi Core Web Vitals.
Sau khi nhấp qua phần này, bạn sẽ thấy một báo cáo dành cho từng vấn đề Core Web Vitals mà trang web của bạn có thể đang gặp khó khăn.
Như ví dụ bên dưới, trang Brightedge.com có một vấn đề nho nhỏ với CLS. Cụ thể có 5 trang của họ đang có vấn đề về CLS như sau:
1. Vấn đề và hướng dẫn, ở trong trường hợp này CLS bị lớn hơn .25
2. Số lượng trang trên trang web của bạn đang bị ảnh hưởng bởi Core Web Vital cụ thể này
3. Một trang ví dụ nơi đang có sự cố xảy ra. Đây là điểm khác biệt chính giữa báo cáo này so với các báo cáo GSC khác. Báo cáo Core Web Vitals sẽ không hiển thị cho bạn mọi trang bạn cần sửa. Thành thật mà nói, sẽ rất lâu và khó khăn để có thể giải quyết tất cả các vấn đề liên quan tới Web Vitals vì bạn có thể sẽ cần sửa mọi thứ ở cấp độ mẫu để sửa nhiều trang cùng một lúc.
4. Danh sách lên đến 20 trang tương tự nơi sự cố này đang xảy ra. Mỗi URL mẫu sẽ hiển thị cho bạn một số trang tương tự. Google đang sử dụng phương pháp này để đánh dấu vị trí các vấn đề tương tự được tìm thấy trên trang mẫu của bạn được tìm thấy trên các trang khác trên toàn bộ trang web của bạn.
Ví dụ: nếu bạn gặp sự cố trên / blog / của mình và vấn đề tương tự đang xảy ra trên các trang trong phần / thông cáo báo chí / của bạn, bạn sẽ chỉ thấy một trong những vấn đề đó trong url ví dụ, nhưng vấn đề khác sẽ hiển thị trong chi tiết ví dụ. Điều này sẽ gợi ý cho bạn rằng nhiều trang hơn trong / thông cáo báo chí / sẽ cần cùng một bản sửa lỗi.
Sửa lỗi Core Web Vitals của bạn
Bây giờ, bạn đã hiểu rõ hơn về mỗi chỉ số Core Web Vitals đang đo lường điều gì và cách mà chúng thể hiện những điểm khó khăn với những người dùng đang cố gắng truy cập nội dung và tương tác với doanh nghiệp của bạn.
Vậy làm sao để sửa lỗi Core Web Vitals?
Dưới đây là các hoạt động giúp bạn sửa lỗi Core Web Vitals.
Các hoạt động phổ biến để giải quyết LCP
- Áp dụng tải tức thì với mẫu PRPL.
- Tối ưu hóa Đường dẫn Hiển thị Quan trọng của bạn.
- Tối ưu hóa các tệp CSS.
- Tối ưu hóa kích thước và nén tệp hình ảnh.
- Tối ưu hóa hoặc xóa phông chữ web.
- Tối ưu hóa hoặc giảm JavaScript của bạn (đối với các trang web do khách hàng hiển thị).
Các hoạt động phổ biến để giải quyết FID
- Giảm tác động của mã bên thứ ba.
- Giảm thời gian thực thi JavaScript.
- Giảm thiểu công việc của chuỗi chính.
- Giữ cho số lượng yêu cầu thấp và kích thước chuyển giao nhỏ.
Các hoạt động chung để giải quyết CLS
- Bao gồm các thuộc tính kích thước trên hình ảnh và phần tử video của bạn hoặc dành không gian bằng các hộp tỷ lệ co CSS.
- Không bao giờ chèn nội dung bên trên nội dung hiện có, ngoại trừ để đáp lại sự tương tác của người dùng.
- Sử dụng hoạt ảnh chuyển đổi thay vì hoạt ảnh của các thuộc tính buộc thay đổi bố cục.
Thông tin nhanh về Core Web Vitals
- Fact 1: Các chỉ số được phân chia giữa máy tính để bàn và thiết bị di động, nhưng chỉ có các tín hiệu di động mới được sử dụng để xếp hạng các trang. Google sẽ ưu tiên chuyển sang việc lập chỉ mục 100% trên các thiết bị di động vào tháng 3 tới, vì vậy việc sử dụng tín hiệu tốc độ trên thiết bị di động là vô cùng hợp lý vì các trang được lập chỉ mục cũng sẽ dựa trên phiên bản dành cho thiết bị di động.
- Fact 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ố sẽ được đánh giá ở phần trăm người dùng thứ 75, 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 vẫn được đánh giá là “cần cải thiện”.
- Fact 3: Các chỉ số sẽ được đánh giá cho từng trang, nhưng nếu không có đủ dữ liệu, John Mueller tuyên bố rằng các tín hiệu từ các phần của trang web hoặc trang web tổng thể có thể được sử dụng.
- Fact 4: Với việc bổ sung các chỉ số mới này, AMP sẽ bị loại bỏ như một yêu cầu khỏi tính năng Câu chuyện hàng đầu trên thiết bị di độ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ó khả năng là các chỉ số từ một danh mục trang lớn hơn hoặc thậm chí toàn bộ tên miền có thể được sử dụng cho việc này.
- Fact 5: Ứng dụng Trang Đơn không đo lường một số chỉ số, FID và LCP, thông qua chuyển đổi trang. Chúng ta sẽ nói về những thứ đó trong một phút nữa.
- Fact 6: Các chỉ số có thể thay đổi theo thời gian và các ngưỡng cũng có thể thay đổi. Google đã thay đổi các chỉ số được sử dụng để đo tốc độ trong các công cụ của họ trong những năm qua cũng như ngưỡng của họ đối với những gì được coi là nhanh hay không. Rất có thể điều này sẽ lại thay đổi trong tương lai. Trên thực tế, chúng tôi đã thực hiện một số công việc cải thiện các chỉ số trước đó vào năm ngoái, nhưng chúng tôi cần thực hiện lại một số công việc để cải thiện các chỉ số mới.
Tổng kết
Ở trên là toàn bộ những chia sẻ, thông tin xung quanh Core Web Vitals của mình. Hy vọng qua bài viết này sẽ giúp ích cho bạn trong việc cải thiện tốc độ trang web và tăng trải nghiệm của người dùng trên website của bạn tốt hơn.
Nếu có bất kỳ câu hỏi thắc mắc hay những thông tin gì mới về Core Web Vitals này, hãy để lại cho VietMoz Academy bình luận ở phía bên dưới nhé!
