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