Cách đo lường và tối ưu hoá cơ chế trao đổi có chữ ký để cải thiện tối đa cơ chế trao đổi có chữ ký
Cơ chế trao đổi có chữ ký (SXG) là một phương thức giúp cải thiện tốc độ trang, chủ yếu là Nội dung lớn nhất hiển thị (LCP). Khi tham chiếu các trang web (hiện là Google Tìm kiếm) liên kết đến một trang, chúng có thể tìm nạp trước liên kết đó vào bộ nhớ đệm của trình duyệt trước khi người dùng nhấp vào liên kết.
Bạn có thể làm cho các trang web mà khi được tìm nạp trước sẽ không yêu cầu mạng trên đường dẫn quan trọng để hiển thị trang! Trên kết nối 4G, quá trình tải trang này mất từ 2,8 giây đến 0,9 giây (0,9 giây còn lại chủ yếu là theo mức sử dụng CPU):
Hầu hết những người phát hành SXG hiện nay đều sử dụng tính năng Tự động trao đổi có chữ ký (ASX) dễ sử dụng của Cloudflare (mặc dù có các tuỳ chọn nguồn mở):
Trong nhiều trường hợp, việc chọn hộp bật tính năng này là đủ để nhận được loại cải thiện đáng kể nêu trên. Đôi khi, có thêm một vài bước để đảm bảo các SXG này hoạt động như dự kiến ở mỗi giai đoạn của quy trình và tối ưu hoá các trang để khai thác tối đa chức năng tìm nạp trước.
Trong vài tháng qua kể từ khi Cloudflare ra mắt, tôi đã đọc và trả lời câu hỏi trên nhiều diễn đàn, đồng thời tìm hiểu cách tư vấn cho các trang web về cách đảm bảo rằng họ khai thác tối đa việc triển khai SXG. Bài đăng này là tuyển tập lời khuyên của tôi. Tôi sẽ hướng dẫn bạn các bước để:
- Phân tích hiệu suất của SXG bằng WebPageTest.
- Gỡ lỗi quy trình SXG nếu bước Phân tích cho thấy quy trình này không hoạt động.
- Tối ưu hoá các trang để tìm nạp trước SXG, bao gồm cả việc đặt
max-agetối ưu và tải trước các tài nguyên phụ chặn hiển thị. - Đo lường mức độ cải thiện SXG thông qua Google Analytics bằng cách chọn các nhóm thử nghiệm và nhóm đối chứng thích hợp.
Giới thiệu
SXG là một tệp chứa URL, một nhóm tiêu đề phản hồi HTTP và nội dung phản hồi – tất cả đều được ký mã hoá bằng một chứng chỉ PKI trên web. Khi tải một SXG, trình duyệt sẽ xác minh tất cả những yếu tố sau:
- SXG chưa hết hạn.
- Chữ ký này khớp với URL, tiêu đề, nội dung và chứng chỉ.
- Chứng chỉ hợp lệ và khớp với URL.
Nếu quá trình xác minh không thành công, trình duyệt sẽ bỏ qua SXG và thay vào đó sẽ tìm nạp URL đã ký. Nếu xác minh thành công thì trình duyệt sẽ tải phản hồi đã ký, coi như phản hồi đó đến trực tiếp từ URL đã ký. Cơ chế này cho phép lưu trữ lại SXG trên bất kỳ máy chủ nào, miễn là SXG chưa hết hạn hoặc bị sửa đổi kể từ khi được ký.
Đối với Google Tìm kiếm, SXG cho phép tìm nạp trước các trang trong kết quả tìm kiếm. Đối với các trang hỗ trợ SXG, Google Tìm kiếm có thể tìm nạp trước bản sao của trang được lưu trong bộ nhớ đệm, được lưu trữ trên webpkgcache.com. Các URL webpkgcache.com này không ảnh hưởng đến việc hiển thị hoặc hoạt động của trang vì trình duyệt tuân theo URL gốc, đã được ký. Tìm nạp trước có thể cho phép trang của bạn tải nhanh hơn nhiều.
Phân tích
Để thấy được lợi ích của SXG, hãy bắt đầu bằng cách dùng một công cụ trong phòng thí nghiệm để phân tích hiệu suất của SXG trong các điều kiện lặp lại. Bạn có thể sử dụng WebPageTest để so sánh thác nước (và LCP) khi có và không có tính năng tìm nạp trước SXG.
Tạo một kiểm thử mà không cần SXG như sau:
- Chuyển đến WebPageTest rồi đăng nhập. Việc đăng nhập sẽ lưu nhật ký kiểm tra của bạn để dễ dàng so sánh sau này.
- Nhập URL mà bạn muốn kiểm tra.
- Chuyển đến phần Cấu hình nâng cao. (Bạn sẽ cần có Cấu hình nâng cao để kiểm thử SXG. Vì vậy, việc sử dụng cấu hình này tại đây sẽ giúp đảm bảo các lựa chọn kiểm thử là giống nhau.)
- Trong thẻ Test Settings (Cài đặt kiểm thử), bạn nên đặt kết nối thành 4G và tăng "Số lượt kiểm thử cần chạy" đến 7.
- Nhấp vào Bắt đầu kiểm tra.
Tạo một bản kiểm thử bằng SXG bằng cách làm theo các bước trên. Tuy nhiên, trước khi nhấp vào Start Test, hãy chuyển đến thẻ Script (Tập lệnh), dán vào tập lệnh WebPageTest sau đây rồi sửa đổi 2 URL navigate theo hướng dẫn:
// Disable log collection for the first step. We only want the waterfall for the target navigation.
logData 0
// Visit a search result page that includes your page.
navigate https://google.com/search?q=site%3Asigned-exchange-testing.dev+image
// Wait for the prefetch to succeed.
sleep 10
// Re-enable log collection.
logData 1
// Navigate to the prefetched SXG on the Google SXG Cache.
navigate https://signed--exchange--testing-dev.webpkgcache.com/doc/-/s/signed-exchange-testing.dev/sxgs/valid-image-subresource.html
Đối với URL navigate đầu tiên, nếu trang của bạn chưa xuất hiện trong kết quả nào trên Google Tìm kiếm thì bạn có thể sử dụng trang tìm nạp trước này để tạo một trang kết quả tìm kiếm giả cho mục đích này.
Để xác định URL navigate thứ hai, hãy truy cập vào trang của bạn bằng tiện ích Trình xác thực SXG của Chrome, rồi nhấp vào biểu tượng tiện ích để xem URL bộ nhớ đệm:
Sau khi các bài kiểm thử này hoàn tất, hãy chuyển đến phần Nhật ký kiểm thử, chọn hai bài kiểm thử rồi nhấp vào So sánh:
Thêm &medianMetric=LCP vào URL so sánh để WebPageTest chọn chạy với LCP trung bình cho mỗi bên của phép so sánh. (Giá trị mặc định là trung vị theo Chỉ số tốc độ.)
Để so sánh các thác nước, hãy mở rộng phần Độ mờ của thác nước rồi kéo thanh trượt. Để xem video, hãy nhấp vào Điều chỉnh chế độ cài đặt Cuộn phim, di chuyển xuống bên trong hộp thoại đó rồi nhấp vào Xem video.
Nếu quá trình tìm nạp trước SXG thành công, bạn sẽ thấy lượt "có SXG" thác nước không bao gồm một hàng cho HTML và quá trình tìm nạp cho các tài nguyên phụ sẽ bắt đầu sớm hơn. Ví dụ: so sánh "Trước" và "Sau" tại đây:
Gỡ lỗi
Nếu WebPageTest cho thấy SXG đang được tìm nạp trước, thì tức là công cụ này đã thành công ở tất cả các bước của quy trình; bạn có thể bỏ qua phần Tối ưu hoá để tìm hiểu cách cải thiện thêm LCP. Nếu không, bạn sẽ cần tìm hiểu xem lỗi ở đâu trong quy trình và tại sao; hãy đọc tiếp để tìm hiểu cách thực hiện.
Xuất bản
Đảm bảo các trang của bạn đang được tạo dưới dạng SXG. Để thực hiện việc này, bạn cần phải giả mạo trình thu thập dữ liệu. Cách dễ nhất là sử dụng tiện ích Trình xác thực SXG của Chrome:
Tiện ích này sẽ tìm nạp URL hiện tại bằng tiêu đề yêu cầu Accept cho biết tiện ích này ưu tiên phiên bản SXG. Nếu bạn thấy dấu kiểm (✅) bên cạnh nguồn gốc, tức là ứng dụng đã trả về một SXG; bạn có thể chuyển đến phần Lập chỉ mục.
Nếu bạn thấy dấu chéo (❌), điều đó có nghĩa là SXG không được trả về:
Nếu Cloudflare ASX được bật, thì lý do có thể nhất dẫn đến dấu chéo (❌) là do tiêu đề phản hồi kiểm soát bộ nhớ đệm ngăn chặn điều này. ASX xem xét các tiêu đề có tên sau:
Cache-ControlCDN-Cache-ControlSurrogate-ControlCloudflare-CDN-Cache-Control
Nếu bất kỳ tiêu đề nào trong số này chứa các giá trị tiêu đề sau đây, thì tiêu đề đó sẽ ngăn việc tạo SXG:
privateno-storeno-cachemax-agenhỏ hơn 120, trừ phi bịs-maxageghi đè lớn hơn hoặc bằng 120
ASX không tạo SXG trong những trường hợp này vì SXG có thể được lưu vào bộ nhớ đệm và sử dụng lại cho nhiều lượt truy cập và nhiều khách truy cập.
Một lý do khác có thể gây ra dấu chéo (❌) là sự hiện diện của một trong các tiêu đề phản hồi có trạng thái này, ngoại trừ Set-Cookie. ASX xoá tiêu đề Set-Cookie để tuân thủ thông số kỹ thuật của SXG.
Một lý do khác có thể là sự có mặt của tiêu đề phản hồi Vary: Cookie. Googlebot tìm nạp các SXG mà không cần thông tin xác thực của người dùng và có thể phân phát các phiên bản này cho nhiều khách truy cập. Nếu bạn phân phát HTML khác nhau cho những người dùng khác nhau dựa trên cookie của họ, thì họ có thể thấy trải nghiệm không chính xác, chẳng hạn như chế độ xem đã đăng xuất.
Ngoài tiện ích của Chrome, bạn có thể dùng một công cụ như curl:
curl -siH "Accept: application/signed-exchange;v=b3" $URL | less
hoặc dump-signedexchange:
dump-signedexchange -verify -uri $URL
Nếu SXG được cung cấp và hợp lệ, bạn sẽ thấy một bản in mà con người có thể đọc được của SXG. Nếu không, bạn sẽ thấy một thông báo lỗi.
Lập chỉ mục
Đảm bảo rằng Google Tìm kiếm đã lập chỉ mục thành công SXG của bạn. Mở Công cụ của Chrome cho nhà phát triển, sau đó tìm kiếm trang của bạn trên Google. Nếu trang đó đã được lập chỉ mục là một SXG, thì đường liên kết của Google tới trang của bạn sẽ bao gồm data-sxg-url trỏ đến bản sao của webpkgcache.com:
Nếu cho rằng người dùng có thể sẽ nhấp vào kết quả đó, Google Tìm kiếm sẽ tìm nạp trước kết quả đó:
Phần tử <link> hướng dẫn trình duyệt tải SXG xuống vào bộ nhớ đệm tìm nạp trước. Khi người dùng nhấp vào phần tử <a>, trình duyệt sẽ sử dụng tiện ích SXG đã lưu vào bộ nhớ đệm để kết xuất trang.
Bạn cũng có thể xem bằng chứng về quá trình tìm nạp trước bằng cách chuyển đến thẻ Mạng trong Công cụ cho nhà phát triển rồi tìm các URL có chứa webpkgcache.
Nếu <a> trỏ đến webpkgcache.com, thì tức là hệ thống lập chỉ mục của Google Tìm kiếm cho giao thức trao đổi có chữ ký này đang hoạt động. Bạn có thể chuyển tới phần Truyền dẫn.
Nếu không, có thể là Google chưa thu thập lại dữ liệu trên trang của bạn kể từ khi bạn bật SXG. Dùng thử Công cụ kiểm tra URL của Google Search Console:
Việc có tiêu đề digest: mi-sha256-03=... cho biết rằng Google đã thu thập dữ liệu thành công phiên bản SXG.
Nếu không có tiêu đề digest, thì đây có thể là dấu hiệu cho thấy SXG không được phân phát cho Googlebot hoặc chỉ mục chưa được cập nhật kể từ khi bạn bật SXG.
Nếu một SXG được thu thập dữ liệu thành công nhưng vẫn không được liên kết với SXG nào đó có thể là do không đáp ứng được các yêu cầu về bộ nhớ đệm của SXG. Những điều này được đề cập trong phần tiếp theo.
Nhập
Khi lập chỉ mục một SXG nào đó, Google Tìm kiếm sẽ gửi bản sao của nó đến bộ nhớ đệm SXG của Google. Bộ nhớ đệm này sẽ xác thực SXG theo các yêu cầu về bộ nhớ đệm. Tiện ích của Chrome hiển thị kết quả:
Nếu thấy dấu kiểm (✅), thì bạn có thể bỏ qua để chuyển đến mục Tối ưu hóa.
Nếu ứng dụng không đáp ứng yêu cầu, bạn sẽ thấy một dấu x (❌) và một thông báo cảnh báo cho biết lý do:
Trong trường hợp này, trang sẽ hoạt động như trước khi bật SXG. Google sẽ liên kết đến trang đó trên máy chủ lưu trữ ban đầu mà không cần tìm nạp trước SXG.
Trong trường hợp bản sao được lưu vào bộ nhớ đệm đã hết hạn và đang được tìm nạp lại trong nền, bạn sẽ thấy biểu tượng đồng hồ cát (⌛):
Tài liệu dành cho nhà phát triển của Google trên SXG cũng có hướng dẫn truy vấn bộ nhớ đệm theo cách thủ công.
Tối ưu hoá
Nếu tiện ích SXG của Chrome hiển thị tất cả dấu kiểm (✅), thì tức là bạn có một SXG có thể phân phát cho người dùng! Hãy đọc tiếp để tìm hiểu cách tối ưu hoá trang web nhằm giúp bạn cải thiện LCP nhất nhờ SXG.
độ tuổi tối đa
Khi SXG hết hạn, bộ nhớ đệm SXG của Google sẽ tìm nạp một bản sao mới ở chế độ nền. Trong khi chờ lần tìm nạp đó, người dùng sẽ được chuyển hướng đến trang trên máy chủ lưu trữ ban đầu. Trang này chưa được tìm nạp trước. Bạn đặt Cache-Control: max-age càng lâu thì quá trình tìm nạp trong nền này càng ít xảy ra và do đó, LCP càng thường xuyên bị giảm bởi quá trình tìm nạp trước.
Đây là sự cân bằng giữa hiệu suất và độ mới. Bộ nhớ đệm cho phép chủ sở hữu trang web cung cấp SXG tối đa ở bất cứ đâu trong khoảng từ 2 phút đến 7 ngày, để phù hợp với nhu cầu cụ thể của từng trang. Chúng tôi nhận thấy rằng:
max-age=86400(1 ngày) trở lên mang lại hiệu suất tốtmax-age=120(2 phút) không
Chúng tôi hy vọng có thể tìm hiểu thêm về các giá trị giữa hai chỉ số này trong quá trình nghiên cứu dữ liệu nhiều hơn.
user-agent
Có lần tôi thấy LCP tăng khi dùng một SXG được tìm nạp trước. Tôi đã chạy công cụ WebPageTest, so sánh kết quả trung vị mà không sử dụng và với tính năng tìm nạp trước SXG. Nhấp vào Sau bên dưới:
Tôi thấy quá trình tìm nạp trước đang hoạt động. HTML bị xoá khỏi đường dẫn quan trọng, do đó, tất cả các tài nguyên phụ đều có thể tải sớm hơn. Tuy nhiên, LCP (đường nét đứt màu xanh lục) tăng từ 2 giây lên 2,1 giây.
Để chẩn đoán vấn đề này, tôi đã xem xét các cuộn phim. Tôi nhận thấy trang hiển thị theo cách khác trong SXG. Trong HTML thuần tuý, Chrome đã xác định rằng "phần tử lớn nhất" đối với LCP là dòng tiêu đề. Tuy nhiên, trong phiên bản SXG, trang này đã thêm một biểu ngữ tải từng phần, đẩy dòng tiêu đề xuống dưới màn hình đầu tiên và khiến thành phần mới lớn nhất trở thành hộp thoại đồng ý sử dụng cookie được tải từng phần. Mọi thứ hiển thị nhanh hơn trước, nhưng thay đổi về bố cục khiến chỉ số báo cáo là chậm hơn.
Tôi đã đào sâu hơn và phát hiện nguyên nhân dẫn đến sự khác biệt về bố cục là do trang thay đổi theo User-Agent và đã xảy ra lỗi trong logic. Chiến dịch này phân phát một trang dành cho máy tính, mặc dù tiêu đề thu thập dữ liệu SXG cho biết thiết bị di động. Sau khi vấn đề này được khắc phục, trình duyệt đã xác định chính xác dòng tiêu đề của trang là phần tử lớn nhất của nó.
Bây giờ, khi nhấp vào "Sau", tôi thấy rằng LCP được tìm nạp trước giảm xuống còn 1,3 giây:
Cơ chế SXG được hỗ trợ cho mọi kiểu dáng thiết bị. Để chuẩn bị cho việc đó, hãy đảm bảo bạn đáp ứng một trong các yêu cầu sau:
- Trang của bạn không
VarytheoUser-Agent(ví dụ: trang sử dụng thiết kế thích ứng hoặc URL riêng biệt dành cho thiết bị di động/máy tính). - Nếu trang của bạn sử dụng tính năng phân phát động, thì trang đó sẽ tự chú thích là chỉ dành cho thiết bị di động hoặc máy tính bằng cách sử dụng
<meta name=supported-media content=...>.
Tài nguyên phụ
Có thể sử dụng SXG để tìm nạp trước các tài nguyên phụ (bao gồm cả hình ảnh) cùng với HTML. Cloudflare ASX sẽ quét HTML để tìm các phần tử <link rel=preload> có cùng nguồn gốc (bên thứ nhất) và chuyển đổi chúng thành các tiêu đề của Đường liên kết tương thích với SXG. Thông tin chi tiết trong mã nguồn tại đây và tại đây.
Nếu mã này hoạt động, bạn sẽ thấy các lượt tìm nạp trước khác từ Google Tìm kiếm:
Để tối ưu hoá LCP, hãy xem xét kỹ thác nước của bạn và xác định những tài nguyên nào trên lộ trình quan trọng để hiển thị phần tử lớn nhất. Nếu không thể tìm nạp trước các giá trị này, hãy cân nhắc xem có thể gỡ bỏ các giá trị này khỏi đường dẫn quan trọng hay không. Chú ý các tập lệnh ẩn trang cho đến khi tải xong.
Bộ nhớ đệm SXG của Google cho phép tải trước tối đa 20 tài nguyên phụ, và ASX đảm bảo rằng giới hạn này không vượt quá. Tuy nhiên, bạn sẽ gặp rủi ro khi thêm quá nhiều lượt tải trước tài nguyên phụ. Trình duyệt sẽ chỉ sử dụng các tài nguyên phụ được tải trước nếu tất cả các tài nguyên đó đã tìm nạp xong, để ngăn chặn hoạt động theo dõi trên nhiều trang web. Càng có nhiều tài nguyên phụ thì càng có ít khả năng tất cả các nguồn phụ đó đã hoàn tất quá trình tìm nạp trước trước khi người dùng nhấp vào để đến trang của bạn.
Trình xác thực SXG hiện không kiểm tra các tài nguyên phụ; để gỡ lỗi, hãy sử dụng curl hoặc dump-signedexchange trong thời gian chờ đợi.
Đo
Sau khi tối ưu hoá việc cải thiện LCP qua WebPageTest, bạn nên đo lường tác động của việc tìm nạp trước SXG đối với hiệu suất tổng thể của trang web.
Các chỉ số phía máy chủ
Khi đo lường các chỉ số phía máy chủ, chẳng hạn như Time to First Byte (TTFB), bạn cần lưu ý rằng trang web của bạn chỉ phân phát SXG cho những trình thu thập dữ liệu chấp nhận định dạng này. Chỉ đo lường TTFB ở các yêu cầu đến từ người dùng thực chứ không phải bot. Bạn có thể thấy rằng việc tạo SXG sẽ làm tăng TTFB cho các yêu cầu trình thu thập thông tin, nhưng điều này không ảnh hưởng đến lượt yêu cầu của khách truy cập của bạn.
Các chỉ số phía máy khách
SXG mang lại lợi ích lớn nhất về tốc độ cho các chỉ số phía máy khách, đặc biệt là LCP. Khi đo lường tác động của chúng, bạn chỉ cần bật Cloudflare ASX, chờ Googlebot thu thập lại dữ liệu, đợi thêm 28 ngày để tổng hợp Chỉ số quan trọng chính của trang web (CWV), rồi xem chỉ số CWV mới của bạn. Tuy nhiên, bạn có thể khó nhận ra sự thay đổi này khi kết hợp với tất cả những thay đổi khác trong khung thời gian này.
Thay vào đó, tôi thấy tính năng "Phóng to" sẽ hữu ích trên lượt tải trang có khả năng bị ảnh hưởng và cho rằng "SXG ảnh hưởng đến X% số lượt xem trang, cải thiện LCP thêm Y mili giây ở phân vị thứ 75".
Hiện tại, việc tìm nạp trước SXG chỉ diễn ra trong một số điều kiện nhất định:
- Trình duyệt Chromium (ví dụ: Chrome hoặc Edge, ngoại trừ trên iOS), phiên bản M98 trở lên
Referer: google.comhoặc các miền tìm kiếm khác của Google. (Xin lưu ý rằng trong Google Analytics, thẻ giới thiệu áp dụng cho tất cả lượt xem trang trong phiên, trong khi tìm nạp trước SXG chỉ áp dụng cho lượt xem trang đầu tiên và được liên kết trực tiếp từ Google Tìm kiếm.)
Đọc mục Nghiên cứu đương thời để biết cách đo lường "X% lượt xem trang" và "cải thiện LCP thêm Y mili giây".
Nghiên cứu đương đại
Khi xem dữ liệu theo dõi người dùng thực (RUM), bạn nên chia lượt tải trang thành SXG và không phải SXG. Khi làm như vậy, bạn cần hạn chế tập hợp các lượt tải trang mà bạn xem xét, vì vậy, nhóm không phải SXG sẽ khớp với điều kiện tham gia SXG nhằm tránh thiên lệch lựa chọn. Nếu không, tất cả nội dung sau đây sẽ chỉ tồn tại trong nhóm lượt tải trang không phải SXG, vốn có thể có LCP khác nhau bẩm sinh:
- Thiết bị iOS: do sự khác biệt về tốc độ phần cứng hoặc mạng giữa những người dùng sử dụng các thiết bị này.
- Các trình duyệt Chromium cũ: vì lý do tương tự.
- Thiết bị máy tính: vì cùng một lý do hoặc vì bố cục trang gây ra một "phần tử lớn nhất" khác để được chọn.
- Các thao tác điều hướng trên cùng một trang web (khách truy cập đi theo các đường liên kết bên trong trang web): vì họ có thể sử dụng lại các tài nguyên phụ đã lưu vào bộ nhớ đệm của lần tải trang trước đó.
Trong Google Analytics (UA), hãy tạo 2 phương diện tuỳ chỉnh có phạm vi "Lượt truy cập", trong đó phương diện có tên là "isSXG" và một đường liên kết có tên là "đường liên kết giới thiệu". (Phương diện "Nguồn" tích hợp có phạm vi phiên hoạt động, nên không loại trừ các thao tác điều hướng trên cùng một trang web.)
Tạo một phân khúc tuỳ chỉnh có tên là "Phản thực của SXG" bằng các bộ lọc sau AND được kết hợp với nhau:
referrerbắt đầu bằnghttps://www.google.Browserkhớp chính xác vớiChromeBrowserPhiên bản khớp với biểu thức chính quy^(9[8-9]|[0-9]{3})isSXGkhớp chính xác vớifalse
Tạo một bản sao của phân khúc này, đặt tên là "SXG", ngoại trừ trường hợp isSXG khớp chính xác với true.
Trong mẫu trang web, hãy thêm đoạn mã sau vào phía trên đoạn mã Google Analytics. Đây là cú pháp đặc biệt mà ASX sẽ thay đổi false thành true khi tạo SXG:
<script data-issxg-var>window.isSXG=false</script>
Tuỳ chỉnh tập lệnh báo cáo Google Analytics theo đề xuất để ghi lại LCP. Nếu bạn đang sử dụng gtag.js, hãy sửa đổi lệnh 'config' để đặt phương diện tuỳ chỉnh (thay thế 'dimension1' và 'dimension2' bằng tên mà Google Analytics sẽ sử dụng):
gtag('config', 'YOUR_TRACKING_ID', {
'dimension1': String(isSXG),
'dimension2': document.referrer,
});
Nếu bạn đang sử dụng analytics.js, hãy sửa đổi lệnh 'create' như được ghi tại đây.
Sau khi đợi vài ngày để thu thập một số dữ liệu, hãy chuyển đến báo cáo Sự kiện Google Analytics rồi thêm thông tin chi tiết cho phân khúc SXG. Mã này cần được điền vào X cho "SXG ảnh hưởng đến X% lượt xem trang":
Cuối cùng, hãy chuyển đến Báo cáo chỉ số quan trọng về trang web, chọn "Chọn phân khúc" rồi chọn "Phản thực tế SXG" và "SXG".
Nhấp vào "Gửi" và bạn sẽ thấy mức phân phối LCP cho hai phân đoạn. Thông tin này sẽ điền vào Y để "cải thiện LCP thêm Y mili giây ở phân vị thứ 75":
Chú ý
Sau khi bạn áp dụng tất cả các bộ lọc trên, lượt tải trang đối chứng SXG phải bao gồm những nội dung sau:
- Thiếu bộ nhớ đệm: Nếu bộ nhớ đệm của Google SXG không có bản sao mới của SXG cho một URL nhất định, thì phiên bản này sẽ chuyển hướng đến URL gốc tại trang web của bạn.
- Các loại kết quả khác: Hiện tại, Google Tìm kiếm chỉ hỗ trợ SXG cho kết quả tiêu chuẩn trên web và một vài loại khác. Một số loại khác, như Đoạn trích nổi bật và băng chuyền Tin bài hàng đầu, sẽ liên kết đến URL gốc trên trang web của bạn.
- URL không đủ điều kiện: Nếu một số trang trên trang web của bạn không đủ điều kiện dùng SXG (chẳng hạn như không thể lưu vào bộ nhớ đệm), thì chúng có thể xuất hiện trong nhóm này.
Có thể còn tồn tại sai lệch giữa lượt tải trang SXG và lượt tải trang không dùng SXG ở trên. Tuy nhiên, độ sai lệch này phải nhỏ hơn mức độ sai lệch được đề cập ở đầu phần Nghiên cứu tạm thời. Ví dụ: có thể các trang không thể lưu vào bộ nhớ đệm chậm hơn hoặc nhanh hơn các trang có thể lưu vào bộ nhớ đệm. Nếu bạn nghi ngờ đây có thể là vấn đề, hãy cân nhắc xem xét dữ liệu chỉ dành cho một URL cụ thể đủ điều kiện sử dụng SXG để xem kết quả có khớp với nghiên cứu tổng thể hay không.
Nếu trang web của bạn có một số trang AMP, thì có thể trang web của bạn sẽ không thấy được những điểm cải thiện về hiệu suất khi bật SXG, vì chúng có thể đã được tìm nạp trước từ Google Tìm kiếm. Hãy cân nhắc thêm một bộ lọc để loại trừ những trang như vậy, để "phóng to" thêm về những thay đổi có liên quan.
Cuối cùng, ngay cả khi giải quyết mọi sai lệch lựa chọn, thì vẫn có nguy cơ thiên lệch sinh tồn khiến việc cải thiện LCP trông giống như sự suy giảm trong số liệu thống kê RUM. Bài viết này làm rất tốt việc giải thích rủi ro đó và đề xuất xem xét một số dạng chỉ số về tỷ lệ bỏ qua để phát hiện xem điều này có xảy ra hay không.
Trước/sau khi nghiên cứu
Để chứng thực kết quả của nghiên cứu hiện đại, bạn nên so sánh LCP trước và sau khi bật SXG. Đừng giới hạn ở lượt xem trang SXG, để loại bỏ những thiên kiến tiềm ẩn nêu trên. Thay vào đó, hãy xem các kết quả đủ điều kiện cho SXG. Bạn có thể xem các định nghĩa về phân khúc nêu trên nhưng không có quy tắc ràng buộc đối với isSXG.
Xin lưu ý rằng Google Tìm kiếm có thể mất đến vài tuần để thu thập lại dữ liệu của tất cả các trang trên trang web của bạn, nhằm xác định rằng bạn đã bật SXG. Trong vài tuần đó, có những thiên kiến tiềm ẩn khác có thể xảy ra:
- Bản phát hành trình duyệt mới hoặc các điểm cải tiến về mặt người dùng có thể tăng tốc độ tải trang.
- Một sự kiện quan trọng như ngày lễ có thể làm sai lệch lưu lượng truy cập so với bình thường.
Để xác nhận các nghiên cứu ở trên, bạn cũng nên xem xét tổng thể LCP thuộc phân vị thứ 75 trước và sau khi thay đổi. Việc tìm hiểu về một tập hợp con tổng thể không nhất thiết cho chúng ta biết về tổng dân số. Ví dụ: giả sử SXG cải thiện 10% số lượt tải trang thêm 800 mili giây.
- Nếu đây là những lượt tải trang nhanh nhất đạt 10%, thì nó hoàn toàn không ảnh hưởng đến phân vị thứ 75.
- Nếu đó là 10% thời gian tải trang chậm nhất, nhưng chúng chậm hơn LCP ở phân vị thứ 75 hơn 800 mili giây để bắt đầu, thì hoàn toàn không ảnh hưởng đến phân vị thứ 75.
Đây là những ví dụ mang tính cực đoan, có thể không phản ánh được thực tế, nhưng hy vọng có thể minh hoạ cho vấn đề này. Trong thực tế, có khả năng SXG sẽ ảnh hưởng đến phân vị thứ 75 đối với hầu hết các trang web. Tốc độ điều hướng trên nhiều trang web thường là một trong những quá trình chậm nhất và những điểm cải tiến đáng kể từ việc tìm nạp trước có xu hướng được cải thiện đáng kể.
Chọn không tham gia một số URL
Cuối cùng, có một cách để so sánh hiệu suất của SXG là vô hiệu hoá SXG đối với một số URL trên trang web của bạn. Ví dụ: bạn có thể đặt tiêu đề CDN-Cache-Control: no-store để ngăn Cloudflare ASX tạo một SXG. Tôi khuyên bạn không nên làm như vậy.
Phương pháp này có nguy cơ sai số do lựa chọn nhiều hơn so với các phương pháp nghiên cứu khác. Ví dụ: điều này có thể tạo ra sự khác biệt lớn cho dù trang chủ của trang web hoặc một URL phổ biến tương tự được chọn vào nhóm đối chứng hay nhóm thử nghiệm.
Nghiên cứu cách ly
Phương pháp lý tưởng để đo lường tác động là tiến hành nghiên cứu cách ly. Rất tiếc, hiện tại bạn không thể thực hiện loại thử nghiệm này. Chúng tôi dự định trong tương lai sẽ hỗ trợ thử nghiệm như vậy.
Nghiên cứu giữ lại có các đặc điểm sau:
- Trong nhóm thử nghiệm, một số tỷ lệ ngẫu nhiên số lượt xem trang có thể là SXG được "giữ lại" và được phân phát ở dạng không phải SXG. Điều này cho phép "tương lai" so sánh giữa số người dùng, thiết bị, tình huống và trang tương đương.
- Những lượt xem trang được giữ lại (còn gọi là phản thực tế) được gắn nhãn như vậy trong số liệu phân tích. Tính năng này cho phép "phóng to" dữ liệu, trong đó chúng tôi có thể so sánh số lượt tải trang SXG trong đối chứng với nội dung phản thực tế của SXG trong thử nghiệm. Nhờ đó, tính năng này sẽ làm giảm hiện tượng tải trang khác mà không bị ảnh hưởng bởi hoạt động tìm nạp trước SXG.
Điều này sẽ loại bỏ các nguồn sai lệch lựa chọn nói trên, mặc dù sẽ không loại bỏ được nguy cơ thiên kiến về khả năng tồn tại của LCP. Cả hai thuộc tính này đều yêu cầu trình duyệt hoặc đường liên kết giới thiệu phải bật.
Kết luận
Chà! Nhiều lắm. Chúng tôi hy vọng dự án này sẽ phác thảo bức tranh toàn diện hơn về cách kiểm thử hiệu suất của SXG trong một thử nghiệm trong phòng thí nghiệm, cách tối ưu hoá hiệu suất trong một vòng hồi tiếp chặt chẽ với thử nghiệm trong phòng thí nghiệm và cuối cùng là cách đo lường hiệu suất trong thực tế. Kết hợp tất cả những yếu tố này lại với nhau sẽ giúp bạn tận dụng tối đa SXG và đảm bảo chúng mang lại lợi ích cho trang web và người dùng của bạn.
Nếu bạn có lời khuyên khác về cách đạt được hiệu suất SXG, vui lòng cho chúng tôi biết! Báo cáo lỗi dựa trên developer.chrome.com cùng với các điểm cải tiến mà bạn đề xuất.
Để biết thêm thông tin về cơ chế trao đổi có chữ ký, hãy tham khảo tài liệu trên web.dev và tài liệu của Google Tìm kiếm.