Hướng dẫn Core Web Vitals 2022

Trong suốt năm 2021 và đến đầu 2022, chúng ta gặp thuật ngữ Core Web Vitals khắp các bài viết, video về SEO, nó là một phần nâng cấp cực kỳ quan trọng của Google trong tiêu chí xếp hạng trang web mới nhất.

Trong phần cuối của chuyên đề Tăng tốc WordPress thuộc Khoá học Pro WordPress Master 2022, chúng ta sẽ tìm hiểu về Core Web Vitals (CWV), các yếu tố ảnh hưởng đến điểm số CWV và các phương pháp tối ưu tốc độ để vượt qua bài kiểm tra CWV của Google.

Cụ thể, những yếu tố quan trọng nhất trong xếp hạng SEO của Google hiện nay, theo thứ tự là:

1. Nội dung có chất lượng cao và hữu ích
2. Nội dung phù hợp với nhu cầu tìm kiếm của người dùng
3. Page Experience (Trải nghiệm trên trang) – là một tập hợp các dấu hiệu để đánh giá CẢM NHẬN CỦA NGƯỜI DÙNG VỀ TRẢI NGHIỆM TƯƠNG TÁC VỚI TRANG WEB.

Như vậy, ngoài Nội dung (chất lượng – hữu ích – phù hợp) thì Page Experience là nhân tố tác động tới xếp hạng còn lại của Google,  tối ưu Page Experience là nhiệm vụ không thể thiếu trong SEO hiện nay.

Theo Google 2022, Page Experience bao gồm các yếu tố sau:

• Core Web Vitals: các chỉ số quan trọng về trang web, ta sẽ tìm hiểu các chỉ số này ở bên dưới.
• Mobile Friendly: thân thiện với các thiết bị di động (tablet, mobile).
• HTTPS: trang web phải sử dụng giao thức bảo mật https:// hợp lệ (có dùng chứng chỉ SSL).
• No intrusive interstitials: không có quảng cáo xen kẽ gây phiền nhiễu, gây cản trở người dùng trong việc tiếp cận nội dung trên trang web (ví dụ điển hình về quảng cáo gây phiền nhiễu là khi xem các trang web về bóng đá như bongdaplus.vn hay bongda.com.vn)

Trong khi 3 yếu tố sau (Mobile Friendly, HTTPS, No instrusive interstitials) đã được biết từ trước và có thể đáp ứng được khá dễ dàng, thì Core Web Vitals là một dự án mới của Google (từ 2021), nó trở thành tiêu chí mà các trang web phải cố gắng đáp ứng càng sớm càng tốt để tránh bị rớt thứ hạng trong kết quả tìm kiếm Google.

Trong topic này ta sẽ tìm hiểu chủ mọi thứ về Core Web Vitals và các yếu tố để Website đáp ứng nó và phương thức để Website WordPress nói riêng – đạt được kết quả tốt nhất trong các bài test Core Web Vitals.

Vậy:

A. Core Web Vitals là gì?

Core Web Vitals (CWV) là một dự án mới của Google, được tạo ra để đo lường các chỉ số quan trọng về trang web (core web vitals) và hướng dẫn cải thiện trải nghiệm người dùng trên trang web (UX – User Experience).

Core Web Vitals bao gồm các chỉ số lấy từ bài kiểm tra tốc độ trang web nhưng thay vì chỉ xem xét về tốc độ load trang như các bài kiểm tra tốc độ thông thường, Core Web Vitals sẽ đánh giá các chỉ số tốc độ có liên quan trực tiếp đến việc nâng cao trải nghiệm người dùng trên trang web.

Core Web Vitals là một dự án quan trọng và được đánh giá cao của Google, bởi vì, thực tế, việc cải thiện tốc độ load của trang web là để mang đến trải nghiệm cao cấp cho người dùng.

Vậy Core Web Vitals bao gồm các yếu tố/ chỉ số đo lường tốc độ nào?

B. Các chỉ số quan trọng trong Core Web Vitals

Core Web Vitals là các chỉ số để đo lường 3 yếu tố sau:

1. Hiệu suất tải trang (Loading Performance): được đo bằng chỉ số gọi là Largest Contenful Paint (LCP)
2. Độ ổn định của hình ảnh trang web (Visual Stability): được đo bằng chỉ số Cumulative Layout Shift (CLS)
3. Khả năng tương tác (Interactivity): được đo bằng chỉ số First Input Delay (FID)

Các chỉ số LCP và FID được tính bằng giây (sec), bạn có thể thấy mức độ đáp ứng như hình bên dưới: tốt, cần cải thiện hoặc quá tệ. Đối với LCP mức tốt là dưới 2.5 giây, FID nên là dưới 100 mili giây. Trong khi đó CLS đo theo thang điểm ngược, mức tốt là dưới 0.1 điểm.

Như vậy 3 chỉ số đo lường tốc độ trong Core Web Vitals là LCP, CLS và FID, đây là 3 chỉ số liên quan trực tiếp đến trải nghiệm người dùng là Loading Performance, Visual Stability và Interactivity.

Ta sẽ tìm hiểu kỹ từng cái:

B.1 – Largest Contenful Paint (LCP)

Largest Contenful Paint (LCP – tạm dịch là ) là chỉ số đo thời gian load của Nội dung có kích cỡ lớn nhất (The Largest Content Element) trên trang web.

The Largest Content Element ngầm hiểu là phần nội dung chính của trang (main content) thường nằm ở khu vực đầu trang, như là Featured Image (ảnh nổi bật) hoặc Hero Header/ Section hoặc đôi khi chỉ là đoạn văn bản nổi bật (ví dụ Slogan…)…

The Largest Content Element ở cùng một trang web có thể khác nhau trên giao diện desktop và mobile, ví dụ trường hợp trên desktop được thiết kết có featured image, trong khi trên mobile trang web chỉ hiển thị phần text (như slogan).

Vì sao Largest Contentful Paint – LCP lại quan trọng đến trải nghiệm người dùng?

Điều này cũng dễ hiểu, nếu bạn vào một trang web từ danh sách kết quả tìm kiếm của Google mà phần nội dung chính – có kích thước lớn nhất của trang web mãi không load (hoặc load chậm) thì nhiều khả năng bạn sẽ mất kiên nhẫn thoát ra để vào trang web khác.

Như đã nói, chỉ số LCP đo bằng giây, theo 3 mức độ Tốt – Cần cải thiện và Tệ, LCP – thời gian load của Nội dung có kích cỡ lớn nhất nên từ 2.5 giây trở xuống:

Phân biệt với First Contenful Paint (FCP)

Trong phép đo tốc độ của Google PageSpeed Insights – có một chỉ số khác gọi là First Contentful Paint (FCP) – để đo thời gian load của phần Nội dung đầu tiên ở mỗi trang web (First Content Element).

First Content Element là cái đầu tiên hiển thị khi load trang – việc hiển thị nội dung báo hiệu cho người dùng trang web có thể load, đôi khi có thể là Largest Content Element, nhưng thường là không phải.

Ví dụ thường gặp là bạn tìm kiếm trên mobile về Larry Page (đồng sáng lập Google), thì First Contentful Paint và Largest Contentful Paint là thời gian load các phần tử tương ứng như hình dưới:

Chỉ số First Contentful Paint có xuất hiện trong kết quả bài test tốc độ nhưng không phải là chỉ số Core Web Vitals xem xét đến vì nó không phải chỉ số ảnh hưởng đến Page Experience như Largest Contentful Paint.

B.2 – First Input Delay (FID)

First Input Delay (FID) – hay Độ trễ đầu vào đầu tiên – là chỉ số đo thời gian kể từ lúc người dùng bắt đầu tương tác với phần nào đó của trang web đến khi trình duyệt có thể xử lý để phản hồi tương tác đó.

Ví dụ bạn vào một trang web trên mobile, bạn nhấp vào icon menu trên cùng để mở menu, 3 giây sau menu mới đổ xuống để bạn chọn – First Input Delay (FID) là 3 giây.

Độ trễ đầu vào đầu tiên có lẽ là số liệu phức tạp nhất để hiểu và tối ưu hóa, vì nó bị ảnh hưởng nhiều bởi code JavaScript của website.

Giả sử bạn truy cập vào một trang web từ thiết bị di động và nhấp vào một liên kết, nhưng bạn không nhận được phản hồi ngay lập tức. Có thể là do điện thoại của bạn đang bận xử lý một tệp JavaScript lớn từ trang web đó.

Đây là cách Google xác định điểm FID:

• Tốt  – Nhỏ hơn hoặc bằng 100 ms
• Cần cải thiện  – Nhỏ hơn hoặc bằng 300 ms
• Kém  – Hơn 300 ms.

Một lưu ý nhỏ là First Input Delay (FID) không phải lúc nào cũng xuất hiện trên kết quả test tốc độ (ta sẽ hiểu vì sao ở phần C). Khi đó, một chỉ số khác có thể đại diện cho FID là Total Blocking Time (TBT – là tổng thời gian chặn – do các đoạn mã Javascript gây ra khi load trang).

B.3 – Cumulative Layout Shift (CLS)

Cumulative Layout Shift – CLS (Thay đổi bố cục tích lũy) là chỉ số đo lường sự ổn định của bố cục trang web khi nó được load, tức là bố cục trang web có thay đổi bất ngờ trong quá trình load không.

Ví dụ về CLS như sau:

• Bạn vào một trang web, trong quá trình load trang, lúc đầu nút Contact Us hiển thị ở bên phải của phần Hero Header, khi bạn định nhấp vào thì nó lại nhảy qua bên trái vì ở bên phải bắt đầu load các đoạn văn bản.
• Lúc đầu menu ở đầu trang là dạng full (hiển thị đầy đủ), khi trang web load xong thì nó lại thành dạng hamburger (dạng menu rút gọn).
• Bạn vào một trang web lúc đầu phần nội dung được hiển thị bình thường, bạn vừa đọc vài đoạn thì các mục quảng cáo nổi lên khiến các đoạn nội dung nhảy chỗ khác không thể đọc tiếp.

Đó là một vài ví dụ về việc Thay đổi bố cục tích lũy khi load trang Cumulative Layout Shift – CLS – một yếu tố tác động xấu đến trải nghiệm người dùng – nó là chỉ số thứ 3 mà Core Web Vitals yêu cầu chúng ta phải xử lý trong quá trình tối ưu trang web nhằm nâng cao trải nghiệm người dùng.

Điểm CLS được tính bằng tỉ lệ giữa phần tác động (impact fraction) (diện tích bị chiếm dụng khi dịch chuyển) và phần khoản cách (distance fraction). Chúng ta chỉ cần biết CLS càng thấp càng tốt và điểm cần đạt là dưới 0.1 điểm:

 

C. Các chỉ số Core Web Vitals trên công cụ Test tốc độ

Có hàng chục công cụ test tốc độ website miễn phí hiện nay, phổ biến như Googe PageSpeed Insight, Gmetrix, Pingdom hay Chrome DevTools … ta sẽ xem chúng hiển thị các chỉ số đo lường Core Web Vitals thế nào.

Hầu hết các công cụ test đều cung cấp các chỉ số Core Web Vitals, trong một số trường hợp thì chỉ số First Input Delay (FID) sẽ thay thế bằng Total Blocking Time (TBT):

Chúng ta có thể sử dụng tùy ý các công cụ test ở trên khi kiểm tra các chỉ số Core Web Vitals, tuy nhiên vì Core Web Vitals là một dự án chính chủ của Google, do đó hầu hết các công cụ đều lấy các kết quả đo lường hiệu suất trang web (Page Performance Metrics) có được từ Google Lighthouse (dự án mã nguồn mở của Google chuyên đo lường hiệu suất, chất lượng trang web)

Ở đây, công cụ test tốc độ khuyên dùng và uy tín nhất dĩ nhiên là Google PageSpeed Insights, vì không chỉ cho các kết quả gốc từ Google Lighthouse mà PageSpeed Insights còn kèm theo dữ liệu rất chi tiết – chỉ chính xác thành phần liên quan đến chỉ số cần cải thiện, trong phần Diagnostics ngay dưới phần điểm số chung:

Trong topic này ta sẽ xem chi tiết về các chỉ số trên công cụ Google PageSpeed Insight và cũng tìm hiểu về báo cáo tổng hợp Core Web Vitals của Website trên công cụ Google Search Console.

C.1 – Phân tích chỉ số Core Web Vitals trên Google PageSpeed Insights

Công cụ Google PageSpeed Insights cho kết quả đo hiệu suất trang web lấy trực tiếp từ Google Lighthouse, bên cạnh điểm số tổng thể trên desktop và mobile còn có thông tin chi tiết về rất nhiều chỉ số tốc độ.

Ở đây ta chỉ quan tâm đến các chỉ số thuộc Core Web Vitals và tìm hiểu yếu tố nào trên trang web ảnh hưởng trực tiếp đến các chỉ số đó để cải thiện nếu chưa đạt.

Nhưng trước hết, bạn cần biết về cách hiển thị kết quả test của Google PageSpeed Insights, xem hình bên dưới, có đến 2 phần hiển thị các chỉ số Core Web Vitals, là dữ liệu từ Field Data và Lab Data:

Có sự khác nhau trong cách thu thập dữ liệu ở mục Field Data và Lab Data:

• Field Data (data from your actual users around the world – dữ liệu từ người dùng thực): là dữ liệu phân tích & tổng hợp từ người dùng thực, được Google thực hiện qua dự án Chrome User Experience (CrUX), đây là dữ liệu không xuất hiện ngay khi tạo Website mà cần thời gian vài tuần để có đủ dữ liệu từ người dùng thực, trên hình bạn có thể thấy dữ liệu được tổng hợp trong 28 ngày gần nhất.
• Lab Data (simulated environment – môi trường mô phỏng): là dữ liệu Google lấy từ các công dụ test của dự án Google Lighthouse, dữ liệu này có ngay khi test một trang web.

Trong các chỉ số Core Web Vitals, thì Lab Data không có First Input Delay (FID) vì cái này là dữ liệu của người dùng thực, không thể có từ công cụ test, ở đây, chỉ số Total Blocking Time có thể đại diện cho FID.

Hiện nay Google PageSpeed Insights không hiển thị tiêu đề Field Data, Lab Data cho 2 khu vực điểm số nữa, mà 2 tiêu đề tương ứng đổi thành Discover what your real users are experiencing và Diagnose performance issues, như hình đầy đủ – khi thử test trang web Kinsta:

Điểm số của các chỉ số ở Field Data và Lab Data thường khác nhau, vì một cái tổng hợp dữ liệu từ người dùng thực trong một thời gian nhất định, cái còn lại là dữ liệu từ công cụ test tốc độ của Google Lighthouse ngay thời điểm test:

• Điểm số Core Web Vitals liên quan đến trải nghiệm người dùng, tất nhiên nó thể hiện ở Field Data, nhưng nếu các chỉ số ở Field Data không đạt, sau khi chuẩn đoán và khắc phục, ta kiểm tra lại phải dựa vào điểm số ở Lab Data, nguyên nhân vì điểm số Field Data cần thời gian 2 -> 4 tuần tổng hợp, còn điểm Lab Data ta có thể có ngay khi test trang.
  
• Điểm số Core Web Vitals trên thiết bị Desktop và Mobile tất nhiên cũng khác nhau, chúng ta cần kiểm tra cả 2 để tối ưu riêng từng cái.
• Trên thiết bị Desktop, trang web thường dễ đạt điểm cao cho các chỉ số Core Web Vitals, trên Mobile thì khó hơn, nguyên nhân thường do việc render code HTML và xử lý Javascript trên Mobile thường nặng nề hơn trên Desktop.
  

C.2 – Kết quả báo cáo Core Web Vitals trên Google Search Console

Với các công cụ test tốc độ như Google PageSpeed Insights, ta chỉ có thể kiểm tra điểm Core Web Vitals bằng cách nhập URL của từng trang web.

Nếu muốn có dữ liệu tổng hợp về Core Web Vitals của toàn bộ các trang trên Website để thực hiện tối ưu toàn diện, cần phải truy cập Google Search Console của Website để lấy dữ liệu đầy đủ.

Trên Google Search Console từ 2021 xuất hiện thêm phần Core Web Vitals để báo cáo tổng quan điểm số về các chỉ số thuộc Core Web Vitals, trên cả thiết bị desktop và mobile, đây là các dữ liệu thuộc Field Data, tổng hợp từ người dùng thực (qua dự án CrUX) nên mọi sự thay đổi sẽ không được cập nhật ngay mà thường sẽ diễn ra trong vòng 14 đến 28 ngày.

Để xem đầy đủ báo cáo ở mỗi phần Desktop hay Mobile, ta nhấp vào Open Report (Mở Báo cáo) như ở hình trên, sau đó chọn mục cần xem chi tiết danh sách trang, ví dụ như hình dưới là mục Need Improvement (Cần cải thiện), rồi click vào chỉ số cần xem chi tiết:

Danh sách các trang cần tối ưu (ví dụ chỉ số LCP lớn hơn 2.5s như hình minh họa), ở đây chỉ hiển thị một số trang điển hình, muốn xem đầy đủ bạn nhấp vào số trang tương tự ở cột Similiar URLs:

Danh sách các trang có điểm số tương tự (ví dụ LCP 3.0 giây như hình) sẽ hiển thị ở sidebar:

Sau khi bạn fix các trang trang, bạn có thể test ngay từng trang đã fix và xem dữ liệu Lab Data trên Google PageSpeed Insights, nếu thấy điểm số đã đạt, bạn có thể báo cáo với Google trang đã được cải thiện để Google cập nhật dữ liệu báo cáo mới nhất nhanh hơn (nhưng cũng phải vài ngày đến vài tuần):

 

D. Tìm nguyên nhân và xử lý lỗi để cải thiện Core Web Vitals

Sau khi đã hiểu hết về dữ liệu Core Web Vitals, phần cuối cùng này chính là lúc ta tìm hiểu làm thế nào để tìm ra nguyên nhân điểm số các chỉ số không đạt yêu cầu, cách xử lý để nâng cao điểm số nhằm vượt qua các tiêu chuẩn (Passed Core Web Vitals).

Ở đây, ta cần phải quay lại với công cụ Google PageSpeed Insights và xem xét yếu tố tác động đến 3 chỉ số LCP (Largest Contentful Paint), FID (First Input Delay)/ TBT (Total Blocking Time) và CLS (Cumulative Layout Shift). Cụ thể:

• Largest Contentful Paint (LCP): ta phải xác định phần tử LCP, tức phần nội dung kích cỡ lớn nhất của trang web (Largest Content Element), qua đó xem xét tối ưu thời gian load của nó để điểm LCP nằm ở mức dưới 2.5 giây.
• First Input Delay (FID)/ Total Blocking Time (TBT): ta phải tìm ra nguyên nhân ảnh hưởng đến Total Blocking Time (tổng thời gian chặn), qua đó có thể tối ưu để nó ở mức dưới 100 mili giây.
• Cumulative Layout Shift (CLS): ta cần xác định chính xác yếu tố dịch chuyển bố cục tích lũy và tìm cách tối ưu để điểm số CLS dưới 0.1 như yêu cầu của Core Web Vitals.

Chi tiết và các thành phần, yếu tố liên quan đến các chỉ số trên nằm ở mục Diagnostics của trang kết quả test Google PageSpeed Insights:

D.1 – Xác định phần tử Largest Contentful Paint và cải thiện LCP

Phần tử Nội dung có kích cỡ lớn nhất, mà thời gian load của nó chính là chỉ số Largest Contentful Paint rất dễ xác định. Chính xác thì ta xem ở tab Largest Contentful Paint element ở phần Diagnostics:

Cũng nên nhắc lại, LCP element trên Mobile có thể khác với Desktop, ví dụ ở trên LCP element là image trên Desktop, nhưng ở giao diện Mobile thì nó là heading text (h1):

Vì vậy, bạn cần xác định cải thiện LCP ở giao diện desktop hay mobile để xác định rõ phần tử LCP tương ứng và tối ưu chính xác.

Hướng dẫn cải thiện LCP

Trong 3 chỉ số của Core Web Vitals thì Largest Contentful Paint (LCP) là dễ nhất, tối ưu LCP không chỉ là tác động tới phần tử LCP mà còn liên quan đến tối ưu tốc độ tải trang chung, do đó việc này đi liền với các kỹ thuật tối ưu tốc độ WordPress quen thuộc mà hầu hết các plugin tăng tốc đều hỗ trợ (SwiftPerformance, LiteSpeed Cache hay plugin tốt nhất: WP-Rocket)

1. Thiết lập bộ nhớ đệm trang (Caching): Bộ nhớ đệm trang tăng tốc và giảm thời gian phản hồi của máy chủ (TTFB), nhờ đó tăng tốc tải phần tử LCP nói riêng và cả trang web nói chung.
2. Tối ưu hóa bộ nhớ đệm của trình duyệt (Browser Cache):  tùy chọn cho các file tĩnh (HTML, CSS, Images) lưu trong bộ nhớ cache của trình duyệt. Bằng cách đó, sẽ giải quyết được đề xuất ” Phân phối nội dung tĩnh với chính sách bộ nhớ đệm hiệu quả ” PageSpeed ​​Insights.
3. Tối ưu ảnh trên trang web: phần tử LCP trên trang thường là một hình ảnh, nên tối ưu ảnh (nén ảnh và dùng định dạng thế hệ mới WebP) sẽ cải thiện được LCP.
4. Tối ưu code trang web: nén (minify) CSS, JS và tải chậm (defer JS, remove unused CSS) sẽ giúp cải thiện thời gian load trang, nhất là ưu tiên load phần tử LCP trước khi xử lý các đoạn mã CSS, JS chưa cần thiết.
   
5. Sử dụng tính năng nén Gzip hoặc Brotli từ máy chủ (Hosting/ VPS): nén file trước khi gởi tới trình duyệt tất nhiên sẽ tối ưu thời gian tải trang.
6. Sử dụng tính năng Preconnect: để kết nối trước với các tài nguyên quan trọng trên trang web nhằm tối ưu thời gian tải trang.
   
7. Sử dụng mạng phân phối nội dung (CDN) : nếu Website phục vụ người dùng nhiều khu vực trên thế giới thì bạn cần dùng dịch vụ CDN để tối ưu thời gian load trang cho các khu vực ở xa máy chủ.
   

Đối với Website WordPress, cách dễ nhất để thực hiện hầu hết các phương pháp trên là sử dụng plugin tăng tốc số 1 thế giới WP Rocket.

WP Rocket sẽ tự động áp dụng bộ nhớ đệm trang (page caching) và nén cấp máy chủ (gzip) ngay sau khi kích hoạt và rất nhiều tính năng khác để  tối ưu code và hiệu suất tải của trang web, tất cả đều cải thiện thời gian LCP.

Ngoài WP-Rocket, bạn cũng có thể dùng các plugin tăng tốc All in One khác như LiteSpeed Cache, SwiftPerformance hay W3 Total Cache, WP Fastest Cache, có thể kết hợp thêm những plugin phụ như WP-Optimize, Perfmatters… đều có thể cải thiện tốc độ load trang nói chung và điểm số LCP nói riêng.

Tham khảo topic:

Hướng dẫn Tăng tốc WordPress với WP-Rocket

D.2 – Tìm nguyên nhân tác động First Input Delay/ Total Blocking Time và cải thiện FID/ TBT

Như đã nói – Độ trễ đầu vào (First Input Delay FID) được tính bằng dữ liệu từ người dùng thực, nên không có cách nào để ‘đo’ được FID ngay khi test tốc độ, mà chỉ có thể đối chiếu bằng Total Blocking Time – TBT, tức tổng thời gian chặn.

Nguyên nhân của Độ trễ đầu vào FID là do mã Javascript của trang web trong quá trình thực thi khi load trang sẽ chặn phản hồi của trình duyệt trong một khoản thời gian nhất định gọi là Total Blocking Time. Ta xem Total Blocking Time ở phần Lab Data:

Hướng dẫn cải thiện FID

Nếu Total Blocking Time trên 100 ms thì đối chiếu tương ứng có thể FID cần phải cải thiện, trong phần Diagnostics của Google PageSpeed Insights hiển thị nhiều thông tin về code Javascript trực tiếp ảnh hưởng đến Total Blocking Time, cụ thể thường là các khuyến cáo (recommendations) để tối ưu quá trình thực thi JS, hạn chế thấp nhất thời gian chặn TBT như Reduce Javascript Execution Time, Remove Unused Javascripts, Minimize Main Thread Work…

Ta có thể giải quyết các khuyến cáo trên bằng các kỹ thuật tối ưu code Javascript trên các plugin tăng tốc như SwiftPerformance, WP-Rocket, các tùy chọn này sẽ giúp giảm thời gian chặn của code Javascript:

• Minify Javavscript (nén code JS)
• Defer Javascript (Load Javascript Deferred) : thực thi chậm JS, sau khi đã hiển thị các phần nội dung quan trọng
• Removed Unused Javscript & Delay Javascript Execution: loại bỏ & hoãn thực thi các chương trình JS không cần thiết cho việc hiển thị nội dung trang web.

Ngoài ra các kỹ thuật tăng tốc khác như nén Gzip/ Brotli, Caching, dùng CDN, tối ưu ảnh,… cũng tác động ít nhiều đến Total Blocking Time.

Các kỹ thuật trên cũng được hỗ trợ bởi plugin WP-Rocket!

D.3 – Tìm yếu tố gây ra Cumulative Layout Shift và cải thiện CLS

Yếu tố gây ra Thay đổi bố cục tích lũy của trang web (CLS) và điểm số từng thành phần có thể xác định ở phần Diaglostics:

Hướng dẫn cải thiện CLS

Việc hạn chế quá trình Thay đổi bố cục tích lũy khi load trang để CLS dưới 0.1 điểm thường phụ thuộc một phần vào thiết kế của trang web (do theme, page builder), nhưng cũng có thể cải thiện nhiều bằng cách kiểm tra và xử lý các nguyên nhân phổ biến khiến CLS không đạt chuẩn.

Một số sự cố phổ biến nhất và cách khắc phục là:

1. Sửa hình ảnh không có kích thước – nếu thêm hình ảnh thông qua trình soạn thảo WordPress (Editor), WordPress sẽ tự động thêm kích thước cho ảnh, nhưng nếu hình ảnh có trên code (theme, plugin) hoặc nhúng từ nguồn ngoài thì chúng ta cần tự thêm kích thước. Vì hình ảnh không định rõ kích thước sẽ khiến bố cục trang web thay đổi mạnh khi load ảnh đó. Việc tự động thêm kích thước cho ảnh (nếu chưa có) được các plugin tăng tốc như WP-Rocket, Perfmatters hỗ trợ rất tốt.
2. Chỉnh sửa quảng cáo, nội dung nhúng (embeds) và iframe không có kích thước – cũng giống như với hình ảnh, ads, embeds hay iframe không có kích thước cũng có thể gây ra sự cố về bố cục khi load. Đảm bảo luôn chỉ định kích thước cho các thành phần này.
3. Tối ưu hóa font: font chữ tải chậm có thể gây ra các vấn đề như Flash of Invisible Text (FOIT) hoặc Flash of Unstyled Text (FOUT) (tức chữ không hiển thị hoặc hiển thị không đúng định dạng font). Vấn đề này sẽ phát sinh khuyến cáo về tốc độ của Google : “Đảm bảo văn bản vẫn hiển thị trong khi tải webfont”. Để xử lý lỗi này có thể dùng tính năng font preloading trên các plugin tăng tốc để tải trước font chữ.
4. Cẩn trọng khi chèn nội dung động (dynamic content) vào trang: nếu bạn quyết định chèn nội dung vào trang web (ví dụ dùng plugin để chèn quảng cáo tự động vào nội dung bài viết) thì phải đảm bảo thực hiện hợp lý, vì nội dung động được chèn vào cùng lúc quá trình load trang sẽ khiến bố cục thay đổi đột ngột, không chỉ mất điểm Core Web Vitals mà người đọc thực sự cũng rất khó chịu với tình trạng này.

D.4 – Cải thiện Core Web Vitals bằng các kỹ thuật tăng tốc phổ biến

Ngoài việc dùng các kỹ thuật cải thiện riêng cho 3 chỉ số LCP, FID, CLS thì các phương pháp tối ưu tốc độ phổ biến cho WordPress cũng có tác động tích cực tới điểm số Core Web Vitals:

1. Hosting & CDN: Chọn dịch vụ Hosting chất lượng cao, gần người dùng và kết hợp dịch vụ CDN chất lượng nếu Website phục vụ cho người dùng ở xa nơi đặt máy chủ (Hosting)
   
2. Tối ưu ảnh toàn diện: nén ảnh bằng cách plugin chuyên dụng như ShortPixel, SmushIT, Imagify.., sử dụng định dạng ảnh thế hệ mới WebP, tự động thêm size cho ảnh chưa chỉ định size.
   
3. Sử dụng theme và plugin tối ưu: sử dụng theme nhẹ, không sử dụng quá nhiều plugin nếu không quá cần thiết, sử dụng plugin Perfmatters để tối ưu quá trình thực thi của các plugins nhằm ngăn chặn các plugin khởi chạy trên các trang không cần chúng.
   
4. Sử dụng Page Builder hợp lý: các trang web tạo bằng Page Builder như Elementor, Divi, Brizy … nếu không có nhiều kinh nghiệm thì kết quả thường là các trang có pagesize lớn, quá trình load phải thực thi nhiều code JS, làm các chỉ số Core Web Vitals sẽ bị ảnh hưởng nhiều.

Ngoài các phương pháp tối ưu tốc độ ở trên, thì các kỹ thuật cải thiện điểm số Core Web Vitals nói riêng và điểm Speed Test nói chung còn phụ thuộc vào từng dự án Website WordPress, với theme và plugin cụ thể trên Website đó.

Ở mỗi dự án Website ta có thể cần phải xử lý thêm một số vấn đề đặc thù do theme và plugin gây ra, ngoài plugin tăng tốc WP-Rocket, có thể ta phải dùng thêm plugin Perfmatters nữa mới đạt được kết quả cao nhất!

Việc thực hành chi tiết tối ưu Core Web Vitals trên Website WordPress cụ thể sẽ được trình bày trong Case Study 2022 – Thiết kế Website WordPress trên Gutenberg 2022!

Hẹn gặp lại ở các topic tiếp theo!