איך פלטפורמת PubConsent הפחיתה את ה-INP בקרב הלקוחות שלה בשיעור של עד 64% באמצעות אסטרטגיה תפוקה שמשתמשת בממשקי ה-Scheduler API של הדפדפן כדי לתקן בעיות רספונסיביות שזוהו באמצעות כלי הפיתוח ל-Chrome.
פלטפורמות לניהול הסכמה (CMP) הן כלים שעוזרים לאתרים לעמוד בדרישות של תקנות הפרטיות באמצעות קבלת הסכמה מהמשתמשים לשימוש בקובצי cookie ובטכנולוגיות מעקב. בנוסף למטרה העיקרית של הבטחת תאימות לחוק, פלטפורמות CMP, כסקריפטים של צד שלישי, חייבות גם להבטיח השפעה מינימלית על הביצועים ועל חוויית המשתמש.
PubConsent CMP הוא המוצר החדש ביותר מ-PubTech. פלטפורמת ה-CMP של PubConsent מיועדת בעיקר לשיפור הביצועים, ומבטיחה חוויית משתמש אופטימלית, עם השפעה מינימלית על הביצועים הכוללים של האתר.
בעקבות ההשקה של המדד Interaction to Next Paint (INP), חברת PubTech הצליחה לגלות בעיות ביכולת התגובה של ה-CMP שלנו. במקרה לדוגמה הזה, ב-PubTech רואים איך הם פתרו את הבעיות הרספונסיביות בפלטפורמת ה-CMP של PubConsent, ואיך הם שיפרו את ה-INP לפני שהוא הופך לאחד ממדדי הליבה לבדיקת חוויית המשתמש באתר במרץ 2024. כך הוכיחו מחויבות בלתי מתפשרת לספק ביצועים טובים ככל האפשר במוצר CMP.
למה ל-PubTech חשובה הביצועים?
פלטפורמת ה-CMP של PubConsent, כמו רוב פלטפורמות ה-CMP, מציעה את הפונקציונליות של ניהול ההסכמה שמוטמעת כסקריפט של צד שלישי בדפי האתר. כדי להבטיח שילוב מוצלח של ה-CMP, חשוב מאוד לצמצם את ההשפעה של ה-CMP על הביצועים, כולל על היכולת להגיב.
מתן עדיפות לביצועים ושמירה על משקל קל של סקריפט ה-CMP של PubConsent, בעלי אתרים יכולים לשמור על איזון עדין בין שילוב של פונקציות בעלות ערך של ניהול הסכמה תוך שמירה על האיכות של חוויית המשתמש.
לאור חשיבות הפונקציונליות של פלטפורמת ה-CMP וההשפעה שלה על הביצועים, PubTech הגדירה את היעדים הבאים:
- לצמצם את ההשפעה של PubConsent CMP על ה-INP.
- יש להפחית משימות ארוכות שניתן לשייך למוצר של פלטפורמת ה-CMP.
- מצמצמים את זמן החסימה הכולל (TBT), שעלול להשפיע לרעה על ה-INP של הדף.
איך מדד INP נמדד
ב-PubTech השתמשו בכלי הפיתוח ל-Chrome כדי לבצע ניתוח ראשוני ואובחנו באופן ידני אינטראקציות איטיות. תהליך העבודה הזה אפשר ל-PubTech לזהות בעיות ספציפיות שמשפיעות על הרספונסיביות של הדפים. לדוגמה, אינטראקציה עם קליק במוצר ה-CMP כדי לאשר את כל קובצי ה-cookie ולאחר מכן לסגור את תיבת הדו-שיח להבעת הסכמה לשימוש בקובצי cookie יצרה משימה ארוכה שגרמה לעיכוב בעדכון הרינדור של ממשק המשתמש. כפי שניתן לראות בתמונה הבאה, ממשק המשתמש לא עודכן כך שתיבת הדו-שיח נסגרה עד שהמשימה הארוכה הושלמה.
כמו הלחצן לאישור כל קובצי ה-cookie, גם הלחצן לדחיית כל קובצי ה-cookie או להתאמה אישית של ההעדפות לגבי קובצי cookie פועל באותו תהליך עבודה בארכיטקטורת ה-CMP של PubConsent. לכן, השיפורים המפורטים במקרה לדוגמה הזה השפיעו על מספר אינטראקציות של משתמשים במוצר ה-CMP.
העיכוב הזה גרם לתפיסה חזותית של הפאנל במצב נעול במהלך המשימה. מאחר שהוא חסם את עדכון הרינדור למשך פרק זמן ארוך באופן מובהק, ה-INP של הדף הושפע לרעה.
איך PubTech ביצעה אופטימיזציה של INP ללחצנים ולקישורים
כדי לשפר את ה-INP, הטמענו אסטרטגיות שונות של תפוקה ב-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. למעשה, לאחר הפחתה משמעותית של משך העיבוד של הגורם המטפל באירועים, התגלתה הזדמנות לבצע שיפורים נוספים בעיבוד עבור ה- Paint הבא עבור הפעולה Close UI. הפעולה הזו תוכננה במקור להסיר רכיבים מה-DOM. המצב הזה מציב אתגרים, במיוחד באתרים עם מספר משמעותי של צומתי DOM, מה שהוביל לעלייה בלתי צפויה בעיבוד.
כדי לטפל בכמות המוגברת של עבודת העיבוד הנדרשת כדי להסיר אלמנטים מה-DOM, השקנו פתרון בשם הצוות שנקרא 'de-rendering מדורגת'. הגישה הזו מחילה קודם כלל CSS מסוג display: none על תיבת הדו-שיח להבעת הסכמה בפלטפורמת CMP, אחרי שהמשתמש נותן הסכמה להסתיר אותו. לאחר מכן, ההסרה של צומתי DOM המשויכים לתיבת הדו-שיח של ה-CMP תזוז לנקודה מאוחרת יותר בזמן שהדפדפן לא פעיל באמצעות requestIdleCallback. נראה שהגישה הזו מהירה בהרבה מהסרת צמתים של DOM ברגע שהמשתמש סגר את תיבת הדו-שיח להבעת הסכמה.
איך PubTech צמצמה עוד יותר את ה-INP באמצעות שיפור ספריית ה-TCF של IAB
אחרי שפותרים בהצלחה את רוב בעיות התגובה של פלטפורמת ה-CMP, זוהו הזדמנויות נוספות לשיפור באחת מיחסי התלות העיקריים שלה: הספרייה של IAB Transparency and Consent Framework (TCF).
הרכיבים היקרים ביותר מבחינת חישוב בספרייה הזו היו 'בניית מחרוזות' ו'שליחה של הסכמה'. הרכיבים האלה הם חלקים בלתי נפרדים מספריית TCF של IAB. האופטימיזציות הבאות של הרכיבים האלה הוחלו במזלג נפרד, שנועד ספציפית לצרכים של PubTech:
- שימוש חוזר בתוצאות מחושבות לתהליך הפענוח, שמתבצע לכל קריאה חוזרת (callback) של צד שלישי שצריך לקרוא את הסכמת המשתמש.
- נמנעת וצמצום של לולאות מיותרות בתהליך הקידוד של הגבלות על בעלי תוכן דיגיטלי, שמתבצע כשהמשתמש מביע הסכמה.
האופטימיזציה הראשונה מקצרת את הזמן שפלטפורמת ה-CMP הקצתה לכל קריאה חוזרת (callback) של צד שלישי שמחוברת לספריית TCF של IAB. האופטימיזציה השנייה הפחיתה את משך העיבוד שהרכיב "build Strings" יצר. למעשה, האופטימיזציה הזו אפשרה צמצום של עד 60% מהלולאות שבוצעו בכל פעם שמשתמש הביע הסכמה.
תוצאות
לאחר יישום האסטרטגיות שהניבו בעבר ואופטימיזציות חדשות של פריסת רינדור, מדד ה-INP של פלטפורמת ה-CMP השתפר בשיעור של עד 65%. כתוצאה מכך, הרספונסיביות של חוויית המשתמש של פלטפורמת ה-CMP של PubConsent שופרה באופן משמעותי, ועבור מודעות מסוימות, הניראות אפילו השתפרה ב-1.5% על ידי אופטימיזציה תוך התמקדות בבקשות להצגת מודעות.
בנוסף לשיפורים האלה, בספריית TCF של IAB ראינו שהעלייה ב-INP בשיעור של עד 77% בניידים אצל הלקוחות שהושפעו מהבעיה נובעת מצמצום של עד 85% במשימות ארוכות שנובעות מ-TCF. כך להפחית באופן משמעותי את התקורה של כל קריאה חוזרת (callback) של צד שלישי שבוצעה לכל אורך מחזור החיים של דף.
מספר המקורות שעברו INP בעת השימוש ב-CMP של PubConsent השתפר ביותר מ-400%, מ-13% ל-55% בנייד. אצל חלק מהלקוחות, ערך ה-INP של הדף ירד ביותר ממחצית – מ-470 אלפיות השנייה ל-230 אלפיות השנייה – הודות לאופטימיזציה של PubTech SDK.
סיכום
הלקוחות של PubTech הצליחו לזהות במהירות את הביצועים החיוביים של מדד INP ואת התוצאות של המדדים העסקיים שנבעו ממאמצי האופטימיזציה שלנו. אנחנו לוקחים בחשבון שיפורי ביצועים נוספים של ה-CMP של PubConsent, תוך שימוש בנתונים חשובים של Real User Monitoring (RUM) מלקוחות. הנתונים האלה עוקבים מקרוב גם אחר רגרסיות וגם שיפורים, ומניעים את מאמצי השיפור המתמשכים של PubTech.
כצד שלישי, ב-PubTech הבינו גם שיש לה הזדמנות לשפר את ביצועי האינטרנט בקנה מידה נרחב ולספק מענה טוב יותר, תוך מניעת השפעות שליליות על מדדי ה-KPI העסקיים. אף פעם לא מאוחר מדי להתחיל ליישם שיפורים כאלה!
תודה מיוחדת ללוקה קופולה, מנהל טכנולוגיות ראשי ב-PubTech שתומך בעבודת החדשנות הזו, ולג'רמי וגנר, מיכל מוצ'ני וריק ויסקומי מ-Google.