SXG เป็นกลไกการนำส่งที่ช่วยให้ตรวจสอบสิทธิ์ต้นทางของทรัพยากรได้อย่างอิสระโดยไม่ต้องอิงตามการนำส่ง
Signed Exchange (SXG) เป็นกลไกการนำส่งที่ช่วยให้ตรวจสอบสิทธิ์ต้นทางของทรัพยากรได้อย่างอิสระโดยไม่ต้องอิงตามวิธีนำส่ง การใช้ SXG จะช่วยปรับปรุง Largest Contentful Paint (LCP) ได้ด้วยการเปิดใช้การดึงข้อมูลล่วงหน้าแบบข้ามต้นทางแบบรักษาความเป็นส่วนตัว นอกจากนี้ การแยกการทำงานในลักษณะนี้ช่วยให้เกิดกรณีการใช้งานที่หลากหลาย เช่น การใช้งานอินเทอร์เน็ตแบบออฟไลน์และบริการจากแคชของบุคคลที่สาม
บทความนี้จะแสดงภาพรวมที่ครอบคลุมเกี่ยวกับ SXG ไม่ว่าจะเป็นวิธีการทำงาน กรณีการใช้งาน และเครื่องมือ
ความเข้ากันได้กับเบราว์เซอร์
เบราว์เซอร์ที่ใช้ Chromium รองรับ SXG (เริ่มตั้งแต่เวอร์ชัน Chrome 73, Edge 79 และ Opera 64)
ภาพรวม
ในกรณีการใช้งานหลัก SXG จะใช้แคชเพื่อดึงข้อมูลล่วงหน้าและแสดงเนื้อหาที่ได้ลงนามแบบเข้ารหัสจากต้นทาง วิธีนี้จะช่วยให้การนำทางข้ามต้นทางจากเว็บไซต์อ้างอิงมีความรวดเร็ว ขณะเดียวกันก็ทำให้หน้าเว็บไม่มีการเปลี่ยนแปลงและระบุแหล่งที่มาอย่างถูกต้อง ข้อมูลที่อาจระบุตัวบุคคลได้จะถูกซ่อนไว้จนกว่าผู้ใช้จะไปยังเว็บไซต์หนึ่งๆ เพื่อปกป้องความเป็นส่วนตัวของผู้ใช้ Google Search เป็นผู้ใช้กลุ่มแรกๆ ที่ใช้ความสามารถในการดึงข้อมูลล่วงหน้าของ SXG และสำหรับเว็บไซต์ที่ได้รับการเข้าชมจำนวนมากจาก Google Search SXG อาจเป็นเครื่องมือสำคัญสำหรับส่งการโหลดหน้าเว็บที่เร็วขึ้นแก่ผู้ใช้ เมื่อเวลาผ่านไป เราหวังว่าผลกระทบนี้จะขยายไปสู่ผู้บอกต่อเพิ่มเติม
วิธีการทำงาน
เว็บไซต์จะลงนามคู่คำขอ/การตอบกลับ ("การแลกเปลี่ยน HTTP") ในลักษณะที่ทำให้เบราว์เซอร์ยืนยันที่มาและความสมบูรณ์ของเนื้อหาได้โดยไม่ต้องคำนึงถึงวิธีการเผยแพร่เนื้อหา ดังนั้น เบราว์เซอร์จึงสามารถแสดง URL ของเว็บไซต์ต้นทางในแถบที่อยู่แทนที่จะแสดง URL ของเซิร์ฟเวอร์ที่ส่งเนื้อหา
ที่ผ่านมา วิธีเดียวที่เว็บไซต์ใช้บุคคลที่สามในการเผยแพร่เนื้อหาโดยคงการระบุแหล่งที่มาไว้คือ เว็บไซต์ต้องแชร์ใบรับรอง SSL กับผู้จัดจำหน่าย ซึ่งมีข้อด้อยด้านความปลอดภัย นอกจากนี้ ยังไม่ใช่เรื่องง่ายที่จะทำให้เนื้อหาสามารถพกพาได้อย่างแท้จริง
รูปแบบ SXG
SXG จะรวมอยู่ในไฟล์ที่เข้ารหัสแบบไบนารีที่มีคอมโพเนนต์หลัก 2 รายการ ได้แก่ HTTP Exchange และลายเซ็นที่ครอบคลุม Exchange การแลกเปลี่ยน HTTP ประกอบด้วย URL คำขอ ข้อมูลการเจรจาเนื้อหา และการตอบกลับ HTTP
format version: 1b3 request: method: GET uri: https://example.org/ headers: response: status: 200 headers: Cache-Control: max-age=604800 Digest: mi-sha256-03=kcwVP6aOwYmA/j9JbUU0GbuiZdnjaBVB/1ag6miNUMY= Expires: Mon, 24 Aug 2020 16:08:24 GMT Content-Type: text/html; charset=UTF-8 Content-Encoding: mi-sha256-03 Date: Mon, 17 Aug 2020 16:08:24 GMT Vary: Accept-Encoding signature: label;cert-sha256=<em>ViFgi0WfQ+NotPJf8PBo2T5dEuZ13NdZefPybXq/HhE=</em>; cert-url="https://test.web.app/ViFgi0WfQ-NotPJf8PBo2T5dEuZ13NdZefPybXq_HhE"; date=1597680503;expires=1598285303;integrity="digest/mi-sha256-03";sig=<em>MEUCIQD5VqojZ1ujXXQaBt1CPKgJxuJTvFlIGLgkyNkC6d7LdAIgQUQ8lC4eaoxBjcVNKLrbS9kRMoCHKG67MweqNXy6wJg=</em>; validity-url="https://example.org/webpkg/validity" header integrity: sha256-Gl9bFHnNvHppKsv+bFEZwlYbbJ4vyf4MnaMMvTitTGQ=</p> <p>The exchange has a valid signature. payload [1256 bytes]:</p> <pre class="prettyprint"><code><title>SXG example</title> <meta charset="utf-8"> <meta http-equiv="Content-type" content="text/html; charset=utf-8"> <style type="text/css"> body { background-color: #f0f0f2; margin: 0; padding: 0; } </style> </code></pre> <div> <h1>Hello</h1> </div> <p>
พารามิเตอร์ expires
ในลายเซ็นระบุวันที่หมดอายุของ SXG โดย SXG จะมีอายุได้สูงสุด 7 วัน ดูข้อมูลเพิ่มเติมเกี่ยวกับส่วนหัวของลายเซ็นได้ในข้อกำหนดของ Signed HTTP Exchange
การรองรับการปรับเปลี่ยนฝั่งเซิร์ฟเวอร์ในแบบของคุณ
SXG ที่มีส่วนหัว Vary: Cookie
จะแสดงเฉพาะกับผู้ใช้ที่ไม่มีคุกกี้สำหรับ URL คำขอที่ลงนามเท่านั้น หากเว็บไซต์แสดง HTML ที่แตกต่างกันแก่ผู้ใช้ที่ลงชื่อเข้าสู่ระบบ คุณจะใช้ฟีเจอร์นี้เพื่อใช้ประโยชน์จาก SXG ได้โดยไม่ต้องเปลี่ยนแปลงประสบการณ์การใช้งานนั้น ดูรายละเอียดเกี่ยวกับการปรับเปลี่ยนฝั่งเซิร์ฟเวอร์ในแบบของคุณด้วย Dynamic SXG
การจัดแพ็กเกจเว็บ
SXG เป็นส่วนหนึ่งของกลุ่มข้อเสนอข้อมูลจำเพาะของแพ็กเกจเว็บที่กว้างขึ้น นอกเหนือจาก SXG องค์ประกอบหลักอีกอย่างหนึ่งของข้อกำหนดเฉพาะของแพ็กเกจเว็บคือ Web Bundle ("การแลกเปลี่ยน HTTP แบบรวม") Web Bundle คือคอลเล็กชันของทรัพยากร HTTP และข้อมูลเมตาที่จำเป็นในการตีความ Bundle
ความสัมพันธ์ระหว่าง SXG และ Web Bundle เป็นจุดที่ก่อให้เกิดความสับสนได้ทั่วไป SXG และ Web Bundle เป็นเทคโนโลยี 2 อย่างที่แตกต่างกันซึ่งไม่ขึ้นอยู่กับกันและกัน กล่าวคือ Web Bundle ใช้ได้กับทั้ง Signed Exchange และแบบไม่ลงชื่อ เป้าหมายทั่วไปของทั้ง SXG และ Web Bundle คือการสร้างรูปแบบ "แพ็กเกจเว็บ" ที่อนุญาตให้แชร์เว็บไซต์ทั้งหมดเพื่อการใช้งานแบบออฟไลน์
เร่งการโหลดหน้าเว็บด้วย Signed Exchange
การเปิดใช้ Signed Exchange จะช่วยเพิ่มประสิทธิภาพของหน้าเว็บ ซึ่งจะส่งผลต่อ Core Web Vitals ของเว็บไซต์ใน Largest Contentful Paint (LCP) โดยเฉพาะ ในฐานะที่เป็นลูกค้ารายแรกสุดที่เปิดรับนวัตกรรม Google Search ใช้ SXG เพื่อมอบประสบการณ์การโหลดหน้าเว็บที่เร็วขึ้นแก่ผู้ใช้สำหรับหน้าเว็บที่โหลดจากหน้าผลการค้นหา
Google Search จะรวบรวมข้อมูลและแคช SXG เมื่อพร้อมใช้งาน และดึงข้อมูล SXG ที่ผู้ใช้น่าจะเข้าชมไว้ล่วงหน้า เช่น หน้าที่ตรงกับผลการค้นหาแรก
SXG ทำงานได้ดีที่สุดควบคู่ไปกับการเพิ่มประสิทธิภาพอื่นๆ เช่น การใช้ CDN และการลดทรัพยากรย่อยของการบล็อกการแสดงผล หลังจากติดตั้งใช้งานแล้ว ให้ทำตามคําแนะนําเหล่านี้เพื่อใช้ประโยชน์จาก LCP ให้ได้สูงสุดจากการดึงข้อมูล SXG ล่วงหน้า ในหลายๆ กรณี การเพิ่มประสิทธิภาพดังกล่าวอาจส่งผลให้มีการโหลดหน้าเว็บเกือบทันทีที่มาจาก Google Search ดังนี้
ผลกระทบของ Signed Exchange
จากการทดสอบที่ผ่านมา เราพบว่า LCP ของการดึงข้อมูลล่วงหน้าที่เปิดใช้ SXG ลดลงโดยเฉลี่ย 300 ถึง 400 มิลลิวินาที ซึ่งจะช่วยให้เว็บไซต์สร้างความประทับใจแรกกับผู้ใช้ได้ดีขึ้น และมักจะส่งผลดีต่อเมตริกธุรกิจ
แบรนด์และเว็บไซต์ระดับโลกหลายแห่งได้รับประโยชน์จาก Signed Exchanges อยู่แล้ว ในกรณีศึกษานี้ มาดูกันว่าการใช้ Signed Exchanges ช่วยให้ RebelMouse ซึ่งเป็นระบบจัดการเนื้อหา (CMS) ที่โดดเด่นปรับปรุงประสิทธิภาพและเมตริกธุรกิจของลูกค้าได้อย่างไร
- Narcity เพิ่ม LCP ได้ 41%
- Paper Magazine พบว่ามีจำนวนเซสชันต่อผู้ใช้เพิ่มขึ้น 27%
- บล็อก MLT ลดเวลาในการโหลดหน้าเว็บได้ 21%
Cloudflare พบว่า SXG ได้ปรับปรุง TTFB สำหรับเว็บไซต์ 98% และปรับปรุง LCP สำหรับเว็บไซต์ 85% โดยมีค่ามัธยฐานเพิ่มขึ้นกว่า 20% ในการโหลดหน้าเว็บที่มีสิทธิ์สำหรับ SXG
การจัดทำดัชนี
การที่ Google Search ไม่ได้จัดอันดับหรือจัดทำดัชนีหน้าที่แทน SXG และไม่ใช่ SXG แตกต่างกัน ท้ายที่สุดแล้ว SXG คือกลไกการนำส่งเนื้อหา ซึ่งไม่ได้เปลี่ยนแปลงเนื้อหาที่สำคัญ
AMP
คุณส่งเนื้อหา AMP โดยใช้ SXG ได้ SXG ช่วยให้สามารถดึงข้อมูล AMP ล่วงหน้าและแสดงเนื้อหาโดยใช้ Canonical URL แทน URL ของ AMP ได้ โดย AMP มีเครื่องมือแยกต่างหากสำหรับการสร้าง SXG ดูวิธีแสดง AMP โดยใช้ Signed Exchange ใน amp.dev
การแก้ไขข้อบกพร่อง SXG ด้วยเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome
หากต้องการดู SXG ด้วยตนเอง ให้ใช้เบราว์เซอร์ Chromium เปิดเครื่องมือสำหรับนักพัฒนาเว็บ เปิดแผงเครือข่าย และไปที่หน้าการค้นหาตัวอย่างนี้ คุณจะระบุ Signed Exchange ได้โดยมองหา signed-exchange
ในคอลัมน์ประเภท
![ภาพหน้าจอแสดงคำขอ SXG ในแผง "เครือข่าย" ในเครื่องมือสำหรับนักพัฒนาเว็บ](https://web.dev/static/articles/signed-exchanges/image/screenshot-showing-sxg-r-9a4f9df2440b3.png?authuser=5&hl=th)
แท็บแสดงตัวอย่างจะแสดงข้อมูลเพิ่มเติมเกี่ยวกับเนื้อหาของ SXG
![ภาพหน้าจอของแท็บ "แสดงตัวอย่าง" สําหรับ SXG](https://web.dev/static/articles/signed-exchanges/image/screenshot-the-preview-033e1253a3e1.png?authuser=5&hl=th)
การใช้เครื่องมือ
การใช้งาน SXG ประกอบด้วยการสร้าง SXG ที่สอดคล้องกับ URL ที่ระบุ จากนั้นจึงแสดง SXG นั้นแก่ผู้ส่งคำขอ (โดยทั่วไปคือ Crawler)
ใบรับรอง
หากต้องการสร้าง SXG คุณจะต้องมีใบรับรองที่สามารถลงนาม SXG ได้ แม้ว่าเครื่องมือบางอย่างจะได้รับใบรับรองเหล่านี้โดยอัตโนมัติก็ตาม หน้านี้แสดงผู้ออกใบรับรองที่ออกใบรับรองประเภทนี้ได้ คุณจะรับใบรับรองได้โดยอัตโนมัติจากผู้ออกใบรับรองของ Google โดยใช้ไคลเอ็นต์ ACME เซิร์ฟเวอร์ Web Packager มีไคลเอ็นต์ ACME ในตัว และ sxg-rs จะมีให้ใช้ในเร็วๆ นี้
เครื่องมือ SXG เฉพาะแพลตฟอร์ม
เครื่องมือเหล่านี้รองรับ Technology Stack ที่เฉพาะเจาะจง หากใช้แพลตฟอร์มที่เครื่องมืออย่างใดอย่างหนึ่งเหล่านี้รองรับอยู่แล้ว คุณอาจพบว่าการตั้งค่าง่ายกว่าเครื่องมือสำหรับจุดประสงค์ทั่วไป
sxg-rs/fastly_compute
เรียกใช้ใน Fastly Compute@EdgeSigned Exchange แบบอัตโนมัติเป็นฟีเจอร์ของ Cloudflare ที่ได้รับใบรับรองและสร้าง Signed Exchange โดยอัตโนมัติ
โมดูล NGINX SXG สร้างและแสดง SXG สำหรับเว็บไซต์ที่ใช้ nginx ดูวิธีการตั้งค่าได้ที่นี่
Envoy SXG Filter จะสร้างและแสดง SXG สำหรับเว็บไซต์ที่ใช้ Envoy
เครื่องมือ SXG อเนกประสงค์
เซิร์ฟเวอร์ HTTP sxg-rs
โดย sxg-rs
http_server
ทำหน้าที่เป็นพร็อกซีแบบย้อนกลับสำหรับ
การแสดง SXG สำหรับคำขอจากโปรแกรมรวบรวมข้อมูล SXG นั้น http_server
จะลงนามการตอบกลับจากแบ็กเอนด์และตอบกลับด้วย SXG สำหรับคำแนะนำในการติดตั้ง โปรดดูที่ README
เซิร์ฟเวอร์ Web Packager
เซิร์ฟเวอร์ Web Packager สำหรับ webpkgserver
เป็นอีกทางเลือกหนึ่งสำหรับ sxg-rs http_server ที่เขียนด้วย Go สำหรับคำแนะนำในการตั้งค่าเซิร์ฟเวอร์ Web Packager โปรดดูวิธีตั้งค่า Signed Exchange โดยใช้ Web Packager
CLI สำหรับ Web Packager
Web Packager CLI จะสร้าง SXG ที่สอดคล้องกับ URL ที่ระบุ
webpackager \
--private\_key=private.key \
--cert\_url=https://example.com/certificate.cbor \
--url=https://example.com
เมื่อสร้างไฟล์ SXG แล้ว ให้อัปโหลดไฟล์ดังกล่าวไปยังเซิร์ฟเวอร์ของคุณ และแสดงด้วยประเภท MIME application/signed-exchange;v=b3
นอกจากนี้ คุณจะต้องแสดงใบรับรอง SXG เป็น application/cert-chain+cbor
ไลบรารี SXG
คุณสามารถใช้ไลบรารีต่อไปนี้เพื่อสร้างโปรแกรมสร้าง SXG ของคุณเอง
sxg_rs
เป็นไลบรารี Rust สำหรับ สร้าง SXG เป็นไลบรารี SXG ที่มีฟีเจอร์มากที่สุดและใช้เป็นฐานสำหรับเครื่องมือcloudflare_worker
และfastly_compute
libsxg
เป็นไลบรารี C ขนาดเล็ก สำหรับการสร้าง SXG โดยใช้เป็นพื้นฐานสำหรับโมดูล NGINX SXG และตัวกรอง Envoy SXGgo/signed-exchange
เป็นไลบรารี Go เพียงเล็กน้อยที่ได้มาจากข้อกำหนด Webpackage เพื่อใช้เป็นการใช้งานอ้างอิงของการสร้าง SXG โดยใช้เป็นพื้นฐานสำหรับเครื่องมือ CLI,gen-signedexchange
และเครื่องมือ Web Packager ที่มีประสิทธิภาพมากขึ้น
การเจรจาต่อรองเนื้อหา
เซิร์ฟเวอร์ควรแสดง SXG เมื่อส่วนหัว "ยอมรับ" ระบุว่าค่า q ของ application/signed-Exchange มากกว่าหรือเท่ากับ q-value สำหรับ text/html ในทางปฏิบัติ จะหมายความว่าเซิร์ฟเวอร์ต้นทางจะให้บริการ SXG แก่ Crawler แต่ไม่ให้บริการเบราว์เซอร์ เครื่องมือข้างต้นหลายรายการทำเช่นนี้โดยค่าเริ่มต้น แต่สำหรับเครื่องมืออื่นๆ จะใช้นิพจน์ทั่วไปต่อไปนี้เพื่อจับคู่ส่วนหัว "ยอมรับ" ของคำขอที่ควรแสดงเป็น SXG ได้
http
Accept: /(^|,)\s\*application\/signed-exchange\s\*;\s\*v=[[:alnum:]\_-]+\s\*(,|$)/
คำแนะนำนี้มีตัวอย่างของ Apache และ nginx
อัปเดต Cache API
แคช SXG ของ Google มี API ที่เจ้าของเว็บไซต์สามารถใช้เพื่อนำ SXG ออกจากแคชก่อนที่จะหมดอายุเนื่องจาก Cache-Control: max-age
โปรดดูรายละเอียดที่เอกสารอ้างอิง API แคชการอัปเดต
การลิงก์กับ SXG
ทุกเว็บไซต์สามารถแคช แสดง และดึงข้อมูล SXG ของหน้าเว็บที่ลิงก์ไปล่วงหน้า (หากมี) โดยใช้แท็ก และ ดังนี้
html
<a href="https://example.com/article.html.sxg">
<link rel="prefetch" as="document" href="https://example.com/article.html.sxg">
บทความนี้จะแสดงวิธีใช้ nginx เพื่อกระจาย SXG
ข้อดีที่เป็นเอกลักษณ์
SXG เป็นหนึ่งในเทคโนโลยีที่เป็นไปได้ทั้งหมดที่เปิดใช้การดึงข้อมูลล่วงหน้าแบบข้ามต้นทาง เมื่อตัดสินใจว่าจะใช้เทคโนโลยีใด คุณอาจต้องแลกกับการเพิ่มประสิทธิภาพในด้านต่างๆ ส่วนต่อไปนี้จะแสดงค่าที่ไม่ซ้ำกัน 2-3 รายการที่ SXG ระบุในพื้นที่ของโซลูชันที่เป็นไปได้ ปัจจัยเหล่านี้อาจมีการเปลี่ยนแปลงเมื่อเวลาผ่านไปเนื่องจากพื้นที่ของโซลูชันที่พร้อมให้ใช้งานมีการพัฒนา
คำขอแสดงโฆษณาน้อยลง
เมื่อใช้การดึงข้อมูลล่วงหน้าข้ามเว็บไซต์ เซิร์ฟเวอร์ของคุณอาจต้องแสดงคำขอเพิ่มเติม กรณีนี้สอดคล้องกับกรณีที่มีการดึงข้อมูลหน้าเว็บล่วงหน้า แต่ผู้ใช้ไม่ได้เข้าชมหน้าเว็บดังกล่าว หรือจำนวนไบต์ที่ดึงข้อมูลล่วงหน้าแสดงให้ผู้ใช้เห็นไม่ได้ สำหรับ SXG คำขอที่ไม่ได้ใช้เพิ่มเติมเหล่านี้จะลดลงอย่างมาก
- ระบบจะแคช SXG ไว้และอาจส่งให้ผู้ใช้จนกว่าจะหมดอายุ ดังนั้น เซิร์ฟเวอร์แคชจะจัดการการดึงข้อมูลล่วงหน้าหลายรายการพร้อมกันเท่านั้น
- SXG จะแสดงให้ผู้ใช้เห็นทั้งกรณีที่มีและไม่มีคุกกี้ในเว็บไซต์ ด้วยเหตุนี้ จึงมีจำนวนครั้งที่ต้องดึงข้อมูลหน้าเว็บอีกครั้งหลังจากการนำทาง
การปรับปรุงความเร็วของหน้าเว็บ
คุณอาจเห็นว่าความเร็วหน้าเว็บมีการปรับปรุงเพิ่มเติมเนื่องจากการดึงข้อมูลล่วงหน้าและความสามารถที่แพลตฟอร์มรองรับในปัจจุบันมีดังต่อไปนี้
- ระบบแสดง SXG แก่ผู้ใช้ที่มีคุกกี้สำหรับเว็บไซต์ของคุณได้
- นอกจากนี้ SXG ยังดึงข้อมูลทรัพยากรย่อยสำหรับหน้าของคุณ เช่น JavaScript, CSS, แบบอักษร และรูปภาพล่วงหน้า เมื่อระบุโดยใช้ส่วนหัว
Link
- ในอนาคตอันใกล้ การดึงข้อมูล SXG ล่วงหน้าจาก Google Search จะพร้อมใช้งานในผลการค้นหาประเภทอื่นๆ
บทสรุป
Signed Exchange เป็นกลไกการส่งที่ช่วยให้ยืนยันต้นทางและความถูกต้องของทรัพยากรได้แบบไม่ขึ้นกับวิธีส่งทรัพยากร ด้วยเหตุนี้ บุคคลที่สามจึงเผยแพร่ SXG ได้ในขณะที่ยังคงรักษาการระบุแหล่งที่มาของผู้เผยแพร่เต็มรูปแบบไว้ได้