ทรัพยากรบุคคลที่สามที่โฮสต์ด้วยตนเอง: ดี, แย่, น่าเกลียด

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

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

ดี: ปรับปรุงประสิทธิภาพ

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

ทรัพยากรของบุคคลที่สามถูกดาวน์โหลดจากแหล่งภายนอก (นำมาจาก ด้วยเหตุนี้)

ทรัพยากรของบุคคลที่สามจะถูกจัดเก็บไว้ในที่เดียวกับเนื้อหาส่วนที่เหลือของไซต์ (นำมาจาก ด้วยเหตุนี้)

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

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

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

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

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

คุณยังสามารถขยาย TTL สำหรับทรัพยากรเป็นหนึ่งปีได้ด้วยการรวมเนื้อหาที่เกี่ยวข้องเข้ากับกลยุทธ์การจัดการแคชของคุณ (แฮช URL, การกำหนดเวอร์ชัน ฯลฯ) เราจะพูดถึงเรื่องนี้ด้านล่าง

▍ป้องกันการหยุดชะงักในการทำงานของบริการของบุคคลที่สามหรือการปิดระบบ

อีกแง่มุมที่น่าสนใจของการโฮสต์ทรัพยากรของบุคคลที่สามด้วยตนเองก็คือ ช่วยให้คุณสามารถลดความเสี่ยงที่เกี่ยวข้องกับการหยุดให้บริการของบุคคลที่สามได้ สมมติว่าโซลูชันการทดสอบ A/B ของบุคคลที่สามที่คุณใช้อยู่นั้นมีการใช้งานเป็นสคริปต์บล็อกที่โหลดในส่วนหัวของหน้า สคริปต์นี้โหลดช้า หากไม่สามารถโหลดสคริปต์ที่เกี่ยวข้อง หน้านั้นจะว่างเปล่า หากใช้เวลาโหลดนานมาก หน้าเว็บก็จะปรากฏขึ้นพร้อมกับการดีเลย์นาน หรือสมมติว่าโปรเจ็กต์ใช้ไลบรารีที่โหลดจากทรัพยากร CDN ของบริษัทอื่น ลองจินตนาการว่าทรัพยากรนี้ประสบความล้มเหลวหรือถูกบล็อกในบางประเทศ สถานการณ์ดังกล่าวจะนำไปสู่การละเมิดตรรกะของไซต์

หากต้องการทราบว่าเว็บไซต์ของคุณทำงานอย่างไรเมื่อบริการภายนอกบางอย่างไม่พร้อมใช้งาน คุณสามารถใช้ส่วน SPOF ได้ เว็บไซต์test.org.

ส่วน SPOF บน webpagetest.org

▍แล้วปัญหาเกี่ยวกับการแคชเนื้อหาในเบราว์เซอร์ล่ะ? (คำใบ้: มันเป็นตำนาน)

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

สมมติว่าเรามีไซต์ต่างๆ หลายแห่ง: website1.com, website2.com, website3.com ไซต์ทั้งหมดเหล่านี้ใช้ไลบรารี jQuery เราเชื่อมต่อกับพวกเขาโดยใช้ CDN เช่น - googleapis.com คุณสามารถคาดหวังให้เบราว์เซอร์ดาวน์โหลดและแคชไลบรารีเพียงครั้งเดียว จากนั้นจึงใช้กับทั้งสามไซต์ได้ ซึ่งอาจช่วยลดภาระบนเครือข่ายได้ บางทีนี่อาจช่วยให้คุณประหยัดเงินที่ไหนสักแห่งและช่วยปรับปรุงประสิทธิภาพของทรัพยากร จากมุมมองเชิงปฏิบัติทุกอย่างดูแตกต่างออกไป ตัวอย่างเช่น Safari มีฟีเจอร์ที่เรียกว่า การป้องกันการติดตามอัจฉริยะ: แคชใช้คีย์คู่โดยอิงตามแหล่งที่มาของเอกสารและแหล่งที่มาของทรัพยากรของบุคคลที่สาม ที่นี่ บทความที่ดีในหัวข้อนี้

การศึกษาเก่า yahoo и Facebookรวมถึงล่าสุดอีกด้วย ศึกษา Paul Calvano แสดงให้เห็นว่าทรัพยากรไม่ได้จัดเก็บไว้ในแคชของเบราว์เซอร์นานเท่าที่เราคาดหวัง: “มีช่องว่างร้ายแรงระหว่างเวลาแคชของทรัพยากรของโปรเจ็กต์เองและของบุคคลที่สาม เรากำลังพูดถึง CSS และแบบอักษรของเว็บ กล่าวคือ 95% ของฟอนต์เนทิฟมีอายุแคชนานกว่าหนึ่งสัปดาห์ ในขณะที่ 50% ของฟอนต์ของบุคคลที่สามมีอายุแคชน้อยกว่าหนึ่งสัปดาห์! สิ่งนี้ทำให้นักพัฒนาเว็บมีเหตุผลที่น่าสนใจในการโฮสต์ไฟล์ฟอนต์ด้วยตนเอง!”

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

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

ความเลว: ปีศาจอยู่ในรายละเอียด

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

ปัญหาหลักอย่างหนึ่งที่นี่คือเวลาในการแคช ตัวอย่างเช่น ข้อมูลเวอร์ชันจะรวมอยู่ในชื่อสคริปต์ของบุคคลที่สามดังนี้: jquery-3.4.1.js. ไฟล์ดังกล่าวจะไม่เปลี่ยนแปลงในอนาคตและด้วยเหตุนี้จึงไม่ทำให้เกิดปัญหากับการแคช

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

จริงอยู่ หากเราพูดถึงเนื้อหาที่ได้รับการอัปเดตบ่อยครั้ง (ตัวจัดการแท็ก โซลูชันสำหรับการทดสอบ A/B) การแคชเนื้อหาเหล่านั้นโดยใช้เครื่องมือ CDN นั้นเป็นงานที่สามารถแก้ไขได้ แต่ซับซ้อนกว่ามาก บริการต่างๆ เช่น Commanders Act ซึ่งเป็นโซลูชันการจัดการแท็ก ใช้ webhooks เมื่อเผยแพร่เวอร์ชันใหม่ สิ่งนี้ทำให้คุณสามารถบังคับให้ล้างแคชบน CDN หรือที่ดีกว่าคือสามารถบังคับแฮชหรือการอัปเดต URL

▍การส่งมอบวัสดุแบบปรับเปลี่ยนให้กับลูกค้า

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

ที่นี่คุณสามารถจดจำสองบริการได้ อันแรกคือ googlefonts.com อันที่สองคือ polyfill.io บริการ Google Fonts มอบโค้ด CSS ต่างๆ สำหรับทรัพยากรบางอย่าง ขึ้นอยู่กับความสามารถของเบราว์เซอร์ (ให้ลิงก์ไปยังทรัพยากร woff2 โดยใช้ unicode-range).

นี่คือผลลัพธ์ของการสืบค้น Google Fonts สองสามรายการที่สร้างจากเบราว์เซอร์ที่แตกต่างกัน

ผลลัพธ์การค้นหา Google Fonts จาก Chrome

ผลลัพธ์ของการสืบค้น Google Fonts ดำเนินการจาก IE10

Polyfill.io ให้เบราว์เซอร์เฉพาะ polyfills ที่ต้องการเท่านั้น สิ่งนี้ทำเพื่อเหตุผลด้านประสิทธิภาพ

ตัวอย่างเช่น ลองมาดูว่าจะเกิดอะไรขึ้นหากคุณเรียกใช้คำขอต่อไปนี้จากเบราว์เซอร์ที่แตกต่างกัน: https://polyfill.io/v3/polyfill.js?features=default

เพื่อตอบสนองต่อคำขอดังกล่าวที่ดำเนินการจาก IE10 จะได้รับข้อมูลขนาด 34 KB และคำตอบที่ดำเนินการจาก Chrome จะว่างเปล่า

โกรธ: ข้อควรพิจารณาด้านความเป็นส่วนตัวบางประการ

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

หากระบบ CDN ของคุณไม่ได้รับการกำหนดค่าอย่างถูกต้อง คุณอาจส่งคุกกี้ของโดเมนไปยังบริการของบุคคลที่สามได้ หากการกรองที่เหมาะสมไม่ได้ถูกจัดระเบียบที่ระดับ CDN คุกกี้เซสชันของคุณ ซึ่งโดยปกติไม่สามารถใช้ใน JavaScript ได้ (ด้วย httponly) อาจถูกส่งไปยังโฮสต์ต่างประเทศ

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

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

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

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

ผลของการ

หากคุณกำลังวางแผนที่จะใช้การโฮสต์ด้วยตนเองสำหรับทรัพยากรของบุคคลที่สามในเร็วๆ นี้ ให้ฉันให้คำแนะนำแก่คุณ:

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

เรียนผู้อ่าน! คุณโฮสต์เนื้อหาของผู้อื่นบนเซิร์ฟเวอร์ของคุณซึ่งมีความสำคัญอย่างยิ่งต่อการดำเนินโครงการของคุณหรือไม่?

ที่มา: will.com