איך הפלטפורמה לניהול הסכמה של PubTech הפחיתה את ה-INP באתרים של הלקוחות שלה בשיעור של עד 64%, ובמקביל הגדילה את הניראות של המודעות בשיעור של עד 1.5%

איך פלטפורמת ה-CMP של PubConsent צמצמה את מספר הבקשות להצגת מודעות (INP) של הלקוחות שלה ב-64% באמצעות אסטרטגיית חלוקת זמן (yielding) שמשתמשת בממשקי ה-API של מתזמן הדפדפן כדי לפתור בעיות בתגובה מהירה שזוהו באמצעות הכלים למפתחים ב-Chrome.

Marco Prontera

Gilberto Cocchi

פלטפורמות לניהול הסכמה (CMP) הן כלים שעוזרים לאתרים לפעול בהתאם לתקנות בנושא פרטיות באמצעות קבלת הסכמה מהמשתמשים לשימוש בקובצי cookie ובטכנולוגיות מעקב. בנוסף למטרה העיקרית של הבטחת תאימות משפטית, פלטפורמות CMP, כסקריפטים של צד שלישי, חייבות גם להבטיח השפעה מינימלית על הביצועים ועל חוויית המשתמש.

PubConsent CMP הוא המוצר החדש ביותר של PubTech. פלטפורמת ה-CMP של PubConsent תוכננה עם דגש עיקרי על ביצועים, והיא קלה לשימוש, מבטיחה חוויית משתמש אופטימלית ומשפיעה במינימום על ביצועי האתר באופן כללי.

ההשקה של המדד מהירות התגובה לאינטראקציה באתר (INP) אפשרה ל-PubTech לגלות בעיות ברספונסיביות של פלטפורמת ה-CMP שלנו. בניתוח המקרה הזה, צוות PubTech מראה איך פתר את הבעיות שקשורות לתגובה המהירה בפלטפורמת ה-CMP של PubConsent, ואיך שיפר את מדד INP לפני שהוא הפך לאחד ממדדי Core Web Vitals במרץ 2024. כך הם מוכיחים את המחויבות הבלתי מעורערת שלהם לספק את הביצועים הטובים ביותר במוצר CMP.

למה הביצועים חשובים ל-PubTech?

הפלטפורמה לניהול הסכמה של PubConsent, כמו רוב הפלטפורמות לניהול הסכמה, מציעה את הפונקציונליות של ניהול ההסכמה כסקריפט של צד שלישי בדפי האתר. כדי להבטיח שילוב מוצלח של פלטפורמת ה-CMP, חשוב לצמצם את ההשפעה על הביצועים – כולל על התגובה המהירה.

העדיפות של הפלטפורמה היא לשפר את הביצועים, והסקריפט של PubConsent CMP קל משקל. כך בעלי אתרים יכולים לשמור על איזון עדין בין שילוב של פונקציות חשובות לניהול הסכמה לבין שמירה על איכות חוויית המשתמש.

לאור החשיבות של הפונקציונליות שמספקת פלטפורמת CMP – וההשפעה שלה על הביצועים – הצוות של PubTech קבע את היעדים הבאים:

1. למזער את ההשפעה של מערכת ניהול ההסכמה של PubConsent על INP.
2. צמצום המשימות הארוכות שאפשר לשייך למוצר ה-CMP.
3. צמצום זמן החסימה הכולל (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);
  });
};

איך חברת PubTech צמצמה עוד יותר את נפח האחסון (TBT) בעזרת אופטימיזציה של פריסת הרינדור

לאחר החלת אסטרטגיית התשואה, נמצא שמדד ה-INP של פלטפורמת ה-CMP השתפר באופן משמעותי. למעשה, אחרי שהפחתנו באופן משמעותי את משך העיבוד של בורר האירועים, התגלתה הזדמנות לשפר את הרינדור של הציור הבא של הפעולה Close UI. הפעולה הזו תוכננה במקור להסרת רכיבים מה-DOM. המצב הזה יצר אתגרים, במיוחד באתרים עם מספר גדול של צמתים ב-DOM, וכתוצאה מכך הייתה עלייה בלתי צפויה בעבודה על העיבוד.

כדי לטפל בכמות הגדולה יותר של עיבוד גרפי שנדרש כדי להסיר רכיבים מ-DOM, הצוות הציג פתרון שנקרא 'ביטול עיבוד גרפי בזמן אמת'. הגישה הזו מחילה כלל CSS display: none על תיבת הדו-שיח להבעת הסכמה ל-CMP אחרי שהמשתמש מביע הסכמה להסתיר אותה. לאחר מכן, באמצעות requestIdleCallback, הסרת צמתים של DOM שמשויכים לתיבת הדו-שיח של ה-CMP מועברת לנקודת זמן מאוחרת יותר שבה הדפדפן לא פעיל. הגישה הזו הוכיחה שהיא מהירה הרבה יותר מאשר הסרת צמתים של DOM ברגע שהמשתמש סגר את תיבת הדו-שיח של בקשת ההסכמה.

איך PubTech צמצמה עוד יותר את מספר הבקשות להצגת מודעות (INP) על ידי שיפור הספרייה של TCF של IAB

אחרי שהצלחנו לפתור את רוב הבעיות שקשורות לתגובה של פלטפורמת ה-CMP, זיהינו הזדמנויות נוספות לשיפור באחד מהיחסים התלויים העיקריים שלה: הספרייה של Transparency and Consent Framework (מסגרת השקיפות וההסכמה, ‏TCF) של IAB.

הרכיבים הממוחשבים ביותר בספרייה הזו היו בניית מחרוזות ו-dispatch consent (הסכמה). הרכיבים האלה הם חלק בלתי נפרד מספריית IAB TCF. האופטימיזציות הבאות של הרכיבים האלה הוחלו בהסתעפות נפרדת, במיוחד לצורכי PubTech:

1. שימוש חוזר בתוצאות מחושבות בתהליך הפענוח, שמתבצע בכל קריאה חוזרת (callback) של צד שלישי שצריך לקרוא את הסכמת המשתמש.
2. ביטול וקיצור של לולאות מיותרות בתהליך הקידוד של הגבלות בעל התוכן הדיגיטלי, שמתבצע כשהמשתמש נותן הסכמה.

כחלק מהאופטימיזציה הראשונה, פלטפורמת ה-CMP מצמצמת את משך הזמן שנדרש על ידי פלטפורמת ה-CMP על כל קריאה חוזרת (callback) של צד שלישי שמקושרת לספריית TCF של IAB. האופטימיזציה השנייה צמצמה את משך העיבוד שנגרם על ידי הרכיב build strings. למעשה, האופטימיזציה הזו אפשרה הפחתה של עד 60% מהלולאות שבוצעו בכל פעם שמשתמש הביע הסכמה.

תוצאות

בעזרת האסטרטגיות שהניבו בעבר והאופטימיזציות החדשות של פריסת התוכן, ה-INP של פלטפורמת ה-CMP השתפר עד ל-65%. כתוצאה מכך, חוויית המשתמש של CMP של PubConsent הפכה למהירה יותר, ובחלק מהמודעות נרשמה עלייה של 1.5% בניראות (viewability) בעקבות אופטימיזציה של הזמן שבו המודעות מתבקשות.

בנוסף לשיפורים האלה, בספריית TCF של IAB גילינו שה-INP השתפר בשיעור של עד 77% בניידים בקרב לקוחות שהושפעו מכך, כתוצאה מצמצום של עד 85% במשימות הארוכות שמקורן ב-TCF. כך הצלחנו לצמצם באופן משמעותי את התקורה של כל קריאה חוזרת (callback) של צד שלישי שמופעלת במהלך כל מחזור החיים של הדף.

מספר מקורות הנתונים ששלחו בקשות INP כשהשתמשו בפלטפורמה לניהול הסכמה של PubConsent השתפר ביותר מ-400%, מ-13% ל-55% בנייד. אצל חלק מהלקוחות, זמן הטעינה של הדף (INP) הופחת ביותר ממחצית – מ-470 אלפיות השנייה ל-230 אלפיות השנייה – בגלל האופטימיזציות שבוצעו ב-SDK של PubTech.

סיכום

הלקוחות של PubTech הכירו במהירות את הביצועים החיוביים של INP ושל המדדים העסקיים שנובעים ממאמצי האופטימיזציה שלנו. אנחנו לוקחים בחשבון שיפורים נוספים בביצועים של PubConsent CMP תוך שימוש בנתונים חשובים של Real User Monitoring (RUM) מהלקוחות. הנתונים האלה עוקבים מקרוב אחרי נסיגות וגם אחרי התקדמות, ומשמשים לצורך שיפור מתמיד של PubTech.

כצד שלישי, ב-PubTech הבינו גם שיש להם הזדמנות לשפר את ביצועי האתר בקנה מידה נרחב ולספק תגובה מהירה יותר, בלי להשפיע לרעה על מדדי ה-KPI העסקיים. אף פעם לא מאוחר מדי להתחיל ליישם שיפורים כאלה.

תודה מיוחדת ל-Luca Coppola, CTO של PubTech, על התמיכה בעבודה החדשנית הזו, ול-Jeremy Wagner, ‏ Michal Mocny ו-Rick Viscomi מ-Google.