במקרה לדוגמה הזה אנחנו מדגישים איך שיפור הביצועים של מקורות מידע מצד שלישי יכול לשפר את המדדים העסקיים. במחקר קודם נמדדה העלות של זמן האחזור שנוסף למודעות, אבל המחקר הזה מדגים את הערך של שיפור הביצועים בעולם האמיתי:
0.5%
עלייה בהכנסות של בעלי תוכן דיגיטלי
2%
עלייה במספר הטעינות המוקדמות של סקריפטים של מודעות
מקור: נתונים פנימיים של Google, יוני עד יולי 2019.
רקע
Google Publisher Tag (GPT) הוא סקריפט לתיוג מודעות ב-Google Ad Manager, שמבקש ומציג מודעות לרשת המדיה באינטרנט. הטמעת כותרת HTTP של stale-while-revalidate ב-GPT אפשרה לצוות GPT לשפר את המהירות והביצועים של מודעות לרשת המדיה של Google עבור שותפי התוכן שלה. אפשר להשתמש באותה טכניקה בכל תרחיש אחר שבו חשוב יותר לטעון סקריפטים כמה שיותר מהר מאשר לטעון את הקוד העדכני ביותר.
הבעיה
GPT נפרס כסקריפט bootstrapping, gpt.js, שמוגדר לו אורך חיים (TTL) קצר של 15 דקות. ערך ה-TTL הקצר מאפשר לעדכן את הסקריפט או לבטל את העדכון שלו במהירות. אחרי הטעינה, gpt.js מבקש וטוען סקריפטים נוספים להטמעה, עם TTL ארוך יותר.
אחרי שפג תוקף ה-TTL של 15 דקות, הגרסה של gpt.js במטמון הופכת ללא עדכנית וצריך לאמת אותה מחדש. בעבר, תהליך האימות מחדש הזה כלל שליחת בקשת רשת סינכרונית כדי לאחזר עותק חדש של הסקריפט, מה שהוסיף זמן אחזור לבקשה הראשונה להצגת מודעה.
הפתרון
המאפיין stale-while-revalidate משמש את הכותרת Cache-Control ומגדיר חלון זמן נוסף שבמהלכו מטמון יכול להשתמש בנכס לא עדכני בזמן שהנכס עובר אימות מחדש באופן אסינכרוני. כך המפתחים יכולים למצוא את האיזון בין מיידיות – טעינת תוכן שמור במטמון באופן מיידי – לבין עדכניות – הבטחה שבעתיד ייעשה שימוש בעדכונים של התוכן השמור במטמון.
מקרה לדוגמה של מודעות לרשת המדיה של 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 בסקריפטים של מודעות. במהלך שבועיים של רישום מדדים ממדגם של 5.2 מיליארד חשיפות של מודעות לרשת המדיה של Google, נצפו בקבוצת הבקרה:
- עלייה של 0.3% במספר החשיפות של המודעות.
- עלייה של 0.5% בהכנסות.
- עלייה של 2% בטעינות מוקדמות של סקריפטים של מודעות (פחות מ-500 אלפיות השנייה מתחילת טעינת הדף).
- עלייה של 1.1% בטעינות מוצלחות של סקריפטים של מודעות באופן כללי.
כפי שמוצג בתרשים, אפשר לשייך את תוצאות הניסוי הזה לעלייה במספר הטעינות המוצלחות של סקריפטים של מודעות, כאשר רוב הטעינות מתרחשות בשלב מוקדם בתהליך טעינת הדף.
הטמעה של stale-while-revalidate באתר
צוות GPT גילה ששינוי קטן יחסית בכותרות HTTP עם stale-while-revalidate יכול לשפר את המהירות ולשפר את המדדים העסקיים. במאמר שמירה על עדכניות באמצעות stale-while-revalidate יש מידע נוסף על הטמעה של stale-while-revalidate באתר שלכם.