איך טעינת משאבים של צד שלישי מהר יותר יכולה להגדיל את ההכנסות
בניתוח המקרה הזה נסביר איך שיפור הביצועים של משאבים של צד שלישי יכול לשפר את המדדים העסקיים. במחקר קודם נמדד העלות של זמן אחזור ארוך יותר של מודעות, אבל במחקר הזה אנחנו מראים את הערך של שיפור הביצועים בעולם האמיתי:
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 דקות אחרי הערך הקודם ששמור במטמון, המערכת תשתמש בערך ששמור במטמון כדי למלא את הבקשה, גם אם הוא לא עדכני. במקביל, תישלח בקשה לאימות מחדש ברקע כדי לאכלס את המטמון בערך חדש לשימוש עתידי.
השקנו את stale-while-revalidate בגרסת 75 של Chrome ל-99% מכל התנועה, והשארנו 1% מהתנועה עם התכונה מושבתת באופן זמני כדי למדוד את ההשפעה שלה. כדי לבדוק את היעילות של stale-while-revalidate בסקריפטים של מודעות, צוות GPT תיעד מדדים מ-1% מהתנועה הזו (קבוצת הניסוי) וגם מ-1% מדגימת התנועה שבה התכונה מופעלת (קבוצת הבקרה). במהלך שבועיים של תיעוד מדדים מדגימה של 5.2 מיליארד חשיפות של מודעות לרשת המדיה של Google, בקבוצת הבקרה נצפו:
- עלייה של 0.3% במספר החשיפות של המודעות.
- עלייה של 0.5% בהכנסות.
- עלייה של 2% בטעינות מוקדמות של סקריפטים של מודעות (פחות מ-500 אלפיות השנייה מתחילת טעינת הדף).
- עלייה של 1.1% במספר הטעינות המוצלחות של סקריפטים של מודעות באופן כללי.
כפי שמוצג בתרשים שלמעלה, אפשר לשייך את תוצאות הניסוי הזה לעלייה במספר הטעינות המוצלחות של סקריפטים של מודעות, כאשר רוב הטעינות מתרחשות בשלב מוקדם בתהליך טעינת הדף.
הטמעת 'לא עדכני בזמן אימות מחדש' באתר
צוות GPT ראה ששינוי פשוט יחסית בכותרות HTTP באמצעות stale-while-revalidate יכול לשפר את המהירות ולשפר את המדדים העסקיים. במאמר שמירה על עדכניות באמצעות 'לא תקף בזמן אימות מחדש' מוסבר בהרחבה איך מטמיעים את stale-while-revalidate באתר שלכם.