การบีบอัดข้อมูลเป็นเทคนิคการเพิ่มประสิทธิภาพที่ผ่านการทดสอบประสิทธิภาพแล้ว ซึ่งจะลดขนาดทรัพยากรของหน้าที่มีสิทธิ์ ในบางกรณี เป็นเรื่องปกติที่จะใช้ gzip ในเว็บเซิร์ฟเวอร์เพื่อบีบอัดทรัพยากรของหน้าแบบข้อความทั่วไป เช่น ไฟล์ HTML, CSS และ JavaScript และส่งไปยังไคลเอ็นต์ซึ่งสามารถแยกออกได้ ผลที่ได้คือเวลาในการโหลดทรัพยากรเร็วขึ้นโดยไม่ส่งผลกระทบต่อลักษณะการทำงานที่ต้องการของหน้าเว็บ
แม้ว่า gzip จะมีประสิทธิภาพมากในตัว แต่การปรับปรุงการบีบอัดบนเว็บก็ได้รับความสนใจมากขึ้นในช่วงไม่กี่ปีที่ผ่านมา ในปี 2016 เราได้จัดส่งอัลกอริทึม Brotli ใน Chrome เพื่อแสดงอัตราส่วนการบีบอัดโดยรวมที่ดีขึ้นสำหรับทรัพยากรที่มีสิทธิ์ ภายในสิ้นปี 2017 เบราว์เซอร์ที่ทันสมัยทั้งหมดสนับสนุน 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 สำหรับทรัพยากรนั้น ส่วนหัวใช้คู่คีย์/ค่า 1 คู่ แต่จำเป็นต้องใช้แค่ 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 แล้ว คุณอาจคุ้นเคยกับปลั๊กอินต่างๆ สำหรับ Bundle ที่บีบอัดทรัพยากร ณ เวลาบิลด์ แล้วนำเสนอทรัพยากรที่บีบอัดเหล่านั้นในภายหลัง ตัวอย่างเช่น Apache ช่วยให้คุณใช้คำสั่งเพื่อให้บริการทรัพยากรที่บีบอัดล่วงหน้าเหล่านั้นในขณะที่ส่งคำขอ
Bundler ที่ใช้ Node.js ส่วนใหญ่ที่รองรับการบีบอัดจะใช้ไลบรารี Zlib ในตัวของโหนด Zlib รองรับ Brotli และ Bundler ที่ใช้ โดยทั่วไปจะมีอินเทอร์เฟซสำหรับส่งตัวเลือกไปยัง Zlib โดยตรง ซึ่งรองรับการบีบอัดโดยใช้พจนานุกรม ต่อไปนี้คือ Bundler บางส่วนที่รองรับการใช้พจนานุกรม
CompressionWebpackPluginของ Webpack ผ่านอินเทอร์เฟซcompressionOptionsของตนเองrollup-plugin-brotliเสนอการกำหนดค่าoptionsที่ส่งผ่าน Zlib ใน Node.js โดยตรง ซึ่งสามารถระบุพจนานุกรมได้- ปลั๊กอินของบุคคลที่สาม
esbuild-plugin-compressสำหรับการสร้างยังให้สิทธิ์ในการเข้าถึงตัวเลือก Zlib ใน Node.js ด้วย
โปรดทราบว่าพจนานุกรมที่ใช้ได้กับทรัพยากรเวอร์ชันใดก็ตามอาจใช้ทรัพยากรเวอร์ชันก่อนหน้าเวอร์ชันใดเวอร์ชันหนึ่ง ซึ่งหมายความว่าคุณจะต้องวิเคราะห์การเข้าชมของผู้ใช้แล้ววางแผนตามนั้น พยายามหาสมดุลและสร้างทรัพยากรที่เป็นประโยชน์ต่อผู้ใช้ที่กลับมามากที่สุดให้ได้มากที่สุด ขณะนี้ผู้ให้บริการ CDN กำลังทดสอบการบีบอัดพจนานุกรมที่แชร์ ปัจจุบันยังไม่มีการใช้งานสำหรับการใช้งานแบบสาธารณะ แต่เราคาดว่าจะทำให้เกิดการเปลี่ยนแปลงดังกล่าว
ลองใช้เลย!
การผสานรวมการบีบอัดพจนานุกรมที่ใช้ร่วมกันกับความสามารถในการบีบอัดที่มีอยู่ของเบราว์เซอร์มีแนวโน้มที่จะช่วยเพิ่มประสิทธิภาพอย่างมากในการโหลดสำหรับเว็บไซต์ต่างๆ ที่จัดส่งโค้ดการผลิตที่อัปเดตแล้วบ่อยครั้ง และได้รับปริมาณการเข้าชมจำนวนมากจากผู้เข้าชมที่กลับมา หากสนใจสร้างการบีบอัดพจนานุกรมที่ใช้ร่วมกัน คุณมี 2 ตัวเลือกดังนี้
- หากคุณแค่กำลังมองหาวิธีทดลองบีบอัดพจนานุกรมที่ใช้ร่วมกันด้วยตัวเองเพื่อทำความเข้าใจวิธีการทำงาน คุณสามารถเปิดใช้งานฟีเจอร์ทดลองการส่งพจนานุกรมการบีบอัดในหน้า
chrome://flags - หากคุณสนใจลองใช้ฟีเจอร์นี้ในเว็บไซต์เวอร์ชันที่ใช้งานจริงและดูว่าการบีบอัดพจนานุกรมที่แชร์มีประโยชน์ต่อผู้ใช้จริงอย่างไร โปรดลงทะเบียนทดลองใช้จากต้นทางเพื่อรับโทเค็น และอ่านเกี่ยวกับวิธีการทำงานของช่วงทดลองใช้จากต้นทาง
บทสรุป
เราค่อนข้างตื่นเต้นกับความก้าวหน้าที่สำคัญในเทคโนโลยีการบีบอัดบนเว็บนี้ และการทำให้แอปพลิเคชันที่มีอยู่ซึ่งผู้คนใช้อยู่ทุกวันทำงานได้เร็วยิ่งขึ้น เราสนับสนุนให้คุณลองใช้งาน และเหนือสิ่งอื่นใด เราอยากทราบความคิดเห็นของคุณ หากคุณสนใจ หากพบข้อบกพร่อง ให้ยื่นข้อบกพร่องที่ crbug.com สำหรับแหล่งข้อมูลและเครื่องมือเพิ่มเติม โปรดดูที่ use-as-dictionary.com สุดท้ายนี้ หากสนใจที่จะเจาะลึกเกี่ยวกับวิธีการทำงานของข้อผิดพลาดดังกล่าว โปรดใช้คำอธิบายเป็นขั้นตอนถัดไป