วิธีวัดผลและเพิ่มประสิทธิภาพ Signed Exchange เพื่อให้ได้รับประโยชน์สูงสุดจาก Exchange ดังกล่าว
Signed Exchange (SXG) เป็นวิธีการปรับปรุงความเร็วหน้าเว็บ ซึ่งหลักๆ แล้วคือ Largest Contentful Paint (LCP) เมื่ออ้างอิงเว็บไซต์ (ปัจจุบันคือ Google Search) ลิงก์ใดๆ ไปยังหน้าเว็บหนึ่งๆ ผู้ใช้จะดึงข้อมูลดังกล่าวล่วงหน้าลงในแคชของเบราว์เซอร์ก่อนที่ผู้ใช้จะคลิกลิงก์ดังกล่าว
คุณสามารถทำให้หน้าเว็บที่เมื่อดึงข้อมูลล่วงหน้าไม่จำเป็นต้องใช้เครือข่ายในเส้นทางที่สำคัญในการแสดงผลหน้าเว็บ สำหรับการเชื่อมต่อ 4G การโหลดหน้าเว็บนี้จะเปลี่ยนจาก 2.8 วินาทีถึง 0.9 วินาที (ส่วน 0.9 วินาทีที่เหลือ ส่วนใหญ่แล้วเกิดจากการใช้งาน CPU)
คนส่วนใหญ่ที่เผยแพร่ SXG ในปัจจุบันใช้ฟีเจอร์ Automatic Signed Exchanges (ASX) ของ Cloudflare (แม้ว่าจะมีตัวเลือกโอเพนซอร์สก็ตาม)
![แผงการตั้งค่า Cloudflare ที่มีช่องทำเครื่องหมายเพื่อเปิดใช้ Signed Exchange โดยอัตโนมัติ](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/cloudflare-settings-panel-5a154cefaeee.png?authuser=5&hl=th)
ในหลายกรณี การทำเครื่องหมายในช่องเพื่อเปิดใช้ฟีเจอร์นี้ก็เพียงพอสำหรับการปรับปรุงที่สำคัญดังที่แสดงไว้ด้านบน บางครั้ง อาจมีอีก 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 ในสภาวะที่ทำซ้ำ คุณใช้ WebPageTest เพื่อเปรียบเทียบ Waterfall และ LCP ที่มีและไม่มีการดึงข้อมูลล่วงหน้าของ SXG ได้
สร้างการทดสอบโดยไม่มี 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 ของแคช:
![โปรแกรมตรวจสอบ SXG แสดงข้อมูลแคช รวมถึง URL](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/sxg-validator-showing-cac-cd00f49c76676.png?authuser=5&hl=th)
เมื่อการทดสอบเหล่านี้เสร็จสมบูรณ์แล้ว ให้ไปที่ประวัติการทดสอบ เลือกการทดสอบ 2 รายการ แล้วคลิกเปรียบเทียบ
![ประวัติการทดสอบที่เลือกการทดสอบ 2 รายการและไฮไลต์ปุ่ม "เปรียบเทียบ"](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/test-history-two-tests-c-c2bdb42542715.png?authuser=5&hl=th)
ใส่ &medianMetric=LCP
ต่อท้าย URL เปรียบเทียบเพื่อให้ WebPageTest เลือกการเรียกใช้ที่ค่ามัธยฐาน LCP สำหรับแต่ละฝั่งของการเปรียบเทียบ (ค่าเริ่มต้นคือค่ามัธยฐานตามดัชนีความเร็ว)
หากต้องการเปรียบเทียบ Waterfall ให้ขยายส่วนความทึบแสงของน้ำตกและลากแถบเลื่อน หากต้องการดูวิดีโอ ให้คลิกปรับการตั้งค่าแถบฟิล์ม เลื่อนลงภายในกล่องโต้ตอบนั้น แล้วคลิกดูวิดีโอ
หากการดึงข้อมูล SXG ล่วงหน้าประสบความสำเร็จ คุณจะเห็นว่า Waterfall "มี SXG" ไม่รวมแถวสำหรับ HTML และการดึงข้อมูลสำหรับทรัพยากรย่อยจะเริ่มต้นเร็วกว่า ตัวอย่างเช่น เปรียบเทียบ "ก่อน" และ "หลัง" ที่นี่
แก้ไขข้อบกพร่อง
หาก WebPageTest แสดงให้เห็นว่ามีการดึงข้อมูล SXG ล่วงหน้า แสดงว่าการดำเนินการสำเร็จในทุกขั้นตอนของไปป์ไลน์ คุณสามารถข้ามไปที่ส่วนเพิ่มประสิทธิภาพเพื่อดูวิธีปรับปรุง LCP เพิ่มเติมได้ ไม่เช่นนั้น คุณจะต้องหาว่ากระบวนการดังกล่าวล้มเหลวในส่วนใดและเพราะเหตุใด อ่านต่อเพื่อเรียนรู้วิธีการ
การเผยแพร่
ตรวจสอบว่าระบบสร้างหน้าเว็บเป็น SXG โดยจะต้องแอบอ้างเป็น Crawler วิธีที่ง่ายที่สุดคือการใช้ส่วนขยาย Chrome ของโปรแกรมตรวจสอบ SXG
![โปรแกรมตรวจสอบ SXG ที่แสดงเครื่องหมายถูก (✅) และประเภทเนื้อหาของแอปพลิเคชัน/signed-Exchange;v=b3](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/sxg-validator-showing-ch-663e5b3cc9f67.png?authuser=5&hl=th)
ส่วนขยายนี้จะดึงข้อมูล URL ปัจจุบันที่มีส่วนหัวของคำขอ Accept
ที่ระบุว่าต้องการเวอร์ชัน SXG หากคุณเห็นเครื่องหมายถูก (✅) ข้างต้นทาง แสดงว่ามีการส่งคืน SXG แล้ว ให้ข้ามไปยังส่วนการจัดทําดัชนี
หากเห็นเครื่องหมายกากบาท (❌) แสดงว่าระบบไม่ได้ส่งคืน SXG ดังนี้
![โปรแกรมตรวจสอบ SXG ที่แสดงเครื่องหมายกากบาท (❌) และประเภทเนื้อหาของข้อความ/html](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/sxg-validator-showing-cr-555ac59fdd27f.png?authuser=5&hl=th)
หากเปิดใช้ 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
อีกสาเหตุหนึ่งที่เป็นไปได้คือการมีส่วนหัวการตอบกลับ 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 Search เพื่อค้นหาหน้าเว็บของคุณ หากได้รับการจัดทำดัชนีเป็น SXG ลิงก์ที่ไปยังหน้าเว็บของคุณของ Google จะมี data-sxg-url
ที่ชี้ไปยังสำเนาของ webpkgcache.com ดังนี้
![ผลการค้นหาของ Google Search ที่มีเครื่องมือสำหรับนักพัฒนาเว็บแสดงแท็ก Anchor ที่ชี้ไปยัง webpkgcache.com](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/google-search-results-de-57d0db7b9c20a.png?authuser=5&hl=th)
หาก Google Search คิดว่าผู้ใช้มีแนวโน้มที่จะคลิกผลการค้นหา ก็จะดึงข้อมูลนั้นล่วงหน้าด้วย
![ผลการค้นหาของ Google Search ที่มีเครื่องมือสำหรับนักพัฒนาเว็บแสดงลิงก์ที่มี rel=prefetch สำหรับ webpkgcache.com](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/google-search-results-de-3127d5a0a1ef9.png?authuser=5&hl=th)
องค์ประกอบ <link>
สั่งให้เบราว์เซอร์ดาวน์โหลด SXG ลงในแคชที่ดึงข้อมูลล่วงหน้า เมื่อผู้ใช้คลิกองค์ประกอบ <a>
เบราว์เซอร์จะใช้ SXG ที่แคชไว้ดังกล่าวเพื่อแสดงผลหน้าเว็บ
นอกจากนี้ คุณดูหลักฐานการดึงข้อมูลล่วงหน้าได้โดยไปที่แท็บ "เครือข่าย" ในเครื่องมือสำหรับนักพัฒนาเว็บ และค้นหา URL ที่มี webpkgcache
หาก <a>
ชี้ไปยัง webpkgcache.com แสดงว่าการจัดทำดัชนีของ Google Search สำหรับ Signed Exchange ทำงานอยู่ คุณสามารถข้ามไปยังส่วนการส่งผ่านข้อมูลได้
มิเช่นนั้น อาจเป็นเพราะ Google ยังไม่ได้ทำการ Crawl หน้าเว็บอีกครั้งเนื่องจากคุณได้เปิดใช้ SXG ลองใช้เครื่องมือตรวจสอบ URL ของ Google Search Console ดังนี้
![เครื่องมือตรวจสอบ URL ของ Search Console โดยคลิก "ดูหน้าที่ทำการ Crawl" แล้วคลิก "ข้อมูลเพิ่มเติม"](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/search-console-url-inspec-3f054b4eeeef4.png?authuser=5&hl=th)
การมีส่วนหัว digest: mi-sha256-03=...
บ่งบอกว่า Google ทำการ Crawl เวอร์ชัน SXG สำเร็จ
หากไม่มีส่วนหัว digest
อาจเป็นไปได้ว่าระบบไม่ได้ส่ง SXG ไปยัง Googlebot หรือดัชนีไม่ได้รับการอัปเดตนับตั้งแต่ที่คุณเปิดใช้ SXG
หากมีการ Crawl SXG สำเร็จ แต่ยังคงไม่ลิงก์กับ SXG อาจเป็นเพราะไม่เป็นไปตามข้อกําหนดของแคช SXG ซึ่งจะมีการอธิบายในส่วนถัดไป
การส่งผ่านข้อมูล
เมื่อ Google Search จัดทำดัชนี SXG ก็จะส่งสำเนาไปยัง Google SXG Cache ซึ่งจะตรวจสอบตามข้อกำหนดของแคช ส่วนขยาย Chrome จะแสดงผลดังนี้
![โปรแกรมตรวจสอบ SXG แสดงเครื่องหมายถูก (✅) และไม่มีข้อความเตือน](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/sxg-validator-showing-ch-1282069b578ae.png?authuser=5&hl=th)
หากเห็นเครื่องหมายถูก (✅) ให้ข้ามไปที่เพิ่มประสิทธิภาพ
หากไม่เป็นไปตามข้อกำหนด คุณจะเห็นเครื่องหมายกากบาท (❌) และข้อความเตือนที่ระบุสาเหตุ
![โปรแกรมตรวจสอบ SXG แสดงเครื่องหมายกากบาท (❌) และข้อความเตือนว่า](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/sxg-validator-showing-cr-69db2da79bd7b.png?authuser=5&hl=th)
ในเหตุการณ์นี้ หน้าเว็บจะทำงานเหมือนเดิมก่อนที่จะเปิดใช้ SXG Google จะลิงก์ไปยังหน้าในโฮสต์เดิมโดยไม่มีการดึงข้อมูล SXG ล่วงหน้า
ในกรณีที่สำเนาที่แคชไว้หมดอายุและดึงข้อมูลอีกครั้งในเบื้องหลัง คุณจะเห็นนาฬิกาทราย (⌛)
![โปรแกรมตรวจสอบ SXG แสดงนาฬิกาทราย (⌛) และไม่มีข้อความเตือน](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/sxg-validator-showing-ho-dcbdc4694a3f.png?authuser=5&hl=th)
นอกจากนี้ เอกสารของนักพัฒนาซอฟต์แวร์ 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 รายการนี้ ขณะที่เราศึกษาข้อมูลนี้เพิ่มเติม
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 ดังนี้
![ผลการค้นหาของ Google Search ที่มีแท็บเครือข่ายเครื่องมือสำหรับนักพัฒนาเว็บ ซึ่งแสดงการดึงข้อมูลล่วงหน้าของ /sub/.../image.jpg](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/google-search-results-de-50436b3876448.png?authuser=5&hl=th)
หากต้องการเพิ่มประสิทธิภาพ LCP ให้ตรวจสอบ Waterfall อย่างละเอียด และหาทรัพยากรที่อยู่บนเส้นทางวิกฤติในการแสดงผลองค์ประกอบที่ใหญ่ที่สุด หากดึงข้อมูลล่วงหน้าไม่ได้ ให้ลองพิจารณาว่าจะออกจากเส้นทางวิกฤติได้หรือไม่ มองหาสคริปต์ที่ซ่อนหน้าเว็บไว้จนกว่าจะโหลดเสร็จ
แคช SXG ของ Google ช่วยให้โหลดทรัพยากรย่อยล่วงหน้าได้สูงสุด 20 รายการ และ ASX นั้นรับประกันว่าจะไม่เกินขีดจำกัดนี้ แต่ก็มีความเสี่ยงในการเพิ่มทรัพยากรย่อยล่วงหน้ามากเกินไป เบราว์เซอร์จะใช้ทรัพยากรย่อยที่โหลดไว้ล่วงหน้าเท่านั้นเมื่อดึงข้อมูลทั้งหมดเสร็จแล้ว ทั้งนี้เพื่อป้องกันการติดตามข้ามเว็บไซต์ ยิ่งมีทรัพยากรย่อยมาก ก็ยิ่งมีโอกาสน้อยลงที่แหล่งข้อมูลทั้งหมดจะโหลดล่วงหน้าเสร็จก่อนที่ผู้ใช้จะคลิกผ่านมายังหน้าเว็บของคุณ
ขณะนี้ 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)
อ่านส่วนการศึกษาร่วมสมัยเพื่อดูวิธีวัด "X% ของการดูหน้าเว็บ" และ "ปรับปรุง LCP ลดลง Y มิลลิวินาที"
การศึกษาร่วมสมัย
เมื่อดูข้อมูลการตรวจสอบผู้ใช้จริง (RUM) คุณควรแยกการโหลดหน้าเว็บออกเป็น SXG และไม่ใช่ SXG ในการดำเนินการดังกล่าว คุณจำเป็นต้องจำกัดชุดการโหลดหน้าเว็บที่คุณดู เพื่อให้ฝั่งที่ไม่ใช่ SXG ตรงกับเงื่อนไขการมีสิทธิ์สำหรับ SXG เพื่อหลีกเลี่ยงการให้น้ำหนักพิเศษในการเลือก มิเช่นนั้น ทั้งหมดต่อไปนี้จะมีอยู่ในชุดการโหลดหน้าเว็บที่ไม่ใช่ SXG เท่านั้น ซึ่งอาจมี LCP ต่างกันเลย
- อุปกรณ์ iOS: เนื่องจากความเร็วของฮาร์ดแวร์หรือเครือข่ายระหว่างผู้ใช้ที่มีอุปกรณ์เหล่านี้แตกต่างกัน
- เบราว์เซอร์ Chromium รุ่นเก่า: ด้วยเหตุผลเดียวกัน
- อุปกรณ์เดสก์ท็อป: ด้วยเหตุผลเดียวกันหรือเนื่องจากเลย์เอาต์หน้าเว็บทำให้มีการเลือก "องค์ประกอบขนาดใหญ่ที่สุด" ที่แตกต่างออกไป
- การนำทางในเว็บไซต์เดียวกัน (ผู้เข้าชมที่ไปตามลิงก์ภายในเว็บไซต์): เนื่องจากสามารถใช้ทรัพยากรย่อยที่แคชไว้จากการโหลดหน้าเว็บก่อนหน้าซ้ำได้
ใน Google Analytics (UA) ให้สร้างมิติข้อมูลที่กำหนดเอง 2 รายการที่มีขอบเขต "Hit" โดยรายการหนึ่งชื่อ "isSXG" และอีกรายการหนึ่งชื่อ "URL ที่มา" (มิติข้อมูล "แหล่งที่มา" ในตัวมีขอบเขตเซสชัน จึงไม่ยกเว้นการนำทางในเว็บไซต์เดียวกัน)
![เครื่องมือแก้ไขมิติข้อมูลของ Google Analytics ที่มีการตั้งค่าที่แนะนำ](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/google-analytics-dimensio-f031123b0438f.png?authuser=5&hl=th)
สร้างกลุ่มที่กำหนดเองชื่อ "SXGcounterftrue" โดยใช้ตัวกรองต่อไปนี้ "และ" รวมกัน
referrer
เริ่มต้นด้วยhttps://www.google.
Browser
ตรงทุกประการกับChrome
Browser
เวอร์ชันตรงกับนิพจน์ทั่วไป^(9[8-9]|[0-9]{3})
isSXG
ตรงทุกประการกับfalse
![เครื่องมือแก้ไขกลุ่มของ Google Analytics ที่มีตัวกรองที่แนะนำ](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/google-analytics-segment-14980677de979.png?authuser=5&hl=th)
สร้างสําเนาของกลุ่มนี้ชื่อ "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%](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/google-analytics-events-r-cbf7d46bbd64e.png?authuser=5&hl=th)
สุดท้าย ไปที่รายงาน Web Vitals เลือก "เลือกกลุ่ม" แล้วเลือก "SXGCounterftrue" และ "SXG"
![รายงาน Web Vitals ที่มีการเลือกข้อมูลที่โต้แย้งความจริงของ SXG และ SXG](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/web-vitals-report-select-d978e48f3498e.png?authuser=5&hl=th)
คลิก "ส่ง" แล้วคุณจะเห็นการแจกแจง LCP ของทั้ง 2 กลุ่ม ข้อมูลนี้ควรเติมอยู่ใน Y สำหรับ "ปรับปรุง LCP ของลูกค้าเป็น Y มิลลิวินาทีที่เปอร์เซ็นไทล์ที่ 75":
![รายงาน Web Vitals ที่แสดงการกระจาย LCP สำหรับสิ่งที่ตรงข้ามกับ SXG และ SXG](https://developer.chrome.com/static/blog/optimizing-lcp-using-signed-exchanges/image/web-vitals-report-showing-07708e1eca8c5.png?authuser=5&hl=th)
คำเตือน
เมื่อคุณใช้ตัวกรองข้างต้นทั้งหมดแล้ว การโหลดหน้าเว็บที่ขัดแย้งของ 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