כאן מוסבר איך טעינה מהירה יותר של משאבים של צד שלישי יכולה להגדיל את ההכנסות.
המקרה לדוגמה הזה מראה איך שיפור הביצועים של מקורות מידע מצד שלישי יכול לשפר את המדדים העסקיים. במחקר קודם נמדד העלות של זמן אחזור של הוספה של מודעות, אבל המחקר הזה ממחיש את הערך של שיפור בביצועים בעולם האמיתי:
0.5%
עלייה בהכנסות של בעלי תוכן דיגיטלי
2%
עלייה בטעינות המוקדמות של הסקריפט של המודעה
מקור: נתונים פנימיים של Google, יוני עד יולי 2019.
רקע
תג Google Publisher Tag (GPT) הוא סקריפט תיוג המודעה של Google Ad Manager, ששולח בקשות ומעבד מודעות לרשת המדיה באינטרנט. על ידי הטמעת כותרת HTTP פשוטה stale-while-revalidate
עבור GPT, צוות GPT הצליח לשפר את המהירות ואת הביצועים של מודעות לרשת המדיה של Google עבור בעלי התוכן הדיגיטלי השותפים. אפשר להשתמש בשיטה הזו בכל תרחיש אחר שבו חשוב יותר לטעון סקריפטים במהירות האפשרית, מאשר טעינת הקוד העדכני ביותר.
הבעיה
GPT נפרס כסקריפט לאתחול, 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% מהתנועה הושבתה זמנית ב-Chrome כדי למדוד את השפעתה. צוות 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
באתר שלכם זמין בפוסט שמירה על רעננות באמצעות אימות לא פעיל בזמן אימות מחדש.