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