เครือข่ายนำส่งข้อมูล (CDN)

ปรับปรุงประสิทธิภาพโดยใช้เครือข่ายนำส่งข้อมูล (CDN)

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

ภาพรวม

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

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

การนำส่งทรัพยากร

แม้ว่าอาจดูไม่ใช่เรื่องง่าย แต่โดยปกติแล้วการใช้ CDN เพื่อนำส่งทรัพยากร (แม้แต่ทรัพยากรที่แคชไม่ได้) จะเร็วกว่าการให้ผู้ใช้โหลดทรัพยากร "โดยตรง" จากเซิร์ฟเวอร์

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

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

การแคช

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

การเพิ่มทรัพยากรลงในแคช

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

การนำทรัพยากรออกจากแคช

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

• การถอนแคช

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

• กำลังลบถาวร

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

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

  เมื่อมีการลบถาวรจะใช้ในปริมาณมาก โดยทั่วไปจะมีการใช้ร่วมกับแนวคิดที่เรียกว่า "แท็กแคช" หรือ "คีย์แคชตัวแทน" กลไกนี้จะช่วยให้เจ้าของเว็บไซต์สามารถเชื่อมโยงตัวระบุเพิ่มเติมอย่างน้อย 1 รายการ (บางครั้งเรียกว่า "แท็ก") กับทรัพยากรที่แคชไว้ แล้วแท็กเหล่านี้จะใช้สำหรับการฟอกอย่างละเอียดได้ เช่น คุณอาจเพิ่มแท็ก "footer" สำหรับทรัพยากรทั้งหมด (เช่น /about, /blog) ที่มีส่วนท้ายของเว็บไซต์ เมื่ออัปเดตส่วนท้ายแล้ว ให้สั่งให้ CDN ลบทรัพยากรทั้งหมดที่เชื่อมโยงกับแท็ก "footer" ออกถาวร

ทรัพยากรที่แคชได้

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

แหล่งข้อมูลส่วนตัวและสาธารณะ

• แหล่งข้อมูลส่วนตัว

  ทรัพยากรส่วนตัวมีข้อมูลสำหรับผู้ใช้แต่ละราย จึงไม่ควรแคชโดย CDN ทรัพยากรส่วนตัวจะระบุด้วยส่วนหัว Cache-Control: private

• แหล่งข้อมูลสาธารณะ

  ทรัพยากรสาธารณะไม่มีข้อมูลที่ระบุสำหรับผู้ใช้ ดังนั้น CDN จึงสามารถแคชได้ CDN อาจถือว่าทรัพยากรนั้นแคชได้ หากไม่มีส่วนหัว Cache-Control: no-store หรือ Cache-Control: private ระยะเวลาที่สามารถแคชทรัพยากรสาธารณะได้จะขึ้นอยู่กับความถี่ในการเปลี่ยนแปลงเนื้อหา

เนื้อหาแบบไดนามิกและแบบคงที่

• เนื้อหาแบบไดนามิก

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

• เนื้อหาแบบคงที่

  เนื้อหาแบบคงที่จะเปลี่ยนแปลงไม่บ่อยนัก (ถ้ามี) รูปภาพ วิดีโอ และไลบรารีที่มีเวอร์ชันมักจะเป็นตัวอย่างของเนื้อหาประเภทนี้ เนื่องจากเนื้อหาแบบคงที่ไม่มีการเปลี่ยนแปลง คุณจึงควรแคชเนื้อหาด้วย Time to Live (TTL) ที่นาน เช่น 6 เดือนหรือ 1 ปี

การเลือก CDN

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

การแสดง

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

ข้อดีข้อนี้ทำให้ CDN บางแห่งใช้วิธีการแคชแบบเป็นขั้น กล่าวคือ PoP ที่อยู่ใกล้ผู้ใช้ (หรือที่เรียกว่า "Edge Caches") จะเสริมด้วย PoP กลางที่มีอัตราส่วนการค้นพบแคชสูงกว่า เมื่อ Edge Cache ไม่พบทรัพยากร ระบบจะค้นหา PoP ส่วนกลางของทรัพยากรนั้น วิธีนี้จะแลกกับเวลาในการตอบสนองที่นานขึ้นเล็กน้อยสำหรับความเป็นไปได้ที่สูงขึ้นที่ทรัพยากรจะให้บริการจากแคช CDN ได้ แต่อาจไม่ได้เป็น Edge Cache ก็ได้

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

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

ผลกระทบต่อการแสดงผลเนื้อหาขนาดใหญ่ที่สุด (LCP)

ตามที่ได้กล่าวไว้ก่อนหน้าในบทความนี้ วัตถุประสงค์หลักของ CDN คือการลดเวลาในการตอบสนองโดยการกระจายทรัพยากรไปยังเซิร์ฟเวอร์ที่อยู่ใกล้ผู้ใช้มากกว่า ด้วยเหตุนี้ ประโยชน์หลักของ CDN จึงเป็นการปรับปรุงประสิทธิภาพการโหลด โดยเฉพาะอย่างยิ่ง Time to First Byte (TTFB) ของทรัพยากรสามารถปรับปรุงได้อย่างมากเมื่อนำ CDN มาใช้ในสถาปัตยกรรมฝั่งเซิร์ฟเวอร์ของเว็บไซต์

แม้ว่า TTFB จะไม่ใช่เมตริกประสิทธิภาพที่เน้นผู้ใช้เป็นหลัก แต่ก็เป็นเมตริกสำคัญสำหรับการวินิจฉัยปัญหาเกี่ยวกับ Largest Contentful Paint (LCP) ซึ่งเป็นเมตริกที่เน้นผู้ใช้เป็นหลัก

CDN มีประสิทธิภาพเป็นพิเศษในการปรับปรุง LCP เนื่องจากสามารถปรับปรุงทั้งการนำส่งเอกสาร (โดยลด TTFB ในการตั้งค่าการเชื่อมต่อและการแคชเอกสาร) และปรับปรุงการนำส่งทรัพยากรแบบคงที่ที่จำเป็นต่อการแสดงผลองค์ประกอบ LCP

ฟีเจอร์เพิ่มเติม

โดยทั่วไปแล้ว CDN จะมีฟีเจอร์ที่หลากหลายนอกเหนือจากข้อเสนอ CDN หลัก ฟีเจอร์ที่นิยมใช้กัน ได้แก่ การจัดสรรภาระงาน การเพิ่มประสิทธิภาพรูปภาพ สตรีมมิงวิดีโอ การประมวลผลที่ต้นทาง (Edge Computing) และผลิตภัณฑ์ด้านความปลอดภัย

วิธีตั้งค่าและกำหนดค่า CDN

โดยหลักการแล้ว คุณควรใช้ CDN เพื่อแสดงทั้งเว็บไซต์ ขั้นตอนการตั้งค่าในระดับสูงจะประกอบด้วยการลงชื่อสมัครใช้กับผู้ให้บริการ CDN จากนั้นอัปเดตระเบียน CNAME DNS ให้ชี้ไปที่ผู้ให้บริการ CDN เช่น ระเบียน CNAME สำหรับ www.example.com อาจชี้ไปที่ example.my-cdn.com เนื่องจากการเปลี่ยนแปลง DNS นี้ การเข้าชมเว็บไซต์จะกำหนดเส้นทางผ่าน CDN

หากไม่สามารถใช้ CDN เพื่อแสดงทรัพยากรทั้งหมด คุณสามารถกำหนดค่า CDN เพื่อแสดงทรัพยากรเพียงบางส่วนเท่านั้น เช่น เฉพาะทรัพยากรแบบคงที่เท่านั้น ซึ่งทำได้โดยการสร้างระเบียน CNAME แยกต่างหากซึ่งจะใช้สำหรับทรัพยากรที่ CDN ควรให้บริการเท่านั้น ตัวอย่างเช่น คุณอาจสร้างระเบียน CNAME ของ static.example.com ที่ชี้ไปยัง example.my-cdn.com นอกจากนี้ คุณจะต้องเขียน URL ของทรัพยากรที่ CDN บริการให้ชี้ไปยังโดเมนย่อย static.example.com ที่คุณสร้าง

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

การปรับปรุงอัตราส่วนการค้นพบแคช

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

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

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

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

การตรวจสอบขั้นต้น

CDN ส่วนใหญ่จะให้ข้อมูลการวิเคราะห์แคช นอกจากนี้ คุณยังใช้เครื่องมือต่างๆ เช่น WebPageTest และ Lighthouse เพื่อตรวจสอบอย่างรวดเร็วว่ามีการแคชทรัพยากรแบบคงที่ทั้งหมดของหน้าเว็บไว้เป็นระยะเวลาที่ถูกต้องได้ด้วย ซึ่งทำได้โดยการตรวจสอบส่วนหัวแคช HTTP ของทรัพยากรแต่ละรายการ การแคชทรัพยากรโดยใช้ Time To Live (TTL) ที่เหมาะสมสูงสุดจะหลีกเลี่ยงการดึงข้อมูลต้นทางที่ไม่จำเป็นในอนาคต ดังนั้นจึงเพิ่ม CHR

โดยปกติแล้ว อย่างน้อย 1 ส่วนหัวจะต้องมีการตั้งค่าเพื่อให้ CDN แคชทรัพยากร

• Cache-Control: max-age=
• Cache-Control: s-maxage=
• Expires

นอกจากนี้ แม้ว่า CDN จะไม่ส่งผลกระทบต่อการแคชทรัพยากรหรือวิธีการแคชทรัพยากร แต่ก็ถือเป็นแนวทางปฏิบัติที่ดีที่จะตั้งค่าคำสั่ง Cache-Control: immutable ด้วยCache-Control: immutable ระบุว่าทรัพยากร "จะไม่อัปเดตในระหว่างอายุการใช้งานของความใหม่" ดังนั้น เบราว์เซอร์จะไม่ตรวจสอบความถูกต้องของทรัพยากรอีกครั้งเมื่อแสดงผลทรัพยากรจากแคชของเบราว์เซอร์ และขจัดคำขอเซิร์ฟเวอร์ที่ไม่จำเป็น ขออภัย คำสั่งนี้สนับสนุนโดย Firefox และ Safari เท่านั้น เนื่องจากไม่มีการสนับสนุนในเบราว์เซอร์แบบ Chromium ปัญหานี้ติดตามการสนับสนุนของ Chromium สำหรับ Cache-Control: immutable การติดดาวปัญหานี้ช่วยส่งเสริมให้มีการสนับสนุนฟีเจอร์นี้ได้

สำหรับคำอธิบายโดยละเอียดเกี่ยวกับการแคช HTTP โปรดอ่านป้องกันคำขอของเครือข่ายที่ไม่จำเป็นด้วยแคช HTTP

การปรับแต่ง

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

พารามิเตอร์การค้นหา

โดยค่าเริ่มต้น CDN จะพิจารณาพารามิเตอร์การค้นหาเมื่อแคชทรัพยากร อย่างไรก็ตาม การปรับเปลี่ยนเล็กๆ น้อยๆ ในการจัดการพารามิเตอร์การค้นหาอาจส่งผลต่อ CHR ได้อย่างมาก เช่น

• พารามิเตอร์การค้นหาที่ไม่จำเป็น

  โดยค่าเริ่มต้น CDN จะแคช example.com/blog และ example.com/blog?referral_id=2zjk แยกกัน แม้ว่าน่าจะเป็นทรัพยากรที่สำคัญเหมือนกัน ซึ่งแก้ไขได้โดยการปรับการกำหนดค่าของ CDN ให้ละเว้นพารามิเตอร์การค้นหา referral\_id

• ลำดับของพารามิเตอร์การค้นหา

  CDN จะแคช example.com/blog?id=123&query=dogs แยกจาก example.com/blog?query=dogs&id=123 สำหรับเว็บไซต์ส่วนใหญ่ ลำดับของพารามิเตอร์การค้นหาไม่มีผลสำคัญ ดังนั้นการกำหนดค่า CDN เพื่อจัดเรียงพารามิเตอร์การค้นหา (ซึ่งจะทำให้ URL ที่ใช้ในการแคชการตอบสนองของเซิร์ฟเวอร์เป็นมาตรฐาน) จะเพิ่ม CHR

สับเปลี่ยน

ส่วนหัวการตอบกลับ Vary จะแจ้งแคชว่าการตอบกลับของเซิร์ฟเวอร์ที่สอดคล้องกับ URL หนึ่งๆ อาจแตกต่างกันไปโดยขึ้นอยู่กับส่วนหัวที่กำหนดไว้ในคำขอ (เช่น ส่วนหัวของคำขอ accept-Language หรือ Accept-Encrypting) ด้วยเหตุนี้ CDN จะสั่งให้ CDN แคชการตอบกลับเหล่านี้แยกต่างหาก CDN ยังไม่รองรับส่วนหัว Vary อย่างกว้างขวาง และอาจส่งผลให้ทรัพยากรที่แคชได้ไม่ได้แสดงจากแคช

แม้ว่าส่วนหัว Vary จะเป็นเครื่องมือที่มีประโยชน์ แต่การใช้งานที่ไม่เหมาะสมจะส่งผลเสียต่อ CHR นอกจากนี้ หากคุณใช้ Vary การปรับส่วนหัวของคำขอให้เป็นมาตรฐานจะช่วยปรับปรุง CHR ด้วย เช่น หากไม่ทำการปรับให้เป็นมาตรฐาน ส่วนหัวของคำขอ Accept-Language: en-US และ Accept-Language: en-US,en;q=0.9 จะทำให้มีรายการแคชแยกกัน 2 รายการ แม้ว่าเนื้อหาจะเหมือนกันก็ตาม

คุกกี้

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

ฟีเจอร์ด้านประสิทธิภาพ

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

การบีบอัด

การตอบกลับที่เป็นข้อความทั้งหมดควรบีบอัดด้วย gzip หรือ Brotli หากต้องการ ให้เลือก Brotli ผ่าน gzip Brotli เป็นอัลกอริทึมการบีบอัดที่ใหม่กว่า และเมื่อเปรียบเทียบกับ gzip ก็จะมีอัตราส่วนการบีบอัดที่สูงกว่า

การรองรับ CDN สำหรับการบีบอัด Brotli มีอยู่ 2 ประเภท ได้แก่ "Brotli จากต้นทาง" และ "การบีบอัด Brotli อัตโนมัติ"

Brotli จากต้นทาง

Brotli จากต้นทางเกิดขึ้นเมื่อ CDN แสดงทรัพยากรที่ต้นทางบีบอัด Brotli แม้ว่านี่อาจดูเหมือนว่าเป็นฟีเจอร์ที่ CDN ทั้งหมดควรรองรับได้ตั้งแต่เริ่มต้น แต่ CDN ก็จำเป็นต้องแคชทรัพยากรหลายเวอร์ชัน (กล่าวคือ เวอร์ชันที่บีบอัดด้วย gzip และ Brotli) ของทรัพยากรที่สอดคล้องกับ URL ที่ระบุ

การบีบอัด Brotli อัตโนมัติ

การบีบอัด Brotli อัตโนมัติเกิดขึ้นเมื่อทรัพยากรถูกบีบอัดโดย CDN ของ Brotli CDN สามารถบีบอัดทั้งทรัพยากรที่แคชได้และที่แคชไม่ได้

ครั้งแรกที่มีการขอทรัพยากร ระบบจะแสดงโดยใช้การบีบอัดที่ "ดีพอ" เช่น Brotli-5 การบีบอัดประเภทนี้ใช้ได้กับทั้งทรัพยากรที่แคชได้และที่แคชไม่ได้

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

แนวทางปฏิบัติแนะนำในการบีบอัด

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

TLS 1.3

TLS 1.3 คือ Transport Layer Security (TLS) เวอร์ชันใหม่ล่าสุด ซึ่งเป็นโปรโตคอลการเข้ารหัสที่ HTTPS ใช้ TLS 1.3 ให้ความเป็นส่วนตัวและประสิทธิภาพที่ดีกว่าเมื่อเทียบกับ TLS 1.2

TLS 1.3 จะลดแฮนด์เชค TLS จาก 2 รอบเหลือเพียง 1 รอบ สำหรับการเชื่อมต่อที่ใช้ HTTP/1 หรือ HTTP/2 การลดแฮนด์เชค TLS ให้เหลือเพียง 1 รอบจะลดเวลาในการตั้งค่าการเชื่อมต่อลง 33% ได้อย่างมีประสิทธิภาพ

HTTP/2 และ HTTP/3

ทั้ง HTTP/2 และ HTTP/3 มีข้อดีด้านประสิทธิภาพมากกว่า HTTP/1 จากทั้ง 2 ประเภท HTTP/3 ให้ประโยชน์ด้านประสิทธิภาพที่เป็นไปได้มากกว่า HTTP/3 ยังไม่ได้เป็นมาตรฐานที่สมบูรณ์ แต่จะรองรับในวงกว้างเมื่อเกิดเหตุการณ์นี้

HTTP/2

หาก CDN ยังไม่ได้เปิดใช้ HTTP/2 โดยค่าเริ่มต้น คุณควรพิจารณาเปิด HTTP/2 มีประโยชน์ด้านประสิทธิภาพหลายอย่างที่เหนือกว่า HTTP/1 และรองรับในเบราว์เซอร์หลักๆ ทั้งหมด ฟีเจอร์ประสิทธิภาพของ HTTP/2 ประกอบด้วย Multiplexing การจัดลําดับความสําคัญของสตรีม และการบีบอัดส่วนหัว

• การทำ Multiplex

  เราสามารถพูดได้เต็มปากว่าการทำ Multiplex เป็นฟีเจอร์ที่สำคัญที่สุดของ HTTP/2 การมัลติเพล็กซ์ช่วยให้การเชื่อมต่อ TCP เดียวสามารถแสดงคู่คำขอตอบกลับหลายรายการพร้อมกันได้ ทำให้ไม่ต้องเสียเวลาไปกับการตั้งค่าการเชื่อมต่อที่ไม่จำเป็น เนื่องจากเบราว์เซอร์สามารถเปิดในจำนวนการเชื่อมต่อได้ในช่วงเวลาหนึ่งๆ จึงมีนัยยะว่าตอนนี้เบราว์เซอร์จะสามารถขอทรัพยากรของหน้าเว็บได้มากขึ้นพร้อมๆ กัน ในทางทฤษฎีแล้ว การใช้ Multiplex ลดความจำเป็นในการเพิ่มประสิทธิภาพ HTTP/1 เช่น การต่อภาพและสไปรท์ชีต แต่ในทางปฏิบัติ เทคนิคเหล่านี้จะยังคงเหมาะสมเนื่องจากไฟล์ที่มีขนาดใหญ่จะบีบอัดได้ดีกว่า

• การจัดลำดับความสำคัญของสตรีม

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

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

การใช้งาน CDN ของการจัดลำดับความสำคัญของทรัพยากร HTTP/2 จะแตกต่างกันไปอย่างมาก หากต้องการระบุว่า CDN ของคุณรองรับการจัดลำดับความสำคัญของทรัพยากร HTTP/2 อย่างถูกต้องสมบูรณ์หรือไม่ โปรดดูHTTP/2 ยังเร็วไหม

แม้ว่าการเปลี่ยนอินสแตนซ์ CDN เป็น HTTP/2 นั้นส่วนใหญ่จะเป็นเรื่องที่ต้องสลับสวิตช์ แต่ก็ควรทดสอบการเปลี่ยนแปลงนี้อย่างละเอียดก่อนเปิดใช้ในเวอร์ชันที่ใช้งานจริง HTTP/1 และ HTTP/2 ใช้รูปแบบเดียวกันสำหรับส่วนหัวของคำขอและการตอบกลับ แต่ HTTP/2 นั้นให้อภัยน้อยกว่ามากเมื่อไม่เป็นไปตามแบบแผนเหล่านี้ ดังนั้น การปฏิบัติที่ไม่ตรงตามข้อกำหนด เช่น การรวมอักขระที่ไม่ใช่ ASCII หรือตัวพิมพ์ใหญ่ในส่วนหัวอาจเริ่มทำให้เกิดข้อผิดพลาดเมื่อเปิดใช้ HTTP/2 หากเกิดกรณีนี้ เบราว์เซอร์จะพยายามดาวน์โหลดทรัพยากรไม่สำเร็จ การดาวน์โหลดที่ไม่สำเร็จจะปรากฏในแท็บ "เครือข่าย" ของเครื่องมือสำหรับนักพัฒนาเว็บ นอกจากนี้ ข้อความแสดงข้อผิดพลาด "ERR_HTTP2_PROTOCOL_ERROR" จะปรากฏในคอนโซลด้วย

HTTP/3

HTTP/3 จะสืบทอดมาจาก HTTP/2 ตั้งแต่เดือนกันยายน 2020 เบราว์เซอร์หลักทั้งหมดจะมีการรองรับ HTTP/3 เวอร์ชันทดลองสำหรับ HTTP/3 และ CDN บางส่วนรองรับด้วย ประสิทธิภาพคือประโยชน์หลักของ HTTP/3 บน HTTP/2 กล่าวอย่างเจาะจงคือ HTTP/3 ขจัดการบล็อกบรรทัดแรกในระดับการเชื่อมต่อและลดเวลาในการตั้งค่าการเชื่อมต่อ

• ขจัดการบล็อกบรรทัดแรก

  HTTP/2 เปิดตัวการทำ Multiplex ซึ่งเป็นฟีเจอร์ที่ช่วยให้สามารถใช้การเชื่อมต่อแบบเดี่ยวเพื่อส่งสตรีมข้อมูลหลายๆ สายพร้อมกันได้ อย่างไรก็ตาม เมื่อใช้ HTTP/2 แพ็กเก็ตแบบดรอปแพ็กเดียวจะบล็อกสตรีมทั้งหมดบนการเชื่อมต่อ (เป็นปรากฏการณ์ที่เรียกว่าการบล็อกบรรทัดแรก) เมื่อใช้ HTTP/3 แพ็กเก็ตที่ปล่อยลงจะบล็อกสตรีมเพียงสตรีมเดียวเท่านั้น การปรับปรุงนี้เป็นผลมาจาก HTTP/3 ที่ใช้ UDP (HTTP/3 ใช้ UDP ผ่าน QUIC) มากกว่า TCP ซึ่งทำให้ HTTP/3 มีประโยชน์อย่างยิ่งสำหรับการโอนข้อมูลผ่านเครือข่ายที่แออัดหรือสูญเสียข้อมูล

• ลดเวลาในการตั้งค่าการเชื่อมต่อ

  HTTP/3 ใช้ TLS 1.3 จึงแชร์ประโยชน์ด้านประสิทธิภาพต่างๆ กัน กล่าวคือ การสร้างการเชื่อมต่อใหม่ต้องใช้การไป-กลับเพียงครั้งเดียวเท่านั้น และการกลับมาเชื่อมต่อเดิมต่อไม่จำเป็นต้องมีการรับส่งข้อมูลไปกลับ

HTTP/3 จะส่งผลกระทบต่อผู้ใช้มากที่สุดเมื่อมีการเชื่อมต่อเครือข่ายที่ไม่ดี ไม่เพียงเพราะ HTTP/3 จัดการการสูญเสียแพ็กเก็ตได้ดีกว่ารุ่นก่อนๆ เท่านั้น แต่ยังเป็นเพราะการประหยัดเวลาสัมบูรณ์อันเป็นผลมาจากการตั้งค่าการเชื่อมต่อ 0-RTT หรือ 1 - RTT จะมากกว่าในเครือข่ายที่มีเวลาในการตอบสนองสูง

การเพิ่มประสิทธิภาพรูปภาพ

บริการเพิ่มประสิทธิภาพรูปภาพ CDN มักเน้นที่การเพิ่มประสิทธิภาพรูปภาพซึ่งสามารถนำไปใช้โดยอัตโนมัติเพื่อลดขนาดการโอนรูปภาพได้ เช่น การตัดข้อมูล EXIF, ใช้การบีบอัดแบบไม่สูญเสียรายละเอียด และการแปลงรูปภาพเป็นรูปแบบไฟล์ที่ใหม่กว่า (เช่น WebP) รูปภาพคิดเป็นประมาณ 50% ของไบต์การโอนบนหน้าเว็บค่ามัธยฐาน ดังนั้นการเพิ่มประสิทธิภาพรูปภาพจึงสามารถลดขนาดหน้าเว็บลงได้อย่างมาก

การลดขนาด

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

บทสรุป

• ใช้ CDN: CDN จะส่งทรัพยากรอย่างรวดเร็ว ลดภาระงานในเซิร์ฟเวอร์ต้นทาง และมีประโยชน์ในการจัดการกับปริมาณการรับส่งข้อมูลที่เพิ่มขึ้นอย่างรวดเร็ว
• แคชเนื้อหาให้เร็วที่สุด: ทั้งเนื้อหาแบบคงที่และแบบไดนามิกสามารถและควรแคชได้ แม้จะมีระยะเวลาต่างกันก็ตาม ตรวจสอบเว็บไซต์เป็นระยะๆ เพื่อให้มั่นใจว่าคุณแคชเนื้อหาอย่างเหมาะสม
• เปิดใช้ฟีเจอร์ด้านประสิทธิภาพของ CDN: ฟีเจอร์ต่างๆ เช่น Brotli, TLS 1.3, HTTP/2 และ HTTP/3 จะช่วยปรับปรุงประสิทธิภาพให้ดียิ่งขึ้น