เพิ่มประสิทธิภาพในการบีบอัดด้วยพจนานุกรมที่แชร์

Jeremy Wagner

เผยแพร่: 6 มีนาคม 2024

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

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

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

คำอธิบายพจนานุกรมที่แชร์

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

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

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

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

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

วิธีที่ Chrome โฆษณาการรองรับพจนานุกรมที่แชร์

เบราว์เซอร์ทั้งหมดจะโฆษณาอัลกอริทึมการบีบอัดที่รองรับผ่านส่วนหัวของคำขอ Accept-Encoding เนื้อหาของส่วนหัวคือรายการที่คั่นด้วยคอมมาของการเข้ารหัสที่รองรับ

Accept-Encoding: gzip, br, zstd

ส่วนหัว Accept-Encoding นี้ระบุว่าเบราว์เซอร์ที่ขอทรัพยากรรองรับอัลกอริทึมการบีบอัด gzip, Brotli และ ZStandard จากนั้นเว็บเซิร์ฟเวอร์ที่ตอบสนองต่อคำขอจะตัดสินใจได้ว่าจะใช้อัลกอริทึมใดเมื่อตอบสนองต่อคำขอ

เมื่อเปิดใช้การรองรับพจนานุกรมที่แชร์และมีพจนานุกรมที่เกี่ยวข้องสำหรับทรัพยากร ระบบจะเพิ่มโทเค็นเพิ่มเติมลงในส่วนหัว Accept-Encoding โทเค็นเหล่านี้คือ br-d สำหรับ Brotli และ zstd-d สำหรับ Zstandard Chrome จะรวมแฮชของพจนานุกรมที่มีให้ใช้งานด้วย ซึ่งจะกล่าวถึงในส่วนถัดไป

Accept-Encoding: gzip, br, zstd, br-d, zstd-d
Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:

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

การบีบอัดพจนานุกรมที่แชร์สำหรับทรัพยากรแบบคงที่

ทรัพยากรหน้าเว็บแบบคงที่คือทรัพยากรที่สร้างการตอบกลับเดียวกันเสมอสำหรับ URL ที่ขอ ตัวอย่างทั่วไปของทรัพยากรหน้าเว็บแบบคงที่ที่บีบอัดได้คือไฟล์ JavaScript และ CSS โดยปกติแล้ว ทรัพยากรเหล่านี้จะมีการกำหนดเวอร์ชันเพื่อวัตถุประสงค์ในการแคชในลักษณะใดลักษณะหนึ่ง เช่น บางครั้งอาจมีแฮชของเนื้อหาไฟล์ในชื่อไฟล์ (เช่น styles.abcd1234.css) หรือใช้วิธีการอื่นๆ ในการระบุลายนิ้วมือของทรัพยากร ทรัพยากรประเภทเหล่านี้เหมาะอย่างยิ่งสำหรับการบีบอัดเดลต้าที่พจนานุกรมที่แชร์มีให้ เนื่องจากมักจะแคชทรัพยากรแบบคงที่เป็นระยะเวลานานและมักจะได้รับการอัปเดตเป็นระยะๆ

คุณระบุพจนานุกรมสำหรับทรัพยากรแบบคงที่ได้โดยการตั้งค่าส่วนหัวการตอบกลับ Use-As-Dictionary สำหรับทรัพยากรนั้น ส่วนหัวจะใช้คู่คีย์/ค่าคู่ใดคู่หนึ่ง แต่คู่ที่จำเป็นต้องใช้คือ match ซึ่งยอมรับไวยากรณ์ URLPattern ที่ระบุเส้นทางทรัพยากรที่ควรใช้พจนานุกรม

Use-As-Dictionary: match="/dist/styles.*.css"

คิดว่าส่วนหัว Use-As-Dictionary เป็นกลไกที่ใช้กับทรัพยากรเวอร์ชันในอนาคตซึ่งตรงกับรูปแบบที่ระบุไว้ในส่วนหัว สมมติว่าเว็บไซต์ของคุณจัดส่งรูปแบบทั้งหมดในไฟล์ CSS ไฟล์เดียว เพื่อความง่าย สมมติว่าเวอร์ชันแรกของทรัพยากรนั้นอยู่ที่ /dist/styles.v1.css และส่งพร้อมกับส่วนหัวการตอบกลับ Use-As-Dictionary ที่มีค่า match เป็น /dist/styles.*.css

หลังจากผ่านไปสักระยะ คุณจะอัปเดต CSS ของเว็บไซต์และเผยแพร่เว็บไซต์เวอร์ชันใหม่ที่ /dist/styles.v2.css เนื่องจากค่า match ที่ใช้ในส่วนหัวการตอบกลับ Use-As-Dictionary จากเวอร์ชันก่อนหน้ามีผลกับคำขอนี้ เบราว์เซอร์จึงจะส่งส่วนหัว Available-Dictionary ที่มีแฮชของพจนานุกรมที่เข้ารหัสเป็นลำดับไบต์ของฟิลด์ที่มีโครงสร้าง

Accept-Encoding: gzip, br, zstd, br-d, zstd-d
Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:

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

หากคุณเผยแพร่โค้ดใหม่สำหรับเว็บไซต์บ่อยๆ การบีบอัดเดลต้าจะช่วยได้มาก อย่างไรก็ตาม กระบวนการนี้มีความยืดหยุ่น หากเบราว์เซอร์ไม่พบว่ามีพจนานุกรมอยู่ในแคชของเบราว์เซอร์ของผู้ใช้ ก็จะไม่ระบุโทเค็น br-d หรือ zstd-d เพิ่มเติมในส่วนหัว Accept-Encoding ในกรณีดังกล่าว ระบบจะใช้ขั้นตอนการบีบอัดมาตรฐาน

การบีบอัดพจนานุกรมที่แชร์สำหรับทรัพยากรแบบไดนามิก

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

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

<link rel="dictionary" href="/dictionary.dat">

เมื่อ Chrome พบองค์ประกอบ <link> นี้ Chrome อาจดึงข้อมูลพจนานุกรมเมื่อหน้าเว็บไม่มีการใช้งาน และมีลำดับความสำคัญต่ำเพื่อหลีกเลี่ยงการแย่งแบนด์วิดท์ การตอบกลับสำหรับพจนานุกรมเองต้องระบุส่วนหัว Use-As-Dictionary และระบุเส้นทางทรัพยากรแบบไดนามิกที่ใช้

Use-As-Dictionary: match="/product/*"

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

บีบอัดทรัพยากรแบบคงที่ในเวลาบิลด์

หากคุ้นเคยกับ Bundler คุณอาจคุ้นเคยกับปลั๊กอินต่างๆ สำหรับ Bundler ที่สามารถบีบอัดทรัพยากรในเวลาบิลด์ และแสดงทรัพยากรที่บีบอัดเหล่านั้นในภายหลัง ตัวอย่างเช่น Apache ช่วยให้คุณใช้คำสั่งเพื่อแสดงทรัพยากรที่บีบอัดล่วงหน้าเหล่านั้นในเวลาที่ส่งคำขอ

Bundler ที่อิงตาม Node.js ส่วนใหญ่ที่รองรับการบีบอัดจะใช้ไลบรารี Zlib ในตัวของ Node Zlib รองรับ Brotli และ Bundler ที่ใช้ Brotli มักจะมีอินเทอร์เฟซสำหรับส่งตัวเลือกไปยัง Zlib โดยตรง ซึ่งรองรับการบีบอัดที่ใช้พจนานุกรม Bundler บางตัวที่รองรับการใช้พจนานุกรมมีดังนี้

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

ลองใช้เลย!

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

  1. หากต้องการทดลองใช้การบีบอัดพจนานุกรมที่ใช้ร่วมกันด้วยตนเองเพื่อดูว่าการทำงานเป็นอย่างไร คุณสามารถเปิดใช้ฟีเจอร์ทดลองการส่งพจนานุกรมการบีบอัดในหน้า chrome://flags ได้
  2. หากสนใจทดลองใช้ในเว็บไซต์เวอร์ชันที่ใช้งานจริงและดูว่าการบีบอัดพจนานุกรมที่แชร์จะเป็นประโยชน์ต่อผู้ใช้จริงได้อย่างไร โปรดลงทะเบียนเพื่อทดลองใช้ Origin เพื่อรับโทเค็น และอ่านวิธีการทำงานของการทดลองใช้ Origin

บทสรุป

เราตื่นเต้นมากกับความก้าวหน้าครั้งสำคัญในเทคโนโลยีการบีบอัดบนเว็บ และความเร็วที่เพิ่มขึ้นซึ่งอาจทำให้แอปพลิเคชันที่มีอยู่ซึ่งผู้คนใช้ทุกวันทำงานได้เร็วขึ้น เราขอแนะนำให้คุณลองใช้ และที่สำคัญที่สุดคือเราอยากทราบความคิดเห็นของคุณหากคุณลองใช้แล้ว หากพบข้อบกพร่อง โปรดรายงานที่ crbug.com ดูแหล่งข้อมูลและเครื่องมือเพิ่มเติมได้ที่ use-as-dictionary.com และหากสนใจที่จะเจาะลึกวิธีการทำงานทั้งหมด คำอธิบายจะเป็นขั้นตอนถัดไปที่ดี