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

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

Marco Prontera
Marco Prontera
Gilberto Cocchi
Gilberto Cocchi

פלטפורמות לניהול הסכמה (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 הגדירה את היעדים הבאים:

  1. לצמצם את ההשפעה של PubConsent CMP על ה-INP.
  2. יש להפחית משימות ארוכות שניתן לשייך למוצר של פלטפורמת ה-CMP.
  3. מצמצמים את זמן החסימה הכולל (TBT), שעלול להשפיע לרעה על ה-INP של הדף.

איך מדד INP נמדד

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

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

רצף שמראה למשך כמה זמן משימה מסוימת חוסמת את העדכון של ממשק המשתמש אחרי שהמשתמש לוחץ על הלחצן 'אישור הכול' ב-CMP של PubConsent. יש חמישה שלבים שמרכיבים משימה ארוכה אחת, שגורמת לממשק המשתמש להרגיש איטי.
ייצוג חזותי של מה שקורה כשמשתמשים לוחצים על הלחצן 'אישור הכול'.

העיכוב הזה גרם לתפיסה חזותית של הפאנל במצב נעול במהלך המשימה. מאחר שהוא חסם את עדכון הרינדור למשך פרק זמן ארוך באופן מובהק, ה-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);
  });
};
רצף שמראה במשך כמה זמן בוצעה אופטימיזציה של המשימה שמנעה את העדכון של ממשק המשתמש, אחרי שהמשתמש לחץ על הלחצן 'אישור הכול' ב-CMP של PubConsent. חמשת השלבים מתבצעים עכשיו כשאפשר, ומאפשרים לממשק המשתמש לעדכן את העיבוד מוקדם יותר.
ייצוג חזותי של האופן שבו תפוקה באמצעות yieldToMainBackground מאפשרת לדפדפן לעבד את הצבע הבא (סגירת ממשק המשתמש של ה-CMP במקרה הזה) מוקדם יותר.

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

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

צילום מסך של החלונית 'ביצועים' בכלי הפיתוח ל-Chrome, שמראה קטע של מעקב עם מקבץ קריאות של פעילות לסגירה של תיבת דו-שיח בממשק המשתמש ב-PubConsent. המשימה לסגור את תיבת הדו-שיח של ממשק המשתמש עצמה גורמת להסרה של צומתי DOM שגורמים לעיכוב ההצגה של האינטראקציה.

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

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

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

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

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

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

האופטימיזציה הראשונה מקצרת את הזמן שפלטפורמת ה-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.

צילום מסך של שיעורי אישורי INP מהמקור לאתרים שמשתמשים בפלטפורמת ה-CMP של PubTech. במחשב, שיעורי המסירה עולים ל-99.12% מ-84%. בנייד, שיעורי המעברים עולים מ-55.46% מכ-22%.
שיעור אישורי INP לפי מקור לאתרים שמשתמשים ב-CMP של PubTech, כפי שדווח ב-HTTP Archive ובדוח חוויית המשתמש ב-Chrome (CrUX).
צילום מסך של מרכז בקרה שבו מוצגים נתוני INP מנתוני RUM באחוזון ה-75. החל מיולי/אוגוסט 2023, משך זמן ה-INP מעט פחות מ-500 אלפיות השנייה, אבל באמצע פברואר 2024, זמן INP יהיה מעט פחות מ-200 אלפיות השנייה, ולכן המדד הזה נמצא בסף 'טוב'.
מגמת שיפור נתוני INP ללקוחות בנייד של PubConsent, בהתאם לשינויים ב-SDK שמתוארים במקרה לדוגמה הזה.

סיכום

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

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

תודה מיוחדת ללוקה קופולה, מנהל טכנולוגיות ראשי ב-PubTech שתומך בעבודת החדשנות הזו, ולג'רמי וגנר, מיכל מוצ'ני וריק ויסקומי מ-Google.