Cách đo lường và tối ưu hoá cơ chế trao đổi có chữ ký để khai thác tối đa cơ chế trao đổi có chữ ký
Trao đổi có chữ ký (SXG) là một phương tiện để cải thiện tốc độ trang, chủ yếu là Thời gian hiển thị nội dung lớn nhất (LCP). Khi tham chiếu các đường liên kết đến một trang (hiện là Google Tìm kiếm) của các trang web, chúng có thể tìm nạp trước trang đó vào bộ nhớ đệm của trình duyệt trước khi người dùng nhấp vào đường liên kết đó.
Có thể tạo các trang web mà khi được tìm nạp trước không cần 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à do mức sử dụng CPU):
Ngày nay, hầu hết các nhà phát hành ứng dụng SXG đều đang sử dụng tính năng Cơ chế trao đổi có chữ ký tự động (ASX) dễ sử dụng của Cloudflare (mặc dù cũng có các lựa chọn nguồn mở):
Trong nhiều trường hợp, chỉ cần 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, bạn cần làm thêm một vài bước để đảm bảo những SXG này hoạt động như dự kiến trong từng giai đoạn của quy trình, và để tối ưu hoá các trang nhằm khai thác tối đa tính 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 và tìm hiểu cách tư vấn cho các trang web về cách đảm bảo họ khai thác tối đa việc triển khai SXG. Bài đăng này là một tập hợp những lời khuyên của tôi. Tôi sẽ thực hiệ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 của 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ý bằng mã hoá bằng một chứng chỉ PKI web. Khi tải một SXG, trình duyệt sẽ xác minh tất cả những thông tin sau:
- Cơ chế SXG chưa hết hạn.
- Chữ ký 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 không xác minh được, trình duyệt sẽ từ bỏ SXG và tìm nạp URL đã ký. Nếu xác minh thành công, trình duyệt sẽ tải phản hồi đã ký, coi đó là phản hồi trực tiếp từ URL đã ký. Việc này cho phép lưu trữ lại SXG trên mọi máy chủ, miễn là chưa hết hạn hoặc chưa bị sửa đổi kể từ khi ký.
Trong 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 những trang hỗ trợ cơ chế SXG, Google Tìm kiếm có thể tìm nạp trước bản sao đã lưu trong bộ nhớ đệm, được lưu trữ trên webpkgcache.com. Những URL của webpkgcache.com này không ảnh hưởng đến cách hiển thị hoặc hoạt động của trang vì trình duyệt tôn trọng URL gốc đã ký. Tính năng tìm nạp trước có thể giúp trang của bạn tải nhanh hơn nhiều.
Phân tích
Để biết lợi ích của SXG, hãy bắt đầu bằng cách sử dụng một công cụ 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ể dùng công cụ 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 quy trình kiểm thử mà không cần dùng SXG bằng cách làm 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 bạn muốn kiểm tra.
- Chuyển đến Cấu hình nâng cao. (Bạn cần phải 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 ở đây sẽ giúp đảm bảo rằng các phương án kiểm tra đều 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ần thử nghiệm cần chạy" lên 7.
- Nhấp vào Start Test (Bắt đầu kiểm thử).
Tạo hoạt động kiểm thử bằng SXG bằng cách làm theo các bước tương tự như trên. Nhưng trước khi nhấp vào Start Test (Bắt đầu kiểm thử), 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 hai 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 bất kỳ kết quả nào của Google Tìm kiếm thì bạn có thể sử dụng trang tìm nạp trước này để tạo trang kết quả tìm kiếm giả mạo cho mục đích này.
Để xác định URL navigate thứ hai, hãy truy cập 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 kiểm tra xong, hãy truy cập vào phần Nhật ký kiểm tra, chọn hai 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 lần chạy có LCP trung bình cho mỗi bên 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 mục Độ mờ của thác nước và kéo thanh trượt. Để xem video, hãy nhấp vào Điều chỉnh các 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 rằng thác nước "với SXG" không bao gồm một hàng cho HTML và quá trình tìm nạp cho tài nguyên phụ 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 đang tìm nạp trước SXG, thì tức là WebPageTest đã thực hiện thành công tất cả các bước của quy trình. Bạn có thể chuyển đến phần Optimize (Tối ưu hoá) để tìm hiểu cách cải thiện LCP hơn nữa. Nếu không, bạn sẽ cần phải tìm hiểu vấn đề không thành công ở đâ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 rằng 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 giả vờ là 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 tìm nạp URL hiện tại bằng tiêu đề yêu cầu Accept cho biết ưu tiên phiên bản SXG. Nếu bạn thấy dấu kiểm (✅) bên cạnh Origin (Nguồn gốc), thì tức là hệ thố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 thập (❌), thì tức là ứng dụng SXG chưa được trả về:
Nếu Cloudflare ASX được bật, thì nguyên nhân có thể nhất dẫn đến dấu thập (❌) là do tiêu đề phản hồi kiểm soát bộ nhớ đệm ngăn chặn điều đó. ASX xem xét các tiêu đề có các tên sau đây:
Cache-ControlCDN-Cache-ControlSurrogate-ControlCloudflare-CDN-Cache-Control
Nếu bất kỳ tiêu đề nào trong số này chứa bất kỳ giá trị tiêu đề nào sau đây, thì tiêu đề đó sẽ ngăn việc tạo SXG:
privateno-storeno-cachemax-agenhỏ hơn 120, trừ phi bịs-maxagelớn hơn hoặc bằng 120 ghi đè
ASX không tạo một SXG trong những trường hợp như vậ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.
Dấu gạch chéo (❌) cũng có thể là một lý do khác là do một trong các tiêu đề phản hồi có trạng thái này, ngoại trừ Set-Cookie. ASX sẽ xoá tiêu đề Set-Cookie để tuân thủ quy cách kỹ thuật của SXG.
Một lý do khác có thể là do tiêu đề phản hồi Vary: Cookie. Googlebot tìm nạp 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 chúng cho nhiều khách truy cập. Nếu bạn phân phát HTML khác nhau cho 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ể sử 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ó xuất hiện và hợp lệ, bạn sẽ thấy một bản in của SXG mà con người có thể đọc được. 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 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 bằng Google Tìm kiếm. Nếu ứng dụng đã được lập chỉ mục dưới dạng một SXG, thì đường liên kết của Google đến trang của bạn sẽ bao gồm một 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ả đó, thì Google Tìm kiếm cũng 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 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 SXG đã lưu vào bộ nhớ đệm để hiển thị 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 kiếm URL chứa webpkgcache.
Nếu <a> trỏ đến webpkgcache.com, thì có nghĩa là hoạt động lập chỉ mục của Google Tìm kiếm đối với cơ chế trao đổi có chữ ký đang hoạt động. Bạn có thể chuyển đến phần Truyền dẫn.
Nếu không, có thể 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. Hãy dùng thử Công cụ kiểm tra URL của Google Search Console:
Nếu có tiêu đề digest: mi-sha256-03=..., thì tức là 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 chưa được phân phối 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 nó vẫn chưa được liên kết, thì có thể cơ chế này không đáp ứng được các yêu cầu về bộ nhớ đệm của SXG. Bạn có thể xem thêm thông tin ở phần tiếp theo.
Quy trình truyền dẫn
Khi lập chỉ mục một SXG, Google Tìm kiếm sẽ gửi bản sao đó đến SXG của Google. Cơ quan này sẽ xác thực dữ liệu dựa trên 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 sang bước Tối ưu hoá.
Nếu bài đánh giá không đáp ứng các yêu cầu, bạn sẽ thấy một dấu gạch chéo (❌) và một 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 ở chế độ nền, bạn sẽ thấy một biểu tượng đồng hồ cát (⌛):
Tài liệu dành cho nhà phát triển của Google về SXG cũng có hướng dẫn về cách truy vấn bộ nhớ đệm theo cách thủ công.
Tối ưu hoá
Nếu tiện ích Trình xác thực SXG của Chrome hiện tất cả dấu kiểm (✅), thì tức là bạn có thể phân phát một SXG cho người dùng! Hãy đọc tiếp để tìm hiểu cách tối ưu hoá trang web nhằm cải thiện LCP tối đa từ SXG.
max-age
Khi SXG hết hạn, Google SXG Cache 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 được chuyển hướng đến trang trên máy chủ lưu trữ ban đầu và trang này không được tìm nạp trước. Bạn thiết lập Cache-Control: max-age càng lâu thì tần suất tìm nạp trong nền này càng giảm và do đó, LCP có thể bị giảm tần suất tìm nạp trước.
Đây là sự đánh đổi giữa hiệu suất và độ mới. Bộ nhớ đệm cho phép chủ sở hữu trang web cung cấp cho SXG giới hạn tuổi tối đa 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. Đôi khi, chúng tôi nhận thấy rằng:
max-age=86400(1 ngày) trở lên phù hợp với hiệu suấtmax-age=120(2 phút) không
Chúng tôi hy vọng có thể tìm hiểu thêm về giá trị giữa hai loại dữ liệu này trong quá trình nghiên cứu dữ liệu thêm.
user-agent
Một lần, tôi thấy LCP tăng lên khi sử dụng cơ chế SXG được tìm nạp trước. Tôi đã chạy công cụ WebPageTest, so sánh kết quả trung bình mà không có và với phương thức tìm nạp trước SXG. Nhấp vào Sau ở bên dưới:
Tôi thấy rằng tính năng tìm nạp trước đang hoạt động. HTML bị xoá khỏi đường dẫn quan trọng và do đó, tất cả tài nguyên phụ có thể tải sớm hơn. Nhưng LCP (đường đứt né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 các đoạn phim. Tôi nhận thấy trang được kết xuất 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" của 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. Biểu ngữ này đã đẩy dòng tiêu đề xuống dưới màn hình đầu tiên và khiến phần tử lớn nhất mới trở thành hộp thoại đồng ý sử dụng cookie tải từng phần. Mọi thứ được kết xuất 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 đã tìm hiểu kỹ hơn và phát hiện ra lý do dẫn đến sự khác biệt về bố cục là vì trang thay đổi theo User-Agent và đã xảy ra lỗi về logic. Quảng cáo 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 của SXG cho biết đó là thiết bị di động. Sau khi vấn đề này được khắc phục, trình duyệt đã xác định lại chính xác dòng tiêu đề của trang thành phần tử lớn nhất.
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 1,3 giây:
Chúng tôi hỗ trợ SXG trên mọi kiểu dáng. Để chuẩn bị cho điều đó, hãy đảm bảo một trong những điều sau là đúng:
- Trang của bạn không
VarytheoUser-Agent(ví dụ: trang sử dụng thiết kế thích ứng hoặc URL dành riêng cho thiết bị di động/máy tính). - Nếu 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ể dùng SXG để tìm nạp trướ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 (của bên thứ nhất) và chuyển đổi các phần tử đó thành các tiêu đề Đườ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 tính năng 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á cho LCP, hãy xem xét kỹ thác nước của bạn và tìm ra tài nguyên nào trên lộ trình quan trọng để kết xuất phần tử lớn nhất. Nếu không thể tìm nạp trước, hãy cân nhắc xem chúng có thể bị rời khỏi đường dẫn quan trọng hay không. Theo dõi các tập lệnh ẩn trang cho đến khi chúng tải xong.
Bộ nhớ đệm SXG của Google cho phép tối đa 20 lượt tải trước tài nguyên phụ và ASX đảm bảo rằng giới hạn này không vượt quá giới hạn. Tuy nhiên, bạn có thể có nguy cơ 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 tài nguyên đó hoàn tất quá trình tìm nạp trước trước khi người dùng nhấp vào 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á mức cải thiện LCP trong WebPageTest, bạn nên đo lường tác động của hoạt động tìm nạp trước SXG đối với hiệu suất tổng thể của trang web.
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ư Thời gian đặt trước byte đầu tiên (TTFB), bạn cần lưu ý rằng trang web của bạn chỉ phân phát SXG cho các trình thu thập dữ liệu chấp nhận định dạng này. Chỉ đo lường TTFB cho các yêu cầu đến từ người dùng thực, chứ không phải từ 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 của trình thu thập dữ liệu, nhưng điều này không ảnh hưởng đến trải nghiệm của khách truy cập.
Chỉ số phía máy khách
SXG mang lại nhiều lợi ích 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 những dữ liệu này, bạn chỉ cần bật Cloudflare ASX, đợi Googlebot thu thập lại dữ liệu, đợi thêm 28 ngày để tổng hợp Các chỉ số quan trọng về trang web (CWV), rồi xem số liệu CWV mới của bạn. Tuy nhiên, bạn có thể sẽ khó phát hiện ra sự thay đổi này khi kết hợp với những thay đổi khác trong khung thời gian này.
Thay vào đó, tôi thấy hữu ích khi "Phóng to" những lượt tải trang có khả năng bị ảnh hưởng và trình bày nội dung như sau: "SXG ảnh hưởng đến X% lượt xem trang, cải thiện LCP Y mili giây ở bách phân vị thứ 75".
Hiện tại, quá trình 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 khác trên Google Tìm kiếm. (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 hoạt động đó, trong khi tính năng tìm nạp trước SXG chỉ áp dụng cho lượt xem trang đầu tiên, được liên kết trực tiếp từ Google Tìm kiếm.)
Hãy đọc phần Nghiên cứu đương thời để biết cách đo lường "X% số lượt xem trang" và "cải thiện LCP thêm Y mili giây".
Nghiên cứu đương đại
Khi xem xét dữ liệu giám sát người dùng thực tế (rum), bạn nên chia lượt tải trang thành SXG và không phải SXG. Trong quá trình này, bạn cần phải giới hạn nhóm các lượt tải trang mà bạn xem. Như vậy, bên không thuộc SXG phù hợp với các điều kiện cho SXG, để tránh thiên kiến khi lựa chọn. Nếu không, tất cả những nội dung sau đây sẽ chỉ tồn tại trong tập hợp các lượt tải trang không phải SXG có thể đã tạo ra LCP vốn đã khác:
- Thiết bị iOS: do sự khác biệt về phần cứng hoặc tốc độ mạng giữa những người dùng sử dụng các thiết bị này.
- Trình duyệt Chromium cũ hơn: với lý do tương tự.
- Thiết bị máy tính: vì lý do tương tự hoặc vì bố cục trang khiến "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 trang web (khách truy cập nhấp vào các đường liên kết 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 từ 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", một phương diện có tên là "isSXG" và một phương diện có tên là "liên kết giới thiệu". (Phương diện "Nguồn" tích hợp có phạm vi phiên, vì vậy, không loại trừ các hoạt động điều hướng trên cùng trang web.)
Tạo một phân khúc tuỳ chỉnh có tên " phản thực tế SXG" bằng các bộ lọc sau VÀ kết hợp với nhau:
referrerbắt đầu bằnghttps://www.google.Browserkhớp chính xác vớiChrome- Phiên bản
Browserkhớp với biểu thức chính quy^(9[8-9]|[0-9]{3}) isSXGkhớp chính xác vớifalse
Hãy tạo một bản sao của phân khúc này (có 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 của bạn, hãy thêm đoạn mã sau đây vào phía trên đoạn mã Google Analytics. Đây là một cú pháp đặc biệt mà ASX sẽ thay đổi false thành true khi tạo một 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ử 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ó trong tài liệu tại đây.
Sau khi đợi vài ngày để thu thập một số dữ liệu, hãy truy cập vào báo cáo Sự kiện Google Analytics rồi thêm thông tin chi tiết về phân khúc SXG. Sau đây là phần điền vào ô X cho "SXG ảnh hưởng đến X% lượt xem trang":
Cuối cùng, hãy truy cập vào Báo cáo các chỉ số quan trọng về trang web, chọn "Chọn phân đoạn", sau đó chọn "Phản thực tế" và "SXG".
Nhấp vào "Gửi" và bạn sẽ thấy các mức phân phối LCP cho hai phân khúc. Thao tác này sẽ điền Y để "cải thiện LCP của chúng theo 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, nội dung tải trang đối chứng SXG sẽ bao gồm những nội dung sau:
- Thiếu bộ nhớ đệm: Nếu Google SXG Cache không có bản sao mới của SXG cho một URL cụ thể, thì nó 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 các kết quả trên web tiêu chuẩn và một số loại khác. Những đoạn trích nổi bật và băng chuyền Tin bài hàng đầu khác 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 sử dụng cơ chế SXG (ví dụ: vì không thể lưu vào bộ nhớ đệm), các trang đó có thể xuất hiện trong tập hợp này.
Có thể vẫn còn sự chênh lệch giữa các lượt tải trang SXG và các tải trang không phải SXG ở trên. Tuy nhiên, mức độ sai lệch này sẽ nhỏ hơn so với những thiên kiến nêu ở đầu phần Nghiên cứu đương đại. Ví dụ: có thể các trang không thể lưu trong bộ nhớ đệm chậm hơn hoặc nhanh hơn các trang có thể lưu trong bộ nhớ đệm. Nếu bạn nghi ngờ đây có thể là vấn đề, hãy cân nhắc việc xem xét dữ liệu chỉ giới hạn ở một URL cụ thể đủ điều kiện cho 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ể các trang đó sẽ không được cải thiện hiệu suất khi bật SXG, vì các trang này có thể đã được tìm nạp trước từ Google Tìm kiếm. Hãy cân nhắc việc thêm một bộ lọc để loại trừ các trang như vậy, nhằm "Phóng to" hơn nữa những thay đổi có liên quan.
Cuối cùng, ngay cả khi giải quyết mọi thiên kiến do lựa chọn, có nguy cơ rằng thiên kiến vượt qua sẽ khiến mứ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 giải thích rất kỹ về rủi ro đó, đồng thời đề xuất xem xét một số dạng chỉ số bỏ ngang để xác định xem điều này có đang 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 đương đại này, bạn nên so sánh LCP trước và sau khi bật cơ chế SXG. Đừng giới hạn ở lượt xem trang SXG, để loại bỏ những thiên kiến có thể xảy ra nêu trên. Thay vào đó, hãy xem xét các kết quả đủ điều kiện cho SXG, tức là 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 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 đối với mọi trang trên trang web của bạn nhằm xác định việc SXG đã được bật cho các trang đó. Trong những tuần đó, có thể có các thành kiến khác có thể xảy ra:
- Các bản phát hành trình duyệt mới hoặc cải tiến về phần cứng của người dùng có thể tăng tốc độ tải trang.
- Một sự kiện quan trọng như dịp lễ có thể làm sai lệch lưu lượng truy cập so với bình thường.
Bạn cũng nên xem xét LCP tổng thể tại phân vị thứ 75 trước và sau để xác nhận các nghiên cứu ở trên. Việc tìm hiểu về một nhóm nhỏ dân số 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% lượt tải trang thêm 800 mili giây.
- Nếu những trang này đã tải 10% tải trang nhanh nhất thì nó sẽ không ảnh hưởng đến phân vị thứ 75 nào cả.
- Nếu các trang đó tải trang chậm nhất 10%, nhưng chậm hơn 800 mili giây so với LCP phân vị thứ 75, thì điều này sẽ không ảnh hưởng đến phân vị thứ 75.
Đây là những ví dụ đặc biệt, có thể không phản ánh đúng thực tế, nhưng hy vọng có thể minh hoạ cho vấn đề. Trong thực tế, có khả năng SXG sẽ ảnh hưởng đến phân vị thứ 75 của hầu hết các trang web. Hoạt động điều hướng trên nhiều trang web có xu hướng chậm nhất và sự cải thiện từ hoạt động tìm nạp trước có xu hướng đáng kể.
Chọn không sử dụng một số URL
Cuối cùng, một cách để so sánh hiệu suất của SXG là vô hiệu hoá SXG cho 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 SXG. Tôi khuyên bạn không nên như vậy.
Phương pháp này có thể có nguy cơ thiên vị trong lựa chọn cao 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 hay một URL phổ biến tương tự được chọn vào nhóm kiểm soát hay nhóm thử nghiệm.
Nghiên cứu cách ly
Cách lý tưởng nhất để đo lường tác động là tiến hành một nghiên cứu cách ly. Rất tiếc, bạn hiện không thể thực hiện loại thử nghiệm này. Chúng tôi dự định sẽ hỗ trợ thêm cho một thử nghiệm như vậy trong tương lai.
Nghiên cứu cách ly có các thuộc tính sau:
- Trong nhóm thử nghiệm, một số lượt xem trang ngẫu nhiên sẽ bị SXG bị "giữ lại" và phân phát dưới dạng không phải SXG. Điều này cho phép so sánh "tương đương" giữa người dùng, thiết bị, tình huống và trang tương đương.
- Những lượt xem trang cách ly (còn gọi là phản thực tế) sẽ được gắn nhãn như vậy trong phần phân tích. Nhờ đó, chúng tôi có thể "thu nhỏ" dữ liệu. Trong quá trình này, chúng tôi có thể so sánh 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. Đổi lại, điều này sẽ làm giảm tiếng ồn từ các lượt tải trang khác vốn không bị ảnh hưởng bởi quá trình tìm nạp trước SXG.
Điều này sẽ loại bỏ các nguồn thiên lệch lựa chọn có thể xảy ra nêu trên, mặc dù sẽ không loại bỏ được nguy cơ thiên kiến sinh tồn 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 để bật.
Kết luận
Chà! Như vậy là rất nhiều. Hy vọng công cụ này sẽ giúp bạn hiểu rõ hơn về cách kiểm tra hiệu suất của SXG trong một bài kiểm thử 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 bài kiểm thử trong phòng thí nghiệm và cuối cùng là cách đo lường hiệu suất của tính năng này trong thực tế. Khi kết hợp tất cả những yếu tố này với nhau, bạn có thể khai thác tối đa SXG, đồng thời đảm bảo rằng 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ó thêm lời khuyên về cách theo dõi hiệu suất của SXG, vui lòng cho chúng tôi biết! Báo cáo lỗi trên developer.chrome.com cùng những điểm cải tiến 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 về web.dev và tài liệu về Google Tìm kiếm.