ดูว่าการโหลดทรัพยากรของบุคคลที่สามเร็วขึ้นจะช่วยเพิ่มรายได้ได้อย่างไร
กรณีศึกษานี้แสดงให้เห็นว่าการปรับปรุงประสิทธิภาพของทรัพยากรของบุคคลที่สามช่วยเพิ่มเมตริกทางธุรกิจได้อย่างไร แม้ว่าการศึกษาก่อนหน้านี้จะวัดต้นทุนของเวลาในการตอบสนองของโฆษณาที่เพิ่มขึ้น แต่การศึกษานี้แสดงให้เห็นถึงมูลค่าของการปรับปรุงประสิทธิภาพในชีวิตจริง
0.5%
รายได้เพิ่มขึ้นสำหรับผู้เผยแพร่โฆษณา
2%
การโหลดสคริปต์โฆษณาในช่วงต้นเพิ่มขึ้น
แหล่งที่มา: ข้อมูลภายในของ Google, มิถุนายนถึงกรกฎาคม 2019
ฉากหลัง
แท็กผู้เผยแพร่โฆษณาผ่าน Google (GPT) คือสคริปต์การติดแท็กโฆษณาสําหรับ Google Ad Manager ที่จะขอและแสดงผลโฆษณา Display บนเว็บ การใช้ส่วนหัว HTTP stale-while-revalidate ง่ายๆ สําหรับ GPT ทําให้ทีม GPT ปรับปรุงความเร็วและประสิทธิภาพของโฆษณา Display ของ Google สําหรับพาร์ทเนอร์ผู้เผยแพร่โฆษณาได้ เทคนิคเดียวกันนี้สามารถใช้กับสถานการณ์อื่นๆ ในกรณีที่การโหลดสคริปต์ให้เร็วที่สุดสำคัญกว่าการโหลดโค้ดล่าสุด
ปัญหา
GPT ติดตั้งใช้งานเป็นสคริปต์การเริ่มต้นระบบ gpt.js ซึ่งมี Time to Live (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 สัปดาห์ที่บันทึกเมตริกจากขนาดกลุ่มตัวอย่าง 5.2 พันล้านการแสดงโฆษณา Display ของ Google กลุ่มควบคุมสังเกตเห็นสิ่งต่อไปนี้
- การแสดงโฆษณาเพิ่มขึ้น 0.3%
- รายได้เพิ่มขึ้น 0.5%
- การโหลดสคริปต์โฆษณาในช่วงต้นเพิ่มขึ้น 2% (<500 มิลลิวินาทีนับจากเริ่มการโหลดหน้าเว็บ)
- โหลดสคริปต์โฆษณาสําเร็จโดยรวมเพิ่มขึ้น 1.1%
ดังที่แสดงในแผนภูมิด้านบน ผลการทดสอบนี้เป็นผลมาจากการโหลดสคริปต์โฆษณาที่ประสบความสําเร็จเพิ่มขึ้น โดยส่วนใหญ่เกิดขึ้นในช่วงต้นของกระบวนการโหลดหน้าเว็บ
การใช้สถานะ "ล้าสมัยขณะกำลังตรวจสอบอีกครั้ง" ในเว็บไซต์
ทีม GPT พบว่าการเปลี่ยนแปลงส่วนหัว HTTP ด้วย stale-while-revalidate นั้นทําได้ง่ายๆ และช่วยเพิ่มความเร็วและเมตริกทางธุรกิจได้ ดูข้อมูลเพิ่มเติมเกี่ยวกับการใช้ stale-while-revalidate ในเว็บไซต์ของคุณเองได้จากโพสต์การอัปเดตข้อมูลอยู่เสมอด้วยสถานะ "ล้าสมัยขณะกำลังตรวจสอบอีกครั้ง"