גלו איך טעינה מהירה יותר של משאבים של צד שלישי יכולה להגדיל את ההכנסות.
מקרה לדוגמה שממחיש איך שיפור הביצועים של מקורות מידע של צד שלישי יכול לשפר את המדדים העסקיים. במחקר קודם נמדדו העלות של זמן אחזור נוסף של הצגת מודעות, אבל המחקר הזה ממחיש את הערך של שיפור הביצועים בעולם האמיתי:
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% מהתנועה כדי למדוד את ההשפעה שלה. צוות 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 באתר שלך זמין בפוסט שמירה על עדכניות בעזרת הסטטוס 'לא פעיל בזמן אימות מחדש'.