איך PubConsent CMP הפחיתה את ערך ה-INP של הלקוחות בשיעור של עד 64% באמצעות אסטרטגיית תפוקה שמתבססת על ממשקי Scheduler API של הדפדפן כדי לפתור בעיות שקשורות לתגובות שזוהו באמצעות כלי הפיתוח ל-Chrome.
פלטפורמות לניהול הסכמה (CMP) הן כלים שעוזרים לאתרים לפעול בהתאם לתקנות בנושא פרטיות, באמצעות קבלת הסכמה מהמשתמשים לשימוש בקובצי cookie ובטכנולוגיות מעקב. בנוסף למטרה העיקרית של ההבטחת תאימות משפטית, פלטפורמות CMP, כמו סקריפטים של צד שלישי, חייבות גם להבטיח השפעה מינימלית על הביצועים ועל חוויית המשתמש.
PubConsent CMP הוא המוצר החדש ביותר של PubTech. פלטפורמת PubConsent מתמקדת בעיקר בביצועים, והיא נועדה להיות פשוטה, מה שמבטיח חוויית משתמש אופטימלית והשפעה מינימלית על הביצועים הכוללים של האתר.
השקת המדד Interaction to Next Paint (INP) אפשרה ל-PubTech לזהות בעיות שקשורות לתגובתיות של פלטפורמת ה-CMP. במקרה לדוגמה הזה, אנשי PubTech מוכיחים איך הם פתרו את הבעיות שקשורות למודעות רספונסיביות בפלטפורמת PubConsent CMP שלהם, ואיך הם שיפרו את ה-INP לפני שהפכו לאחד ממדדי הליבה לבדיקת חוויית המשתמש באתר במרץ 2024. הם הראו מחויבות בלתי מתפשרת לספק ביצועים טובים ככל האפשר במוצר CMP.
למה הביצועים חשובים ל-PubTech?
בפלטפורמת PubConsent CMP, כמו ברוב ספקי ה-CMP, יש פונקציונליות של ניהול הסכמה שמוטמעת כסקריפט של צד שלישי בדפי האתר. צמצום ההשפעה על הביצועים של פלטפורמת ה-CMP שלנו – כולל תגובה מהירה – הוא חיוני כדי להבטיח שילוב מוצלח של פלטפורמת ה-CMP.
בעלי אתרים יכולים לתת עדיפות לביצועים ולהשאיר את הסקריפט של PubConsent CMP בקלות יכול ליצור איזון עדין בין שילוב של פונקציות חשובות לניהול הסכמה תוך שמירה על האיכות של חוויית המשתמש.
בגלל החשיבות של הפונקציונליות שפלטפורמת ה-CMP מספקת, ושל ההשפעה שהיא יכולה לקבל על הביצועים, אתם צריכים להגדיר את היעדים הבאים:
- צמצום ההשפעה של מוצר PubConsent CMP על INP.
- הפחתת משימות ארוכות שאפשר לשייך למוצר ה-CMP.
- מפחיתים את האפשרות משך זמן החסימה הכולל (TBT), שעשוי להיות לכך השפעה שלילית על מדד ה-INP של הדף.
איך נמדד INP
חברת PubTech השתמשה בכלי הפיתוח ל-Chrome כדי לבצע ניתוח ראשוני ואבחון ידני של אינטראקציות איטיות. תהליך העבודה הזה אפשר ל-PubTech לזהות בעיות ספציפיות שמשפיעות על הרספונסיביות של הדף. לדוגמה, אינטראקציה עם קליק במוצר ה-CMP שהובילה לאישור של כל קובצי ה-Cookie ולאחר מכן סגירה של תיבת הדו-שיח להבעת הסכמה לשימוש בקובצי Cookie גרמה למשימה ארוכה שגרמה לעיכוב בעדכון הרינדור בממשק המשתמש. כמו שאפשר לראות בתמונה הבאה, ממשק המשתמש לא עודכן כך שתיבת הדו-שיח נסגרה עד לסיום המשימה הארוכה.
כמו הלחצן לאישור כל קובצי ה-Cookie, הלחצן לדחיית כל קובצי ה-Cookie או להתאמה אישית של ההעדפות לגבי קובצי Cookie פועלים לפי אותו תהליך עבודה בארכיטקטורת PubConsent CMP. לכן, השיפורים המפורטים במקרה לדוגמה הזה השפיעו על סדרה של אינטראקציות של משתמשים במוצר ה-CMP.
העיכוב הזה גרם לכך שהתפיסה החזותית של הלוח הייתה נעולה במהלך המשימה. בגלל שהפעולה חסמה את עדכון הרינדור לפרק זמן ארוך במידה נראית, ה-INP של הדף הושפע מכך.
איך PubTech ביצעו אופטימיזציה של INP ללחצנים ולקישורים
כדי לשפר את ה-INP, התחלנו להשתמש באסטרטגיות תפוקה שונות ב-CMP של PubConsent.
ביצוע משימות בעדיפות גבוהה
השיטה yieldToMainUiBlocking שמוצגת בקטע הקוד הבא נועדה לבצע אופטימיזציה של משימות JavaScript בעדיפות גבוהה על ידי תפוקה עם scheduler.yield אם היא זמינה, אבל חזרה ל-postTask עם עדיפות user-blocking (גבוהה) אם postTask זמין, ולבסוף ללא ערך.
לא מומלץ להשתמש ב-setTimeout כי השיטה yieldToMainUiBlocking מיועדת לטפל בפעולות של הגדרות CMP פנימיות ובעבודה בעדיפות גבוהה שאמורה לשמור על עדיפות כזו בזמן התפוקה. המשמעות של היא שרק דפדפנים שמיישמים את ממשקי ה-API האלה לתזמון, שזמינים כרגע רק בדפדפנים המבוססים על Chromium בזמן הכתיבה, מפיקים תועלת מהשיפורים שמפורטים במקרה לדוגמה הזה. למרות זאת, הגישה הזו נחשבה כשיפור הדרגתי של המשימות האלה בעדיפות גבוהה.
function yieldToMainUiBlocking () {
return new Promise((resolve) => {
if ('scheduler' in window) {
if ('yield' in window.scheduler) {
return window.scheduler.yield().then(() => resolve(true));
}
if ('postTask' in window.scheduler) {
return window.scheduler.postTask(() => resolve(true), { priority: 'user-blocking' });
}
}
resolve(false);
});
};
תפוקה על משימות בגוון בינוני וברקע
השיטה yieldToMainBackground שמוצגת בקטע הקוד הבא משמשת לפיצול משימות ארוכות עם עדיפות user-visible (בינונית) או background. הלוגיקה מטמיעים את scheduler.yield() אם היא זמינה, אבל היא שונה בכך שנעשה שימוש ב-postTask עם עדיפות בינונית, ולבסוף חוזרים ל-setTimeout בדפדפנים שאינם דפדפן Chromium.
function yieldToMainBackground () {
return new Promise((resolve) => {
if ('scheduler' in window) {
if ('yield' in window.scheduler) {
return window.scheduler.yield().then(() => resolve(true));
}
if ('postTask' in window.scheduler) {
return window.scheduler.postTask(() => resolve(true), { priority: 'user-visible' });
}
}
setTimeout(() => { resolve(true) }, 0);
});
};
yieldToMainBackground מאפשרת לדפדפן לעבד את העיבוד הבא (סגירת ממשק המשתמש של פלטפורמת ה-CMP) במקרה הזה) מוקדם יותר.
איך חברת PubTech צמצמה עוד יותר את נפח האחסון (TBT) בעזרת אופטימיזציה של פריסת הרינדור
אחרי החלת אסטרטגיית התפוקה, גילינו שה-INP השתפר באופן משמעותי ל-CMP. למעשה, אחרי צמצום משמעותי של משך העיבוד של הגורם המטפל באירועים, התגלתה הזדמנות לבצע שיפורים נוספים בעיבוד הנתונים הבאים של הפעולה Close UI. במקור הפעולה הזו נועדה להסיר רכיבים מה-DOM. דבר זה עלול לגרום לעלייה בלתי צפויה בעבודה, במיוחד באתרים עם מספר משמעותי של צומתי DOM.
כדי לטפל בכמות המוגברת של עבודת הרינדור הדרושה להסרת אלמנטים מה-DOM, הושק פתרון שהגדיר הצוות בשם "lazy de-rendering". הגישה הזו מחילה כלל CSS display: none על תיבת הדו-שיח להבעת הסכמה ל-CMP אחרי שהמשתמש מביע הסכמה להסתיר אותה. לאחר מכן, ההסרה של צומתי DOM שמשויכים לתיבת הדו-שיח של ה-CMP מועברת למועד מאוחר יותר שבו הדפדפן לא פעיל באמצעות requestIdleCallback. הגישה הזו הוכחה כמהירה בהרבה מהסרה של צומתי DOM ברגע שהמשתמש סגר את תיבת הדו-שיח להבעת הסכמה.
איך חברת PubTech הפחיתה עוד יותר את ערך ה-INP על ידי שיפור ספריית TCF של IAB
אחרי שהפתרון של רוב בעיות הרספונסיביות של פלטפורמת ה-CMP הושלם בהצלחה, זיהינו הזדמנויות נוספות לשיפור באחד מיחסי התלות העיקריים של פלטפורמת ה-CMP: הספרייה TCF של IAB.
הרכיבים הממוחשבים ביותר של הספרייה הזו היו 'יצירת מחרוזות'. ו'לשלוח הסכמה'. הרכיבים האלה הם חלקים בלתי נפרדים מספריית TCF של IAB. האופטימיזציות הבאות לרכיבים האלה הוחלו בפיצול נפרד בהתאם לצרכים של PubTech:
- שימוש חוזר בתוצאות מחושבות בתהליך הפענוח, שמתבצע בכל קריאה חוזרת של צד שלישי שצריכה לקרוא את הסכמת המשתמש.
- תהליך הקידוד של ההגבלות על בעלי תוכן דיגיטלי לצורך הימנעות וצמצום של לולאות מיותרות שמתבצעות כשהמשתמש מביע הסכמה.
כחלק מהאופטימיזציה הראשונה, פלטפורמת ה-CMP מצמצמת את משך הזמן שנדרש על ידי פלטפורמת ה-CMP על כל קריאה חוזרת (callback) של צד שלישי שמקושרת לספריית TCF של IAB. האופטימיזציה השנייה קיצרה את משך העיבוד שנוצר על ידי 'יצירת מחרוזות'. לרכיב הזה. למעשה, האופטימיזציה הזו אפשרה הפחתה של עד 60% מהלולאות שבוצעו בכל פעם שמשתמש הביע הסכמה.
תוצאות
בעזרת האסטרטגיות שהניבו בעבר והאופטימיזציות החדשות של פריסת התוכן, ה-INP של פלטפורמת ה-CMP השתפר עד ל-65%. כתוצאה מכך, הרספונסיביות של חוויית המשתמש בפלטפורמת PubConsent השתפרה באופן משמעותי. במודעות מסוימות, הניראות אפילו שופרה ב-1.5% על ידי אופטימיזציה של הבקשות להצגת מודעות.
בנוסף לשיפורים האלה, בספריית TCF של IAB גילינו שה-INP השתפר בשיעור של עד 77% בניידים בקרב לקוחות שהושפעו מכך, כתוצאה מצמצום של עד 85% במשימות הארוכות שמקורן ב-TCF. כך הצלחנו לצמצם משמעותית את התקורה של כל קריאה חוזרת (callback) של צד שלישי שבוצעה במהלך כל מחזור החיים של דף.
מספר המקורות שעוברים INP בעת השימוש ב-PubConsent CMP עלה ביותר מ-400%, מ-13% ל-55% בנייד. אצל חלק מהלקוחות, מדד ה-INP של הדפים הופחת ביותר ממחצית – מ-470 אלפיות השנייה ל-230 אלפיות שנייה – בעקבות האופטימיזציה של PubTech SDK.
סיכום
הלקוחות של PubTech הכירו במהירות את הביצועים החיוביים של INP ושל המדדים העסקיים שנובעים ממאמצי האופטימיזציה שלנו. אנחנו לוקחים בחשבון שיפורים נוספים בביצועים של PubConsent CMP תוך שימוש בנתונים חשובים של Real User Monitoring (RUM) מהלקוחות. הנתונים האלה עוקבים מקרוב אחרי רגרסיות והתפתחויות, וכך תורמים לשיפור המתמשך של PubTech.
כצד שלישי, ב-PubTech גם הבינו שיש לה הזדמנות לשפר את ביצועי האתר בקנה מידה נרחב ולספק רספונסיביות טובה יותר, ובמקביל להימנע מהשפעות שליליות על מדדי ה-KPI של העסק. אף פעם לא מאוחר מדי להתחיל ליישם שיפורים כאלה!
תודה מיוחדת ללוקה קופולה (Luca Coppola), מנהל טכנולוגיות ראשי (CTO) ב-PubTech, שתומכת בעבודה החדשנית הזו, ולג'רמי וגנר (Jremy Wagner), מיכל מוקני (Michal Mocny) וריק ויסקומי מ-Google.