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

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

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

จนกว่าแฮชทรัพยากรจะเสถียร ประโยชน์ของการบีบอัดจะไม่สามารถป้องกันได้

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

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

การดำเนินการที่มีประโยชน์จริงๆ มักจะไม่ใช่การปรับระดับการบีบอัดต่อไป แต่ต้องควบคุมความเสถียรของผลิตภัณฑ์ที่วางจำหน่ายก่อน:

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

เฉพาะเมื่อเอกลักษณ์ของทรัพยากรมีความเสถียรเท่านั้นจึงจะสามารถนำแคชกลับมาใช้ซ้ำได้อย่างต่อเนื่อง และผลการบีบอัดจะมีค่าสะสม

งานแถลงข่าวความถี่สูงจะเขียนปัญหาการบีบอัดใหม่ให้กลายเป็นปัญหาเวอร์ชันพจนานุกรม

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

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

นี่เป็นการเปลี่ยนแปลงในทางปฏิบัติอย่างมากในการส่งมอบส่วนหน้าล่าสุด: กลยุทธ์การแคชและโปรโตคอลการบีบอัดไม่สามารถรักษาโดยทีมที่แตกต่างกันได้อีกต่อไป เวอร์ชันทรัพยากร เวอร์ชันพจนานุกรม และช่องว่างคีย์แคชโดยพื้นฐานแล้วคือปัญหาการเผยแพร่เดียวกัน

วิธีการแบบลำดับชั้นดังต่อไปนี้มักจะมีเสถียรภาพมากกว่า “การบีบอัดที่แข็งแกร่งแบบรวมศูนย์สำหรับทั้งไซต์”:

const policy = {
  immutableAssets: 'public, max-age=31536000, immutable',
  releaseManifest: 'public, max-age=60, stale-while-revalidate=30',
  sharedDictionary: 'versioned-by-release-train'
}

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

ความกดดันในการกลับไปยังแหล่งที่มามักไม่ใช่ว่าไฟล์มีขนาดใหญ่เกินไป แต่วิธีความล้มเหลวนั้นหยาบเกินไป

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

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

ในสถานการณ์ประเภทนี้ สิ่งที่มีค่าที่สุดคือรัศมีความล้มเหลวที่ควบคุมได้:

• เฉพาะไฟล์ Manifest, HTML และทรัพยากรที่ไม่แน่นอนที่มีการเปลี่ยนแปลงจริงเท่านั้น
• พยายามอย่าล้างไฟล์สแตติกที่มีแฮช และส่งต่อไปยังการอ้างอิงใหม่เพื่อการสลับตามธรรมชาติ
• แบ่งการเผยแพร่ออกเป็นลำดับ “อัปโหลดทรัพยากรใหม่ก่อน จากนั้นจึงตัดการอ้างอิง จากนั้นรีไซเคิลทรัพยากรเก่า” แทนที่จะล้างข้อมูลทั้งหมดในคราวเดียว

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

ขอบเขตที่เกี่ยวข้องจะถูกกำหนดร่วมกับขนาดทรัพยากรและความถี่ในการเผยแพร่

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

การแคชและการบีบอัดร่วมกันจะกลายเป็นโครงสร้างพื้นฐานในการจัดส่งอย่างรวดเร็วเมื่อมีคุณลักษณะเหล่านี้:

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

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