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

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

Devin Mullins

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

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

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

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

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

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

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

เกริ่นนำ

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 เพื่อให้ผู้ใช้ดูลิงก์ดังกล่าวขณะออฟไลน์ได้ ดูรายการกรณีการใช้งานที่เป็นไปได้จำนวนมากขึ้น

วิเคราะห์

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

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

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

• ไปที่ WebPageTest และลงชื่อเข้าใช้ การลงชื่อเข้าใช้จะบันทึกประวัติการทดสอบไว้เพื่อให้เปรียบเทียบได้ง่ายขึ้นในภายหลัง
• ป้อน URL ที่คุณต้องการทดสอบ
• ไปที่การกำหนดค่าขั้นสูง (คุณจำเป็นต้องมีการกำหนดค่าขั้นสูงสำหรับการทดสอบ 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 สำหรับแต่ละฝั่งของการเปรียบเทียบ (ค่าเริ่มต้นคือค่ามัธยฐานตามดัชนีความเร็ว)

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

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

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

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

การเผยแพร่

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

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

ส่วนขยายนี้จะดึงข้อมูล 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 ในกรณีเหล่านี้เนื่องจากอาจมีแคชและนำกลับมาใช้ซ้ำสำหรับการเข้าชมหลายครั้งและผู้เข้าชมหลายราย

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

หมายเหตุ: ดูรายละเอียดเพิ่มเติมได้ในโค้ด ASX เช่น ส่วนหัวการควบคุมแคชจะตรวจสอบโดยโค้ดที่กำหนดว่าจะลงชื่อเมื่อใดและระยะเวลาการเซ็นชื่อ ระบบจะนำส่วนหัวอื่นๆ ออกก่อนที่จะลงนามด้วยการกำหนดค่านี้หรือด้วยโค้ดนี้ ส่วนหัวอื่นๆ จะป้องกันไม่ให้มีการลงชื่อหากไม่มีการถูกตัดออก

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

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

หรือคุณจะใช้เครื่องมืออย่างเช่น 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 Search เพื่อค้นหาหน้าเว็บของคุณ หากได้รับการจัดทำดัชนีเป็น 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 ยังอธิบายวิธีการค้นหาแคชด้วยตนเองอีกด้วย

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

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

max-age

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

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

• max-age=86400 (1 วัน) หรือนานกว่านั้นทำงานได้อย่างดีเพื่อประสิทธิภาพ
• max-age=120 (2 นาที) ไม่

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

หมายเหตุ: เราวางแผนที่จะทำให้การเปลี่ยนแปลงนี้ง่ายขึ้นในอนาคตโดยการเพิ่ม API การล้างแคช โดยจะประกาศในประกาศเกี่ยวกับการแสดงเว็บแพ็กเกจ

user-agent

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

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

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

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

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

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

วัดระยะทาง

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

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

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

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

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

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

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

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

หมายเหตุ: Google Search มีแผนที่จะขยายบริบทที่อาจทำให้การดึงข้อมูล SXG ล่วงหน้าเกิดขึ้นได้ ซึ่งรวมถึงระบบปฏิบัติการในเดสก์ท็อป และอื่นๆ ซึ่งอาจเพิ่มขึ้น X% เมื่อเวลาผ่านไป และหมายความว่าคุณอาจต้องอัปเดตเมตริกเพื่อรองรับการเปลี่ยนแปลง ในกรณีนี้ ควรประกาศในประกาศเกี่ยวกับการจัดแพ็กเกจ

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

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

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

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

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

สร้างกลุ่มที่กำหนดเองชื่อ "SXGcounterftrue" โดยใช้ตัวกรองต่อไปนี้ "และ" รวมกัน

• 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 เลือก "เลือกกลุ่ม" แล้วเลือก "SXGCounterftrue" และ "SXG"

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

คำเตือน

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

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

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

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

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

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

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

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

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

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

• หากหน้าเว็บเหล่านี้โหลดได้เร็วที่สุด 10% อยู่แล้ว ก็จะไม่มีผลต่อเปอร์เซ็นไทล์ที่ 75 แต่อย่างใด
• หากหน้าเว็บโหลดช้าที่สุด 10% ในช่วงเริ่มต้น แต่ช้ากว่า 800 มิลลิวินาที เมื่อเทียบกับ LCP เปอร์เซ็นไทล์ที่ 75 ก็จะไม่ส่งผลต่อเปอร์เซ็นไทล์ที่ 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