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

วิธีวัดและเพิ่มประสิทธิภาพ Signed Exchange เพื่อให้ได้รับการปรับปรุงมากที่สุด

Devin Mullins
Devin Mullins
X GitHub

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

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

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

แผงการตั้งค่า Cloudflare ที่มีช่องทำเครื่องหมายเพื่อเปิดใช้ Signed Exchange อัตโนมัติ

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

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

บทนำ

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

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

หากการยืนยันไม่สำเร็จ เบราว์เซอร์จะเลิกใช้ SXG และดึง URL ที่ลงนามแทน หากการยืนยันสำเร็จ เบราว์เซอร์จะโหลดการตอบกลับที่ลงชื่อ โดยปฏิบัติเสมือนว่ามาจาก URL ที่ลงนามโดยตรง ซึ่งจะทำให้สามารถโฮสต์ 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 ของแคช

โปรแกรมตรวจสอบ SXG แสดงข้อมูลแคชที่มี URL

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

ประวัติการทดสอบที่มีการเลือกการทดสอบ 2 รายการและไฮไลต์ปุ่มเปรียบเทียบ

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

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

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

Waterfall เครือข่ายที่ไม่มีการดึงข้อมูล SXG ล่วงหน้า แถวแรกคือการดึงข้อมูล HTML ซึ่งใช้เวลา 1050 มิลลิวินาที Waterfall เครือข่ายที่มีการดึงข้อมูล SXG ล่วงหน้า มีการดึงข้อมูล HTML ล่วงหน้า ซึ่งทำให้ทรัพยากรย่อยทั้งหมดเริ่มดึงข้อมูลได้เร็วขึ้น 1050 มิลลิวินาที

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

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

การเผยแพร่

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

วันที่ โปรแกรมตรวจสอบ SXG แสดงเครื่องหมายถูก (✅) และประเภทเนื้อหาของแอปพลิเคชัน/Signed-Exchange;v=b3

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

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

โปรแกรมตรวจสอบ SXG แสดงเครื่องหมายกากบาท (❌) และประเภทเนื้อหาของข้อความ/html

หากเปิดใช้ 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 โดยไม่ต้องมีข้อมูลเข้าสู่ระบบของผู้ใช้ และอาจให้บริการแก่ผู้เข้าชมหลายราย หากคุณแสดง HTML ที่แตกต่างกันแก่ผู้ใช้ที่แตกต่างกันตามคุกกี้ ผู้ใช้อาจเห็นประสบการณ์ที่ไม่ถูกต้อง เช่น มุมมองออกจากระบบ

หรือใช้เครื่องมือ เช่น curl นอกเหนือจากส่วนขยาย Chrome โดยทำดังนี้

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

หรือ dump-signedexchange:

dump-signedexchange -verify -uri $URL

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

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

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

ผลการค้นหาของ Google Search ที่มีเครื่องมือสำหรับนักพัฒนาเว็บแสดงแท็ก Anchor ที่ชี้ไปยัง webpkgcache.com

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

ผลการค้นหาของ Google Search ที่มีเครื่องมือสำหรับนักพัฒนาเว็บแสดงลิงก์ที่มี rel=prefetch สำหรับ webpkgcache.com

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

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

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

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

เครื่องมือตรวจสอบ URL ของ Search Console ให้คลิก &quot;ดูหน้าเว็บที่รวบรวมข้อมูล&quot; แล้วคลิก &quot;ข้อมูลเพิ่มเติม&quot;

การมีส่วนหัว digest: mi-sha256-03=... แสดงว่า Google รวบรวมข้อมูลเวอร์ชัน SXG เรียบร้อยแล้ว

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

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

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

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

โปรแกรมตรวจสอบ SXG แสดงเครื่องหมายถูก (✅) และไม่มีข้อความเตือน

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

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

โปรแกรมตรวจสอบ SXG แสดงเครื่องหมายกากบาท (❌) และข้อความเตือนว่า

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

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

โปรแกรมตรวจสอบ SXG แสดงนาฬิกาทราย (⌛) และไม่มีข้อความเตือน

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

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

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

อายุสูงสุด

เมื่อ 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 คลิกหลังจากด้านล่าง

Waterfall เครือข่ายที่ไม่มีการดึงข้อมูล SXG ล่วงหน้า LCP เท่ากับ 2 วินาที Waterfall เครือข่ายที่มีการดึงข้อมูล SXG ล่วงหน้า มีการดึงข้อมูล HTML ล่วงหน้า ซึ่งทำให้ทรัพยากรย่อยทั้งหมดเริ่มดึงข้อมูลได้เร็วขึ้น 800 มิลลิวินาที แต่ LCP คือ 2.1 วินาที

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

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

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

ตอนนี้เมื่อคลิก "หลัง" คุณจะเห็นว่า LCP ที่ดึงข้อมูลล่วงหน้าลดลงเหลือ 1.3 วินาที

Waterfall เครือข่ายที่ไม่มีการดึงข้อมูล SXG ล่วงหน้า LCP เท่ากับ 2 วินาที Waterfall เครือข่ายที่มีการดึงข้อมูล SXG ล่วงหน้า LCP เท่ากับ 1.3 วินาที

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

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

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

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

ผลการค้นหาของ Google Search ที่มีแท็บเครือข่ายเครื่องมือสำหรับนักพัฒนาเว็บ แสดงการดึงข้อมูลล่วงหน้าของ /sub/.../image.jpg

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

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

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

วัดระยะทาง

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

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

เมื่อวัดเมตริกฝั่งเซิร์ฟเวอร์ เช่น Time to First Byte (TTFB) โปรดทราบว่าเว็บไซต์ของคุณแสดงเฉพาะ SXG ต่อโปรแกรมรวบรวมข้อมูลที่ยอมรับรูปแบบนี้เท่านั้น จำกัดการวัดผล 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" (มิติข้อมูล "แหล่งที่มา" ในตัวมีขอบเขตเซสชัน จึงไม่ยกเว้นการไปยังส่วนต่างๆ ในเว็บไซต์เดียวกัน)

ตัวแก้ไขมิติข้อมูล Google Analytics พร้อมการตั้งค่าที่แนะนำ

สร้างกลุ่มที่กําหนดเองชื่อ "SXGcounterffinal" โดยใช้ตัวกรองต่อไปนี้ AND รวมเข้าด้วยกัน

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

สร้างสำเนาของกลุ่มนี้ ชื่อว่า "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% ของการดูหน้าเว็บ" ดังนี้

รายงานเหตุการณ์ Google Analytics ที่มีกลุ่ม SXG แสดงเหตุการณ์ที่ไม่ซ้ำ 12.5%

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

รายงาน Web Vitals ที่มีตัวเลือกการโต้แย้งเกี่ยวกับ SXG และ SXG

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

รายงาน Web Vitals แสดงการกระจาย LCP สำหรับข้อมูลที่ขัดแย้งของ SXG และ SXG

คำเตือน

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

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

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

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

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

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

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

โปรดทราบว่า Google Search อาจใช้เวลาหลายสัปดาห์ในการทำการ 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 ที่ได้รับความนิยมคล้ายๆ กันนั้นไว้ในกลุ่มควบคุมหรือกลุ่มทดสอบ

การศึกษา Holdback

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

การศึกษาการยกเว้นมีคุณสมบัติต่อไปนี้

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

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

บทสรุป

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

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

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