การเพิ่มประสิทธิภาพ LCP โดยใช้ Signed Exchange

วิธีวัดและเพิ่มประสิทธิภาพการแลกเปลี่ยนที่ลงนามเพื่อให้ได้ประโยชน์สูงสุด

Signed Exchange (SXG) เป็นวิธีเพิ่มความเร็วหน้าเว็บ โดยใช้ฟีเจอร์ Largest Contentful Paint (LCP) เป็นหลัก เมื่อไซต์ที่อ้างอิง (ปัจจุบันคือ Google Search) ลิงก์ไปที่หน้าเว็บ ผู้ใช้สามารถดึงข้อมูลล่วงหน้าลงในแคชของเบราว์เซอร์ก่อนที่ผู้ใช้จะคลิกลิงก์

คุณสามารถสร้างหน้าเว็บที่เมื่อทำการดึงข้อมูลล่วงหน้าแล้ว จะไม่ต้องใช้เครือข่ายในเส้นทางที่สำคัญในการแสดงผลหน้าเว็บ ในการเชื่อมต่อ 4G การโหลดหน้าเว็บนี้จาก 2.8 วินาทีเป็น 0.9 วินาที (0.9 วินาทีที่เหลือส่วนใหญ่มาจากการใช้ CPU)

ผู้คนส่วนใหญ่ที่เผยแพร่ SXG ในปัจจุบันใช้ฟีเจอร์ Automatic Signed Exchange (ASX) ที่ใช้งานง่ายของ Cloudflare (แต่มีตัวเลือกโอเพนซอร์สด้วยเช่นกัน)

ในหลายกรณี การทำเครื่องหมายในช่องเพื่อเปิดใช้ฟีเจอร์นี้ก็เพียงพอที่จะทำให้ได้การปรับปรุงที่สำคัญอย่างข้างต้น บางครั้งอาจมีอีก 2-3 ขั้นตอนเพื่อให้มั่นใจว่า SXG เหล่านี้ทํางานได้ตามที่ต้องการในแต่ละขั้นตอนของไปป์ไลน์ และเพื่อเพิ่มประสิทธิภาพหน้าเว็บเพื่อใช้ประโยชน์จากการดึงข้อมูลล่วงหน้าอย่างเต็มที่

ในช่วง 2-3 เดือนที่ผ่านมานับตั้งแต่เปิดตัว Cloudflare เราได้อ่านและตอบคำถามในฟอรัมต่างๆ และเรียนรู้วิธีให้คำแนะนำเว็บไซต์เกี่ยวกับวิธีใช้ประโยชน์จากการทำให้ใช้งานได้จริงของ SXG ให้ได้มากที่สุด โพสต์นี้เป็นคอลเล็กชันคําแนะนําของฉัน เราจะอธิบายขั้นตอนต่อไปนี้

• วิเคราะห์ประสิทธิภาพ SXG โดยใช้ WebPageTest
• แก้ไขข้อบกพร่องในไปป์ไลน์ SXG หากขั้นตอนการวิเคราะห์ระบุว่าไม่ทํางาน
• เพิ่มประสิทธิภาพหน้าเว็บสำหรับการดึงข้อมูล SXG ล่วงหน้า รวมถึงการตั้งค่า max-age ที่เหมาะสมและการโหลดทรัพยากรย่อยที่บล็อกการแสดงผลล่วงหน้า
• วัดการปรับปรุง SXG โดยใช้ Google Analytics โดยเลือกกลุ่มทดสอบและกลุ่มควบคุมที่เหมาะสม

บทนำ

SXG คือไฟล์ที่มี URL, ชุดส่วนหัวการตอบกลับ HTTP และเนื้อหาการตอบกลับ ซึ่งทั้งหมดได้รับการรับรองการเข้ารหัสโดยใบรับรอง Web PKI เมื่อเบราว์เซอร์โหลด SXG ระบบจะยืนยันสิ่งต่อไปนี้ทั้งหมด

• SXG ยังไม่หมดอายุ
• ลายเซ็นตรงกับ URL, ส่วนหัว, เนื้อความ และใบรับรอง
• ใบรับรองถูกต้องและตรงกับ URL

หากการยืนยันไม่สำเร็จ เบราว์เซอร์จะเลิกใช้ SXG และดึง URL ที่ลงนามแทน หากการยืนยันสําเร็จ เบราว์เซอร์จะโหลดการตอบกลับที่รับรอง โดยถือว่าการตอบกลับนั้นมาจาก URL ที่รับรองโดยตรง ซึ่งช่วยให้โฮสต์ SXG อีกครั้งในเซิร์ฟเวอร์ใดก็ได้ ตราบใดที่ SXG นั้นยังไม่หมดอายุหรือมีการแก้ไขนับตั้งแต่ลงนาม

ในกรณีของ Google Search นั้น SXG จะเปิดใช้การดึงข้อมูลหน้าเว็บล่วงหน้าในผลการค้นหา สําหรับหน้าที่รองรับ SXG นั้น Google Search จะดึงข้อมูลหน้าเว็บสำเนาที่แคชไว้ซึ่งโฮสต์ใน webpkgcache.com ล่วงหน้าได้ URL ของ webpkgcache.com เหล่านี้จะไม่ส่งผลต่อการแสดงผลหรือลักษณะการทํางานของหน้า เนื่องจากเบราว์เซอร์จะยึดตาม URL เดิมที่ลงชื่อไว้ การดึงข้อมูลล่วงหน้าช่วยให้หน้าเว็บโหลดได้เร็วขึ้นมาก

วิเคราะห์

หากต้องการดูประโยชน์ของ SXG ให้เริ่มด้วยการใช้เครื่องมือในห้องทดลองเพื่อวิเคราะห์ประสิทธิภาพของ SXG ในเงื่อนไขที่ทำซ้ำได้ คุณสามารถใช้ WebPageTest เพื่อเปรียบเทียบ Waterfall และ LCP โดยใช้และไม่ได้ใช้การเรียกข้อมูลล่วงหน้า SXG

สร้างการทดสอบโดยไม่มี SXG ดังนี้

• ไปที่ WebPageTest แล้วลงชื่อเข้าใช้ การลงชื่อเข้าใช้จะบันทึกประวัติการทดสอบไว้เพื่อให้เปรียบเทียบได้ง่ายขึ้นภายหลัง
• ป้อน URL ที่ต้องการทดสอบ
• ไปที่ Advanced Configuration (คุณต้องใช้การกําหนดค่าขั้นสูงสําหรับการทดสอบ SXG ดังนั้นการใช้การกําหนดค่านี้ที่นี่จะช่วยให้ตัวเลือกการทดสอบเหมือนกัน)
• ในแท็บการตั้งค่าการทดสอบ คุณอาจต้องตั้งค่าการเชื่อมต่อเป็น 4G และเพิ่ม "จํานวนการทดสอบที่จะทํา" เป็น 7
• คลิกเริ่มการทดสอบ

สร้างการทดสอบด้วย SXG โดยใช้ขั้นตอนเดียวกับด้านบน แต่ก่อนที่จะคลิกเริ่มการทดสอบ ให้ไปที่แท็บสคริปต์ วางสคริปต์ WebPageTest ต่อไปนี้ และแก้ไข URL navigate 2 รายการตามวิธีการ

// 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

สําหรับ URL navigate รายการแรก หากหน้าเว็บของคุณยังไม่ปรากฏในผลการค้นหาของ Google Search คุณสามารถใช้หน้าการเรียกข้อมูลล่วงหน้านี้เพื่อสร้างหน้าผลการค้นหาจำลองเพื่อวัตถุประสงค์นี้

หากต้องการดู URL navigate รายการที่ 2 ให้ไปที่หน้าเว็บโดยใช้ส่วนขยาย Chrome ของโปรแกรมตรวจสอบ SXG แล้วคลิกไอคอนส่วนขยายเพื่อดู URL ของแคช

เมื่อการทดสอบเหล่านี้เสร็จสิ้นแล้ว ให้ไปที่ประวัติการทดสอบ เลือกการทดสอบ 2 รายการ แล้วคลิกเปรียบเทียบ

ใส่ &medianMetric=LCP ต่อท้าย URL เปรียบเทียบเพื่อให้ WebPageTest เลือกการเรียกใช้ที่มี LCP ตามค่ามัธยฐานสำหรับการเปรียบเทียบแต่ละฝั่ง (ค่าเริ่มต้นคือค่ามัธยฐานตามดัชนีความเร็ว)

หากต้องการเปรียบเทียบการแสดงโฆษณาสื่อกลางตามลำดับขั้น ให้ขยายส่วนความทึบแสงของการแสดงโฆษณาสื่อกลางตามลำดับขั้น แล้วลากแถบเลื่อน หากต้องการดูวิดีโอ ให้คลิกปรับการตั้งค่าแถบสไลด์ เลื่อนลงในกล่องโต้ตอบ แล้วคลิกดูวิดีโอ

หากการดึงข้อมูล SXG ล่วงหน้าสําเร็จ คุณจะเห็นว่า Waterfall "มี SXG" ไม่มีแถวสําหรับ HTML และการดึงข้อมูลทรัพยากรย่อยจะเริ่มเร็วขึ้น เช่น เปรียบเทียบ "ก่อน" กับ "หลัง" ที่นี่

แก้ไขข้อบกพร่อง

หาก WebPageTest แสดงว่าระบบกําลังดึงข้อมูล SXG ล่วงหน้า แสดงว่าขั้นตอนทั้งหมดในไปป์ไลน์สําเร็จแล้ว คุณข้ามไปที่ส่วนเพิ่มประสิทธิภาพเพื่อดูวิธีปรับปรุง LCP เพิ่มเติมได้ มิเช่นนั้น คุณจะต้องดูว่าขั้นตอนใดในไปป์ไลน์ที่ดำเนินการไม่สำเร็จและสาเหตุ โปรดอ่านต่อเพื่อดูวิธี

การเผยแพร่

ตรวจสอบว่าหน้าเว็บสร้างขึ้นเป็น SXG โดยจะต้องแอบอ้างเป็น Crawler วิธีที่ง่ายที่สุดคือการใช้ส่วนขยาย Chrome ของโปรแกรมตรวจสอบ SXG โดยทำดังนี้

ส่วนขยายจะดึงข้อมูล URL ปัจจุบันโดยมีส่วนหัวของคำขอ Accept ซึ่งระบุว่าต้องการใช้เวอร์ชัน SXG หากเห็นเครื่องหมายถูก (✅) ข้าง "ต้นทาง" แสดงว่าระบบแสดงผล SXG แล้ว คุณข้ามไปที่ส่วนการจัดทําดัชนีได้

หากเห็นเครื่องหมายกากบาท (❌) แสดงว่าระบบไม่แสดงผล SXG ให้ทำดังนี้

หากเปิดใช้ Cloudflare ASX สาเหตุที่เป็นไปได้มากที่สุดสำหรับเครื่องหมายกากบาท (❌) คือมีการใช้ส่วนหัวการตอบกลับการควบคุมแคชที่ป้องกันไม่ให้ใช้ ASX จะพิจารณาส่วนหัวที่มีชื่อต่อไปนี้

• Cache-Control
• CDN-Cache-Control
• Surrogate-Control
• Cloudflare-CDN-Cache-Control

หากส่วนหัวเหล่านี้มีค่าส่วนหัวต่อไปนี้ ระบบจะไม่สร้าง SXG

• private
• no-store
• no-cache
• max-age น้อยกว่า 120 เว้นแต่จะมีการลบล้างด้วย s-maxage ที่มากกว่าหรือเท่ากับ 120

ASX จะไม่สร้าง SXG ในกรณีเหล่านี้เนื่องจาก SXG อาจแคชไว้และนํามาใช้ซ้ำสําหรับการเข้าชมหลายครั้งและผู้เข้าชมหลายคน

สาเหตุที่เป็นไปได้อีกประการหนึ่งสำหรับเครื่องหมายกากบาท (❌) คือมีส่วนหัวการตอบกลับที่มีสถานะรายการใดรายการหนึ่งต่อไปนี้ ยกเว้น Set-Cookie ASX นำส่วนหัว Set-Cookie ออกเพื่อให้เป็นไปตามข้อกำหนด SXG

อีกสาเหตุที่เป็นไปได้คือการมีส่วนหัวการตอบกลับ Vary: Cookie Googlebot จะดึงข้อมูล SXG โดยไม่ใช้ข้อมูลเข้าสู่ระบบของผู้ใช้ และอาจแสดง SXG แก่ผู้เข้าชมหลายคน หากคุณแสดง HTML ที่แตกต่างกันแก่ผู้ใช้แต่ละรายตามคุกกี้ ผู้ใช้อาจเห็นประสบการณ์ที่ไม่ถูกต้อง เช่น มุมมองที่ออกจากระบบ

คุณสามารถใช้เครื่องมืออย่าง curl แทนส่วนขยาย Chrome ได้

curl -siH "Accept: application/signed-exchange;v=b3" $URL | less

หรือ dump-signedexchange

dump-signedexchange -verify -uri $URL

หากมี SXG อยู่และใช้งานได้ คุณจะเห็น SXG ที่พิมพ์ออกมาซึ่งมนุษย์อ่านได้ ไม่เช่นนั้นคุณจะเห็นข้อความแสดงข้อผิดพลาด

การจัดทำดัชนี

ตรวจสอบว่า Google Search จัดทําดัชนี SXG เรียบร้อยแล้ว เปิดเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome แล้วทำการค้นหาหน้าเว็บของคุณใน Google หากจัดทำดัชนีเป็น SXG แล้ว ลิงก์ของ Google ไปยังหน้าเว็บของคุณจะมี data-sxg-url ที่ชี้ไปยังสำเนาของ webpkgcache.com:

หาก Google Search คิดว่าผู้ใช้มีแนวโน้มที่จะคลิกผลการค้นหา ระบบจะแสดงผลการค้นหานั้นล่วงหน้าด้วย โดยทำดังนี้

องค์ประกอบ <link> จะสั่งให้เบราว์เซอร์ดาวน์โหลด SXG ลงในแคชการดึงข้อมูลล่วงหน้า เมื่อผู้ใช้คลิกองค์ประกอบ <a> เบราว์เซอร์จะใช้ SXG ที่แคชไว้เพื่อแสดงผลหน้าเว็บ

นอกจากนี้ คุณยังดูหลักฐานการดึงข้อมูลล่วงหน้าได้โดยไปที่แท็บ "เครือข่าย" ในเครื่องมือสำหรับนักพัฒนาเว็บ และค้นหา URL ที่มี webpkgcache

หาก <a> ชี้ไปยัง webpkgcache.com แสดงว่าการจัดทำดัชนี Google Search ของ Signed Exchange ทำงานอยู่ คุณสามารถข้ามไปยังส่วนการส่งผ่านข้อมูล

มิฉะนั้น อาจเป็นเพราะ Google ยังไม่ได้ทำการ Crawl หน้าเว็บอีกครั้งหลังจากที่คุณเปิดใช้ SXG ลองใช้เครื่องมือตรวจสอบ URL ของ Google Search Console โดยทำดังนี้

การมีส่วนหัว digest: mi-sha256-03=... หมายความว่า Google ทำการ Crawl เวอร์ชัน SXG สำเร็จ

หากไม่มีส่วนหัว digest แสดงว่าระบบอาจไม่ได้แสดง SXG แก่ Googlebot หรือดัชนีไม่ได้รับการอัปเดตนับตั้งแต่ที่คุณเปิดใช้ SXG

หากทำการ Crawl SXG สำเร็จ แต่ยังไม่มีการลิงก์กับ SXG อาจเป็นเพราะไม่เป็นไปตามข้อกําหนดของแคช SXG ซึ่งจะอธิบายในส่วนถัดไป

การส่งผ่านข้อมูล

เมื่อ Google Search จัดทำดัชนี SXG ระบบจะส่งสำเนาไปยัง Google SXG Cache ซึ่งจะตรวจสอบเทียบกับข้อกำหนดของแคช ส่วนขยาย Chrome จะแสดงผลดังนี้

หากเห็นเครื่องหมายถูก (✅) ให้ข้ามไปที่เพิ่มประสิทธิภาพ

หากไม่เป็นไปตามข้อกำหนด คุณจะเห็นเครื่องหมายกากบาท (❌) และข้อความเตือนที่ระบุสาเหตุดังนี้

ในกรณีนี้ หน้าเว็บจะทํางานเหมือนเดิมก่อนที่จะเปิดใช้ SXG Google จะลิงก์ไปยังหน้าในโฮสต์เดิมโดยไม่มีการอ่านล่วงหน้า SXG

ในกรณีที่สำเนาที่แคชไว้หมดอายุและกำลังดึงข้อมูลอีกครั้งในเบื้องหลัง คุณจะเห็นนาฬิกาทราย (⌛) ดังต่อไปนี้

เอกสารสำหรับนักพัฒนาซอฟต์แวร์ของ Google เกี่ยวกับ SXG ยังมีวิธีการการค้นหาแคชด้วยตนเองด้วย

เพิ่มประสิทธิภาพ

หากส่วนขยาย Chrome ของโปรแกรมตรวจสอบ SXG แสดงเครื่องหมายถูกทั้งหมด (✅) แสดงว่าคุณมี SXG ที่แสดงต่อผู้ใช้ได้ อ่านต่อเพื่อดูวิธีเพิ่มประสิทธิภาพหน้าเว็บเพื่อให้ได้การปรับปรุง LCP มากที่สุดจาก SXG

max-age

เมื่อ SXG หมดอายุ Google SXG Cache จะดึงสำเนาใหม่ในเบื้องหลัง ในระหว่างที่รอการดึงข้อมูล ระบบจะนำผู้ใช้ไปยังหน้าในโฮสต์เดิม ซึ่งไม่ใช่การดึงข้อมูลล่วงหน้า ยิ่งคุณตั้งค่า Cache-Control: max-age ไว้นานเท่าใด การดึงข้อมูลในเบื้องหลังก็จะยิ่งเกิดขึ้นน้อยลงเท่านั้น ดังนั้น LCP จึงจะลดลงจากการโหลดล่วงหน้าได้บ่อยขึ้น

ซึ่งถือเป็นการแลกเปลี่ยนระหว่างประสิทธิภาพกับความใหม่ และแคชช่วยให้เจ้าของเว็บไซต์ระบุอายุสูงสุดของ SXG ได้ตั้งแต่ 2 นาทีถึง 7 วันเพื่อให้เหมาะกับความต้องการเฉพาะของแต่ละหน้า จากประสบการณ์ที่เราได้รับ เราพบว่า

• max-age=86400 (1 วัน) ขึ้นไปให้ประสิทธิภาพที่ดี
• max-age=120 (2 นาที) ไม่

เราหวังว่าจะได้ทราบข้อมูลเพิ่มเติมเกี่ยวกับค่าที่อยู่ตรงกลางระหว่าง 2 ค่าดังกล่าวเมื่อศึกษาข้อมูลมากขึ้น

user-agent

มีอยู่ครั้งหนึ่งที่ฉันเห็นว่า LCP เพิ่มขึ้นเมื่อใช้ SXG ที่โหลดล่วงหน้า เราเรียกใช้ WebPageTest เพื่อเปรียบเทียบผลลัพธ์ค่ามัธยฐานแบบไม่มีและแบบใช้การอ่านล่วงหน้า SXG การคลิกหลังจากด้านล่าง

เราเห็นว่าการเรียกข้อมูลล่วงหน้าใช้งานได้ ระบบจะนำ HTML ออกจากเส้นทางที่สำคัญ ดังนั้นทรัพยากรย่อยทั้งหมดจึงโหลดได้เร็วขึ้น แต่ LCP หรือเส้นประสีเขียวนั้นเพิ่มขึ้นจาก 2 วินาทีเป็น 2.1 วินาที

เราได้ตรวจสอบแถบฟิล์มเพื่อวิเคราะห์ปัญหานี้ เราพบว่าหน้าเว็บแสดงผลใน SXG แตกต่างออกไป ใน HTML ธรรมดา Chrome ระบุว่า "องค์ประกอบที่ใหญ่ที่สุด" สำหรับ LCP คือบรรทัดแรก อย่างไรก็ตาม ในเวอร์ชัน SXG หน้าเว็บได้เพิ่มแบนเนอร์แบบ Lazy Load ซึ่งดันบรรทัดแรกให้อยู่ใต้ส่วนที่มีการแบ่งหน้า และทําให้องค์ประกอบใหม่ที่มีขนาดใหญ่ที่สุดคือกล่องโต้ตอบความยินยอมในการใช้คุกกี้แบบ Lazy Load ทุกอย่างแสดงผลเร็วขึ้นกว่าก่อน แต่การเปลี่ยนแปลงเลย์เอาต์ทําให้เมตริกรายงานช้าลง

ฉันเจาะลึกมากขึ้นและพบว่าเหตุผลที่เลย์เอาต์แตกต่างกันคือหน้าเว็บแตกต่างกัน User-Agent และมีข้อผิดพลาดในตรรกะ หน้าเว็บแสดงหน้าเดสก์ท็อปแม้ว่าส่วนหัวการ Crawl ของ SXG จะระบุเป็นอุปกรณ์เคลื่อนที่ หลังจากแก้ไขแล้ว เบราว์เซอร์ก็ระบุบรรทัดแรกของหน้าเว็บเป็นองค์ประกอบที่ใหญ่ที่สุดได้อย่างถูกต้องอีกครั้ง

เมื่อคลิก "หลังจาก" เราพบว่า LCP ที่ดึงข้อมูลล่วงหน้าลดลงเหลือ 1.3 วินาที

SXG เปิดใช้สำหรับอุปกรณ์ทุกรูปแบบ โปรดตรวจสอบว่าข้อใดข้อหนึ่งต่อไปนี้เป็นจริงเพื่อเตรียมพร้อม

• หน้าเว็บของคุณไม่ Vary โดย User-Agent (เช่น ใช้การออกแบบที่ตอบสนองตามอุปกรณ์หรือURL แยกต่างหากสำหรับอุปกรณ์เคลื่อนที่/เดสก์ท็อป)
• หากหน้าเว็บใช้การแสดงผลแบบไดนามิก ระบบจะใส่คำอธิบายประกอบว่าเหมาะกับอุปกรณ์เคลื่อนที่หรือเดสก์ท็อปเท่านั้นโดยใช้ <meta name=supported-media content=...>

ทรัพยากรย่อย

คุณใช้ SXG เพื่อดึงข้อมูลทรัพยากรย่อยล่วงหน้า (รวมถึงรูปภาพ) ไปพร้อมกับ HTML ได้ Cloudflare ASX จะสแกน HTML เพื่อหาองค์ประกอบ <link rel=preload> ต้นทางเดียวกัน (บุคคลที่หนึ่ง) และแปลงเป็นส่วนหัวลิงก์ที่เข้ากันได้กับ SXG ดูรายละเอียดได้ในซอร์สโค้ดที่นี่และที่นี่

หากการเรียกข้อมูลล่วงหน้าทำงาน คุณจะเห็นการเรียกข้อมูลล่วงหน้าเพิ่มเติมจาก Google Search ดังนี้

หากต้องการเพิ่มประสิทธิภาพสำหรับ LCP ให้ดูที่ Waterfall อย่างใกล้ชิด และดูว่าทรัพยากรใดอยู่ในเส้นทางสําคัญในการแสดงผลองค์ประกอบที่ใหญ่ที่สุด หากไม่สามารถโหลดล่วงหน้าได้ ให้พิจารณาว่านำออกจากเส้นทางที่สำคัญได้หรือไม่ โปรดระวังสคริปต์ที่ซ่อนหน้าเว็บไว้จนกว่าจะโหลดเสร็จ

แคช SXG ของ Google อนุญาตให้โหลดทรัพยากรย่อยล่วงหน้าได้สูงสุด 20 รายการ และ ASX ตรวจสอบว่าไม่เกินขีดจํากัดนี้ อย่างไรก็ตาม การเพิ่มการโหลดทรัพยากรย่อยล่วงหน้ามากเกินไปก็อาจมีความเสี่ยง เบราว์เซอร์จะใช้ทรัพยากรย่อยที่โหลดไว้ล่วงหน้าก็ต่อเมื่อโหลดทรัพยากรย่อยทั้งหมดเสร็จแล้ว เพื่อป้องกันการติดตามข้ามเว็บไซต์ ยิ่งมีทรัพยากรย่อยมากเท่าใด โอกาสที่ทรัพยากรย่อยทั้งหมดจะทำการโหลดล่วงหน้าเสร็จก่อนที่ผู้ใช้จะคลิกผ่านไปยังหน้าเว็บของคุณก็ยิ่งน้อยลงเท่านั้น

ขณะนี้โปรแกรมตรวจสอบ SXG ไม่ได้ตรวจสอบทรัพยากรย่อย หากต้องการแก้ไขข้อบกพร่อง ให้ใช้ curl หรือ dump-signedexchange ในระหว่างนี้

วัดระยะทาง

หลังจากเพิ่มประสิทธิภาพ LCP ภายใต้ WebPageTest แล้ว คุณควรวัดผลกระทบของการอ่านล่วงหน้า SXG ต่อประสิทธิภาพโดยรวมของเว็บไซต์

เมตริกฝั่งเซิร์ฟเวอร์

เมื่อวัดเมตริกฝั่งเซิร์ฟเวอร์ เช่น Time To First Byte (TTFB) โปรดทราบว่าเว็บไซต์จะแสดง SXG แก่ Crawler ที่ยอมรับรูปแบบเท่านั้น จํากัดการวัด TTFB ไว้เฉพาะคําขอที่มาจากผู้ใช้จริง ไม่ใช่บ็อต คุณอาจพบว่าการสร้าง SXG จะเพิ่ม TTFB สําหรับคําขอ Crawler แต่จะไม่ส่งผลต่อประสบการณ์ของผู้เข้าชม

เมตริกฝั่งไคลเอ็นต์

SXG ให้ประโยชน์ด้านความเร็วมากที่สุดสำหรับเมตริกฝั่งไคลเอ็นต์โดยเฉพาะ LCP เมื่อวัดผลลัพธ์ คุณก็เปิดใช้ Cloudflare ASX รอให้ Googlebot ทำการ Crawl อีกครั้ง รออีก 28 วันเพื่อให้มีการรวบรวมข้อมูล Core Web Vitals (CWV) แล้วดูตัวเลข CWV ใหม่ อย่างไรก็ตาม การเปลี่ยนแปลงอาจสังเกตได้ยากเมื่ออยู่ท่ามกลางการเปลี่ยนแปลงอื่นๆ ทั้งหมดในช่วงเวลานี้

แต่เราพบว่าการ "ซูมเข้า" การโหลดหน้าเว็บที่อาจได้รับผลกระทบและสรุปเป็น "SXG ส่งผลต่อยอดดูหน้าเว็บ X% ซึ่งปรับปรุง LCP ขึ้น Y มิลลิวินาทีที่เปอร์เซ็นไทล์ที่ 75" นั้นมีประโยชน์มากกว่า

ปัจจุบันการเรียกข้อมูล SXG ล่วงหน้าจะเกิดขึ้นภายใต้เงื่อนไขบางอย่างเท่านั้น ดังนี้

• เบราว์เซอร์ Chromium (เช่น Chrome หรือ Edge ยกเว้นใน iOS) เวอร์ชัน M98 ขึ้นไป
• Referer: google.com หรือโดเมนการค้นหาของ Google อื่นๆ (โปรดทราบว่าใน Google Analytics แท็กการอ้างอิงจะมีผลกับการดูหน้าเว็บทั้งหมดในเซสชัน ขณะที่การดึงข้อมูลล่วงหน้าของ SXG จะใช้กับการดูหน้าเว็บครั้งแรกซึ่งลิงก์จาก Google Search โดยตรงเท่านั้น)

อ่านส่วนการศึกษาร่วมสมัยเพื่อดูวิธีวัด "การดูหน้าเว็บ X%" และ "การปรับปรุง LCP ขึ้น Y มิลลิวินาที"

การศึกษาร่วมสมัย

เมื่อดูข้อมูลการตรวจสอบผู้ใช้จริง (RUM) คุณควรแยกการโหลดหน้าเว็บออกเป็น SXG และไม่ใช่ SXG เมื่อทําเช่นนั้น คุณต้องจํากัดชุดการโหลดหน้าเว็บที่จะดู เพื่อให้กลุ่มที่ไม่ใช่ SXG ตรงกับเงื่อนไขการมีสิทธิ์สําหรับ SXG เพื่อหลีกเลี่ยงการเลือกที่มีอคติ มิเช่นนั้น ข้อมูลทั้งหมดต่อไปนี้จะมีอยู่เฉพาะในชุดการโหลดหน้าเว็บที่ไม่ใช่ SXG ซึ่งอาจมี LCP ต่างกันโดยค่าเริ่มต้น

• อุปกรณ์ iOS: เนื่องจากความแตกต่างของฮาร์ดแวร์หรือความเร็วของเครือข่ายในหมู่ผู้ใช้ที่มีอุปกรณ์เหล่านี้
• เบราว์เซอร์ Chromium รุ่นเก่า: ด้วยเหตุผลเดียวกัน
• อุปกรณ์เดสก์ท็อป: ด้วยเหตุผลเดียวกัน หรือเพราะเลย์เอาต์หน้าเว็บทำให้ระบบเลือก "องค์ประกอบที่ใหญ่ที่สุด" อื่น
• การนำทางในเว็บไซต์เดียวกัน (ผู้เข้าชมที่ไปตามลิงก์ภายในเว็บไซต์): เนื่องจากผู้เข้าชมจะนำทรัพยากรย่อยที่แคชไว้จากการโหลดหน้าเว็บก่อนหน้ามาใช้ซ้ำได้

ใน Google Analytics (UA) ให้สร้างมิติข้อมูลที่กำหนดเอง 2 รายการซึ่งมีขอบเขตเป็น "Hit" โดยให้ชื่อรายการหนึ่งว่า "isSXG" และอีกรายการหนึ่งว่า "referrer" (มิติข้อมูล "แหล่งที่มา" ในตัวมีขอบเขตระดับเซสชัน จึงไม่ได้ยกเว้นการไปยังส่วนต่างๆ ในเว็บไซต์เดียวกัน)

สร้างกลุ่มเป้าหมายที่กําหนดเองชื่อ "กลุ่มควบคุมสมมติของ SXG" ด้วยตัวกรองต่อไปนี้ที่ทำงานร่วมกันแบบ AND

• referrer เริ่มต้นด้วย https://www.google.
• Browser ตรงทุกประการกับ Chrome
• Browser เวอร์ชันตรงกับนิพจน์ทั่วไป ^(9[8-9]|[0-9]{3})
• isSXG ตรงทุกประการกับ false

สร้างสําเนาของกลุ่มนี้ชื่อ "SXG" ยกเว้น isSXG จะตรงกับ true ทั้งหมด

ในเทมเพลตเว็บไซต์ ให้เพิ่มข้อมูลโค้ดต่อไปนี้เหนือข้อมูลโค้ด Google Analytics ไวยากรณ์พิเศษที่ ASX จะเปลี่ยน false เป็น true เมื่อสร้าง SXG

<script data-issxg-var>window.isSXG=false</script>

ปรับแต่งสคริปต์การรายงานของ Google Analytics ตามที่แนะนําเพื่อบันทึก LCP หากคุณใช้ gtag.js ให้แก้ไขคําสั่ง 'config' เพื่อตั้งค่ามิติข้อมูลที่กำหนดเอง (แทนที่ 'dimension1' และ 'dimension2' ด้วยชื่อที่ Google Analytics แนะนำให้ใช้)

gtag('config', 'YOUR_TRACKING_ID', {
  'dimension1': String(isSXG),
  'dimension2': document.referrer,
});

หากคุณใช้ analytics.js ให้แก้ไขคําสั่ง 'create' ตามที่ระบุไว้ที่นี่

หลังจากรอ 2-3 วันเพื่อรวบรวมข้อมูลบางส่วน ให้ไปที่รายงานเหตุการณ์ของ Google Analytics แล้วเพิ่มการเจาะลึกสำหรับกลุ่ม SXG ข้อมูลนี้ควรกรอกค่า X สําหรับ "SXG ส่งผลต่อจำนวนการดูหน้าเว็บ X%"

สุดท้าย ให้ไปที่รายงาน Web Vitals เลือก "เลือกกลุ่ม" แล้วเลือก "กลุ่มเปรียบเทียบของ SXG" และ "SXG"

คลิก "ส่ง" แล้วคุณจะเห็นการกระจาย LCP ของทั้ง 2 กลุ่ม วิธีนี้จะเติมค่า Y ลงใน "การปรับปรุง LCP ทุกๆ Y มิลลิวินาทีที่เปอร์เซ็นไทล์ที่ 75" ดังนี้

คำเตือน

เมื่อคุณใช้ตัวกรองข้างต้นทั้งหมดแล้ว การโหลดหน้าเว็บที่โต้แย้งตามจริงของ SXG ควรประกอบด้วยข้อมูลต่อไปนี้

• แคชขาดหายไป: หาก Google SXG Cache ไม่มีสำเนาใหม่ของ SXG สำหรับ URL ที่ระบุ ระบบจะเปลี่ยนเส้นทางไปยัง URL ต้นฉบับที่เว็บไซต์ของคุณ
• ผลการค้นหาประเภทอื่นๆ: ปัจจุบัน Google Search รองรับเฉพาะ SXG สำหรับผลการค้นหาบนเว็บมาตรฐานและอีก 2-3 ประเภท ส่วนรายการอื่นๆ เช่น ตัวอย่างข้อมูลแนะนำและภาพสไลด์เรื่องเด่น จะลิงก์ไปยัง URL ต้นฉบับที่เว็บไซต์ของคุณ
• URL ที่ไม่มีสิทธิ์: หากหน้าเว็บบางหน้าในเว็บไซต์ไม่มีสิทธิ์ใช้ SXG (เช่น เนื่องจากแคชไม่ได้) หน้าเหล่านั้นอาจปรากฏในชุดนี้

อาจมีความเอนเอียงระหว่างการโหลดหน้าเว็บ SXG และการโหลดหน้าเว็บที่ไม่ใช่ SXG ชุดข้างต้น แต่ขนาดควรน้อยกว่าความเอนเอียงที่กล่าวถึงด้านบนของหัวข้อการศึกษาร่วมสมัย เช่น หน้าเว็บที่แคชไม่ได้อาจช้ากว่าหรือเร็วกว่าหน้าเว็บที่แคชได้ หากสงสัยว่านี่อาจเป็นปัญหา ให้พิจารณาดูข้อมูลที่จํากัดเฉพาะ URL ที่มีสิทธิ์ SXG เพื่อดูว่าผลลัพธ์ตรงกับการศึกษาโดยรวมหรือไม่

หากเว็บไซต์มีหน้า AMP บางหน้า หน้าเหล่านั้นอาจไม่ได้รับการปรับปรุงประสิทธิภาพจากการเปิดใช้ SXG เนื่องจากหน้าดังกล่าวสามารถรับข้อมูลล่วงหน้าจาก Google Search อยู่แล้ว ลองเพิ่มตัวกรองเพื่อยกเว้นหน้าเหล่านั้น เพื่อ "ซูมเข้า" ไปยังการเปลี่ยนแปลงที่เกี่ยวข้องเพิ่มเติม

สุดท้ายนี้ แม้แต่การจัดการกับอคติในการเลือกทั้งหมด ก็ยังมีความเสี่ยงที่อคติในการรอดชีวิตจะทำให้การปรับปรุง LCP มีประสิทธิภาพลดลงในสถิติของ RUM บทความนี้อธิบายความเสี่ยงดังกล่าวได้เป็นอย่างดี และแนะนำให้ดูเมตริกการละทิ้งกลางคันเพื่อตรวจหาว่าสิ่งนี้เกิดขึ้นหรือไม่

การศึกษาก่อน/หลัง

หากต้องการยืนยันผลลัพธ์จากการศึกษาในปัจจุบัน คุณอาจต้องเปรียบเทียบ LCP ก่อนและหลังเปิดใช้ SXG อย่าจำกัดการดูหน้าเว็บของ SXG เพื่อขจัดความลำเอียงที่อาจเกิดขึ้นซึ่งระบุไว้ข้างต้น ให้ดูที่ผลการค้นหาที่มีสิทธิ์ SXG แทน ซึ่งก็คือคําจํากัดความกลุ่มด้านบนนี้ แต่ไม่มีข้อจํากัด isSXG

โปรดทราบว่า Google Search อาจใช้เวลาถึง 2-3 สัปดาห์ในการ Crawl หน้าทั้งหมดในเว็บไซต์อีกครั้งเพื่อระบุว่ามีการเปิดใช้ SXG ให้กับหน้าเหล่านั้นแล้ว ในช่วงหลายสัปดาห์ดังกล่าว อาจมีอคติอื่นๆ ที่อาจเกิดขึ้น ดังนี้

• เบราว์เซอร์รุ่นใหม่หรือการปรับปรุงฮาร์ดแวร์ของผู้ใช้อาจทำให้หน้าเว็บโหลดเร็วขึ้น
• เหตุการณ์สำคัญ เช่น วันหยุด อาจบิดเบือนจำนวนการเข้าชมจากปกติได้

นอกจากนี้ คุณควรดู LCP เปอร์เซ็นไทล์ 75 โดยรวมก่อนและหลังเพื่อยืนยันการศึกษาข้างต้น การศึกษาประชากรบางส่วนไม่ได้บอกเราเกี่ยวกับประชากรโดยรวมเสมอไป เช่น สมมติว่า SXG ปรับปรุงการโหลดหน้าเว็บ 10% เร็วขึ้น 800 มิลลิวินาที

• หากหน้าเว็บเหล่านี้เป็นหน้าเว็บที่โหลดเร็วที่สุด 10% อยู่แล้ว ก็จะไม่ส่งผลต่อเปอร์เซ็นไทล์ที่ 75 เลย
• หากหน้าเว็บโหลดช้าที่สุด 10% แต่ช้ากว่า LCP เปอร์เซ็นไทล์ที่ 75 ไปมากกว่า 800 มิลลิวินาที ก็จะไม่ส่งผลต่อเปอร์เซ็นไทล์ที่ 75 เลย

เหตุการณ์เหล่านี้เป็นตัวอย่างที่รุนแรง ซึ่งอาจไม่สะท้อนให้เห็นถึงความเป็นจริง แต่ก็หวังว่าจะสามารถอธิบายปัญหาได้ชัดเจนขึ้น ในทางปฏิบัติ SXG มีแนวโน้มที่จะส่งผลต่อเปอร์เซ็นต์ไทล์ที่ 75 สำหรับเว็บไซต์ส่วนใหญ่ การนำทางข้ามเว็บไซต์มักจะช้าที่สุด และการปรับปรุงจากการอ่านล่วงหน้ามักจะมีมาก

เลือกไม่ใช้ URL บางรายการ

ข้อสุดท้าย วิธีหนึ่งในการเปรียบเทียบประสิทธิภาพของ SXG คือการปิดใช้ SXG สำหรับ URL บางส่วนในเว็บไซต์ของคุณ เช่น คุณอาจตั้งค่าส่วนหัว CDN-Cache-Control: no-store เพื่อไม่ให้ Cloudflare ASX สร้าง SXG เราขอแนะนำว่าอย่าทำเช่นนั้น

และอาจมีความเสี่ยงสูงกว่าวิธีการศึกษาอื่นๆ ในเรื่องของการเลือกตัวอย่าง ตัวอย่างเช่น อาจสร้างความแตกต่างได้อย่างมากไม่ว่าจะเลือกหน้าแรกของเว็บไซต์หรือ URL ที่ได้รับความนิยมคล้ายๆ กันไว้ในกลุ่มควบคุมหรือกลุ่มทดสอบ

การศึกษาการยกเว้น

วิธีที่เหมาะสมในการวัดผลกระทบคือ การศึกษาการยกเว้น ขออภัย คุณทำการทดสอบประเภทนี้ไม่ได้ในขณะนี้ เราวางแผนที่จะเพิ่มการรองรับการทดสอบดังกล่าวในอนาคต

การศึกษาการระงับชั่วคราวมีพร็อพเพอร์ตี้ต่อไปนี้

• ในกลุ่มทดสอบ เราจะ "ระงับ" การเข้าชมหน้าเว็บบางส่วนแบบสุ่มซึ่งควรจะเป็น SXG และแสดงเป็นหน้าเว็บที่ไม่ใช่ SXG แทน ซึ่งช่วยให้เปรียบเทียบ "เทียบเท่ากัน" ระหว่างผู้ใช้ อุปกรณ์ สถานการณ์ และหน้าเว็บที่เทียบเท่าได้
• การดูหน้าเว็บที่ถูกระงับ (หรือที่เรียกว่าการเปรียบเทียบกับกลุ่มควบคุม) จะมีการติดป้ายกํากับไว้เช่นนั้นในข้อมูลวิเคราะห์ ซึ่งช่วยให้เห็นมุมมองข้อมูลที่ "ซูมเข้า" ซึ่งเราสามารถเปรียบเทียบการโหลดหน้า SXG ในกลุ่มควบคุมกับกลุ่มเปรียบเทียบของ SXG ในการทดสอบ ซึ่งจะช่วยลดสัญญาณรบกวนจากการโหลดหน้าเว็บอื่นๆ ที่จะไม่ได้รับผลกระทบจากการอ่านล่วงหน้าของ SXG

วิธีนี้จะช่วยขจัดแหล่งที่มาที่เป็นไปได้ของการเลือกที่มีอคติตามที่กล่าวไว้ข้างต้น แต่จะไม่ช่วยลดความเสี่ยงของอคติในการอยู่รอดของ LCP พร็อพเพอร์ตี้ทั้ง 2 รายการนี้ต้องเปิดใช้เบราว์เซอร์หรือ URL ที่มา

บทสรุป

ในที่สุด เยอะมาก หวังว่าฟีเจอร์นี้จะทำให้คุณเห็นภาพที่สมบูรณ์มากขึ้นเกี่ยวกับวิธีการทดสอบประสิทธิภาพ SXG ในการทดสอบในห้องทดลอง วิธีเพิ่มประสิทธิภาพในลูปความคิดเห็นแบบกระชับด้วยการทดสอบในห้องทดลอง และสุดท้ายคือวิธีวัดประสิทธิภาพในโลกแห่งความเป็นจริง การทำตามขั้นตอนทั้งหมดนี้จะช่วยให้คุณได้รับประโยชน์สูงสุดจาก SXG และช่วยให้ SXG ส่งผลดีต่อเว็บไซต์และผู้ใช้

หากมีคำแนะนำเพิ่มเติมเกี่ยวกับวิธีบันทึกประสิทธิภาพ SXG โปรดแจ้งให้เราทราบ รายงานข้อบกพร่องใน developer.chrome.com พร้อมการปรับปรุงที่แนะนำ

ดูข้อมูลเพิ่มเติมเกี่ยวกับ Signed Exchange ได้ที่เอกสารประกอบของ web.dev และเอกสารประกอบของ Google Search