ดูว่าการโหลดทรัพยากรของบุคคลที่สามเร็วขึ้นช่วยเพิ่มรายได้ได้อย่างไร
กรณีศึกษานี้แสดงให้เห็นว่าการปรับปรุงประสิทธิภาพของทรัพยากรของบุคคลที่สามช่วยเพิ่มเมตริกทางธุรกิจได้อย่างไร แม้ว่าการศึกษาก่อนหน้านี้จะวัดต้นทุนของเวลาในการตอบสนองที่เพิ่มขึ้นของโฆษณา แต่การศึกษานี้แสดงให้เห็นถึงมูลค่าของการปรับปรุงประสิทธิภาพในชีวิตจริง
0.5%
การเพิ่มรายได้สำหรับผู้เผยแพร่โฆษณา
2%
การโหลดสคริปต์โฆษณาในช่วงแรกเพิ่มขึ้น
แหล่งที่มา: ข้อมูลภายในของ Google, มิถุนายนถึงกรกฎาคม 2019
ข้อมูลเบื้องต้น
แท็กผู้เผยแพร่โฆษณาผ่าน Google (GPT) คือสคริปต์การติดแท็กโฆษณาสําหรับ Google Ad Manager ที่ขอและแสดงผลโฆษณา Display บนเว็บ การใช้ส่วนหัว HTTP stale-while-revalidate ง่ายๆ สําหรับ GPT ทําให้ทีม GPT ปรับปรุงความเร็วและประสิทธิภาพของโฆษณา Display ของ Google สําหรับพาร์ทเนอร์ผู้เผยแพร่โฆษณาได้ เทคนิคเดียวกันนี้สามารถใช้ได้กับสถานการณ์อื่นๆ ที่การโหลดสคริปต์ให้เร็วที่สุดมีความสำคัญมากกว่าการโหลดโค้ดใหม่ล่าสุด
ปัญหา
GPT ติดตั้งใช้งานเป็นสคริปต์การเริ่มต้นระบบ gpt.js ซึ่งมี TTL สั้นๆ เพียง 15 นาที TTL ที่สั้นนี้ช่วยให้อัปเดตหรือเปลี่ยนกลับสคริปต์ได้อย่างรวดเร็ว เมื่อโหลดแล้ว gpt.js จะส่งคำขอและโหลดสคริปต์การใช้งานเพิ่มเติมซึ่งมี TTL ขนาดยาว
เมื่อ TTL 15 นาทีหมดอายุ เวอร์ชันของ gpt.js ในแคชจะล้าสมัยและต้องมีการตรวจสอบความถูกต้องอีกครั้ง ก่อนหน้านี้ กระบวนการตรวจสอบอีกครั้งนี้เกี่ยวข้องกับการส่งคําขอเครือข่ายแบบซิงค์เพื่อดึงข้อมูลสคริปต์สําเนาใหม่ ซึ่งจะเพิ่มเวลาในการตอบสนองของคําขอโฆษณาแรก
การแก้ปัญหา
ส่วนหัว Cache-Control จะใช้แอตทริบิวต์ stale-while-revalidate และกำหนดกรอบเวลาเพิ่มเติมในระหว่างที่แคชสามารถใช้ชิ้นงานที่ล้าสมัยได้ขณะที่ชิ้นงานได้รับการตรวจสอบอีกครั้งแบบไม่พร้อมกัน ซึ่งจะช่วยให้นักพัฒนาแอปมีความสมดุลระหว่างความรวดเร็วในการโหลด นั่นคือการโหลดเนื้อหาที่แคชไว้ทันที กับความใหม่ของเนื้อหา นั่นคือการทำให้มั่นใจว่าเนื้อหาที่แคชไว้ได้รับการอัปเดตในอนาคต
กรณีศึกษาของโฆษณา Display ของ Google
ทีม GPT ได้เพิ่มส่วนหัว Cache-Control นี้ในการตอบสนอง HTTP ของ gpt.js ในปี 2016 ซึ่งคาดว่าเบราว์เซอร์ที่ใช้ stale-while-revalidate มีดังต่อไปนี้
cache-control: private, max-age=900, stale-while-revalidate=3600
การตั้งค่านี้หมายความว่าหากมีการขอ gpt.js ระหว่าง 15 ถึง 60 นาทีหลังจากค่าแคชก่อนหน้า ระบบจะใช้ค่าแคชเพื่อตอบสนองคําขอ แม้ว่าค่าดังกล่าวจะล้าสมัยแล้วก็ตาม ในขณะเดียวกัน จะมีการส่งคำขอการตรวจสอบอีกครั้งในเบื้องหลังเพื่อเติมค่าแคชใหม่เพื่อใช้ในอนาคต
Chrome เปิดตัว stale-while-revalidate ในเวอร์ชัน 75 กับการเข้าชมทั้งหมด 99% โดยปิดใช้ฟีเจอร์นี้กับการเข้าชม 1% เป็นการชั่วคราวเพื่อวัดผล ทีม GPT ได้บันทึกเมตริกจาก 1% นี้ (กลุ่มทดสอบ) รวมถึงตัวอย่างการเข้าชม 1% ที่เปิดใช้ฟีเจอร์ (กลุ่มควบคุม) เพื่อทดสอบประสิทธิภาพของ stale-while-revalidate สำหรับสคริปต์โฆษณา ตลอดระยะเวลา 2 สัปดาห์ที่บันทึกเมตริกจากตัวอย่างการแสดงโฆษณา Display ของ Google จำนวน 5.2 พันล้านครั้ง กลุ่มควบคุมสังเกตเห็นสิ่งต่อไปนี้
- การแสดงโฆษณาเพิ่มขึ้น 0.3%
- รายได้เพิ่มขึ้น 0.5%
- การโหลดสคริปต์โฆษณาล่วงหน้าเพิ่มขึ้น 2% (<500 มิลลิวินาทีนับจากเริ่มโหลดหน้าเว็บ)
- โหลดสคริปต์โฆษณาสําเร็จโดยรวมเพิ่มขึ้น 1.1%
ดังที่แสดงในแผนภูมิด้านบน ผลการทดสอบนี้เป็นผลมาจากการโหลดสคริปต์โฆษณาที่ประสบความสําเร็จเพิ่มขึ้น โดยส่วนใหญ่เกิดขึ้นในช่วงต้นของกระบวนการโหลดหน้าเว็บ
การใช้สถานะ "ล้าสมัยขณะกำลังตรวจสอบอีกครั้ง" ในเว็บไซต์
ทีม GPT พบว่าการเปลี่ยนแปลงส่วนหัว HTTP ด้วย stale-while-revalidate นั้นทําได้ง่ายๆ และช่วยเพิ่มความเร็วและเมตริกทางธุรกิจได้ ดูข้อมูลเพิ่มเติมเกี่ยวกับการใช้ stale-while-revalidate ในเว็บไซต์ของคุณเองได้จากโพสต์การอัปเดตข้อมูลอยู่เสมอด้วยสถานะ "ล้าสมัยขณะกำลังตรวจสอบอีกครั้ง"