چگونه پلتفرم مدیریت رضایت PubTech INP را در مشتریان خود کاهش داد. وب‌سایت‌ها تا 64٪، در حالی که قابلیت مشاهده تبلیغات را تا 1.5٪ بهبود می‌بخشند.

چگونه PubConsent CMP با استفاده از یک استراتژی سودمند که از APIهای Scheduler مرورگر برای رفع مشکلات پاسخگویی شناسایی شده با استفاده از Chrome DevTools استفاده می کند، INP را برای مشتریان خود تا 64٪ کاهش داد.

Marco Prontera

Gilberto Cocchi

پلتفرم‌های مدیریت رضایت (CMPs) ابزارهایی هستند که به وب‌سایت‌ها کمک می‌کنند تا با کسب رضایت کاربر برای استفاده از کوکی‌ها و فناوری‌های ردیابی، از مقررات حفظ حریم خصوصی پیروی کنند. علاوه بر هدف اصلی اطمینان از انطباق قانونی، CMPها، به عنوان اسکریپت های شخص ثالث، باید حداقل تأثیر را بر عملکرد و تجربه کاربر تضمین کنند.

PubConsent CMP جدیدترین محصول PubTech است. PubConsent CMP با تمرکز اولیه بر عملکرد طراحی شده است تا سبک وزن باشد، تجربه کاربری بهینه را تضمین کند، و کمترین تأثیر را بر عملکرد کلی وب سایت داشته باشد.

معرفی معیار Interaction to Next Paint (INP) به PubTech اجازه داد مشکلات مربوط به پاسخگویی CMP ما را کشف کند. در این مطالعه موردی، PubTech نشان می‌دهد که چگونه مشکلات خود را در زمینه پاسخ‌گویی در پلتفرم PubConsent CMP خود حل کرده‌اند، و چگونه INP را قبل از تبدیل شدن به یکی از اصلی‌ترین بخش‌های وب در مارس 2024 بهبود داده‌اند، که نشان‌دهنده تعهد تزلزل‌ناپذیر برای ارائه بهترین عملکرد ممکن است. محصول CMP

چرا PubTech به عملکرد اهمیت می دهد؟

PubConsent CMP - مانند اکثر CMP ها - عملکرد مدیریت رضایت خود را ارائه می دهد که به عنوان یک اسکریپت شخص ثالث در صفحات سایت پیاده سازی شده است. کاهش تأثیر عملکرد ارائه CMP ما - از جمله در پاسخگویی - برای تضمین یکپارچگی موفق CMP بسیار مهم است.

با اولویت بندی عملکرد و سبک نگه داشتن اسکریپت PubConsent CMP، صاحبان وب سایت می توانند تعادل ظریفی را بین ترکیب عملکردهای ارزشمند مدیریت رضایت و در عین حال حفظ کیفیت تجربه کاربر ایجاد کنند.

با توجه به اهمیت عملکردی که یک CMP ارائه می دهد - و تأثیری که می تواند بر عملکرد داشته باشد - PubTech اهداف زیر را تعیین می کند:

1. تأثیر محصول PubConsent CMP بر INP را به حداقل برسانید.
2. کارهای طولانی منتسب به محصول CMP را کاهش دهید.
3. کاهش زمان مسدود کردن کل (TBT) که می تواند تأثیر منفی بر INP صفحه داشته باشد.

چگونه INP اندازه گیری شد

PubTech از Chrome DevTools برای انجام یک تحلیل اولیه و تشخیص دستی تعاملات کند استفاده کرد. این گردش کار به PubTech اجازه داد تا مسائل خاصی را که بر پاسخگویی صفحه تأثیر می‌گذارد، مشخص کند. برای مثال، یک تعامل کلیک در محصول CMP برای پذیرش همه کوکی‌ها و متعاقباً رد کردن گفتگوی رضایت کوکی باعث انجام یک کار طولانی شد که به‌روزرسانی رندر رابط کاربری را به تأخیر انداخت. همانطور که از تصویر زیر می بینید، رابط کاربری برای نشان دادن بسته شدن گفتگو تا زمانی که کار طولانی انجام نشده بود، به روز نشد.

مانند دکمه پذیرش همه کوکی‌ها، دکمه رد همه کوکی‌ها یا سفارشی‌سازی تنظیمات برگزیده کوکی، همگی از یک گردش کار در معماری PubConsent CMP پیروی می‌کنند. به همین دلیل، بهبودهایی که در این مطالعه موردی شرح داده شد، بر یک سری از تعاملات کاربر در محصول CMP تأثیر گذاشت.

این تاخیر منجر به درک بصری پانل در حالت قفل در حین کار شد. از آنجایی که به‌روزرسانی رندر را برای یک دوره زمانی طولانی مسدود کرد، INP صفحه تأثیر منفی گذاشت.

چگونه PubTech INP را برای دکمه ها و پیوندها بهینه کرد

برای بهبود INP، استراتژی‌های بازده متفاوتی در PubConsent CMP اتخاذ شد.

انجام وظایف با اولویت بالا

روش yieldToMainUiBlocking نشان‌داده‌شده در قطعه کد زیر برای بهینه‌سازی وظایف جاوا اسکریپت با اولویت بالا طراحی شده است که در صورت موجود بودن، با scheduler.yield ارائه می‌شود، اما اگر postTask در دسترس باشد، به postTask با اولویت user-blocking (بالا) برمی‌گردد، و در نهایت به هیچ چیز باز می‌گردد. .

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، راه حلی معرفی شد که تیم آن را "تنبل زدایی" نامید. این رویکرد ابتدا یک display: none قانون CSS در گفتگوی رضایت CMP پس از اینکه کاربر رضایت خود را برای پنهان کردن آن اعلام کرد. سپس، با استفاده از requestIdleCallback ، حذف گره‌های DOM مرتبط با گفتگوی CMP به نقطه‌ای در زمان بعدی منتقل می‌شود که مرورگر غیرفعال است. ثابت شد که این رویکرد بسیار سریع‌تر از حذف گره‌های DOM در لحظه‌ای که کاربر گفتگوی رضایت را بست.

چگونه PubTech با بهبود کتابخانه IAB TCF، INP را بیشتر کاهش داد

پس از حل موفقیت آمیز بسیاری از مسائل مربوط به پاسخگویی CMP، فرصت های بیشتری برای بهبود در یکی از وابستگی های اصلی آن شناسایی شد: کتابخانه شفافیت و رضایت چارچوب IAB ( TCF ).

گران ترین اجزای محاسباتی این کتابخانه «ساخت رشته ها» و «رضایت نامه» بود. این اجزا بخش جدایی ناپذیر کتابخانه IAB TCF هستند. بهینه‌سازی‌های زیر برای این مؤلفه‌ها در یک فورک جداگانه به‌طور خاص برای نیازهای PubTech اعمال شد:

1. استفاده مجدد از نتایج محاسبه‌شده برای فرآیند رمزگشایی، که برای هر فراخوانی شخص ثالثی که نیاز به خواندن رضایت کاربر دارد، اجرا می‌شود.
2. اجتناب و کاهش حلقه‌های غیرضروری در فرآیند رمزگذاری محدودیت‌های ناشر، که با رضایت کاربر اجرا می‌شود.

اولین مورد از این بهینه‌سازی‌ها زمان صرف شده توسط CMP را برای هر تماس شخص ثالثی که به کتابخانه IAB TCF متصل می‌شود، کاهش داد. بهینه سازی دوم مدت زمان پردازش متحمل شده توسط مؤلفه "رشته های ساخت" را کاهش داد. در واقع، این بهینه‌سازی باعث کاهش تا 60 درصد از حلقه‌هایی می‌شود که هر بار که کاربر رضایت خود را اعلام می‌کرد، اجرا می‌شد.

نتایج

با استراتژی‌های بازده قبلی و بهینه‌سازی‌های طرح‌بندی رندر جدید، INP CMP تا 65 درصد بهبود یافته است . در نتیجه، واکنش‌پذیری تجربه کاربری PubConsent CMP بسیار بهبود یافت و برای برخی از تبلیغات، با بهینه‌سازی زمانی که تبلیغات درخواست می‌شود، قابلیت مشاهده حتی تا 1.5 درصد بهبود یافت.

علاوه بر این پیشرفت‌ها، در کتابخانه TCF IAB مشاهده شد که INP تا ​​77 درصد در تلفن همراه برای مشتریان آسیب‌دیده در نتیجه کاهش وظایف طولانی ناشی از TCF تا 85 درصد بهبود یافته است . این به کاهش قابل توجه سربار هر پاسخ به تماس شخص ثالث در کل چرخه عمر صفحه کمک کرد.

تعداد مبداهایی که در هنگام استفاده از PubConsent CMP از INP عبور می کنند، بیش از 400 درصد بهبود یافته است، از 13 درصد به 55 درصد در تلفن همراه. برای برخی از مشتریان، به دلیل بهینه سازی PubTech SDK انجام شده، INP صفحه به نصف کاهش یافت - از 470 میلی ثانیه به 230 میلی ثانیه.

نتیجه گیری

مشتریان PubTech به سرعت عملکرد مثبت INP و نتایج معیارهای تجاری را که از تلاش‌های بهینه‌سازی ما ناشی می‌شود، تشخیص داده‌اند، بهبود عملکرد بیشتر برای PubConsent CMP در نظر گرفته شده است، و از داده‌های ارزشمند نظارت بر کاربر واقعی (RUM) از مشتریان خود استفاده می‌کند. این داده‌ها هم رگرسیون‌ها و هم پیشرفت‌ها را از نزدیک دنبال می‌کنند و تلاش‌های بهبود مستمر PubTech را هدایت می‌کنند.

به عنوان یک شخص ثالث، PubTech همچنین متوجه شد که این فرصت را دارند که عملکرد وب را در مقیاس بهبود بخشند و پاسخگویی بهتری ارائه دهند، در حالی که از تأثیرات منفی بر KPIهای تجاری جلوگیری می کنند. برای شروع اجرای این نوع بهبودها هرگز دیر نیست!

تشکر ویژه از Luca Coppola، مدیر ارشد فناوری PubTech برای حمایت از این کار نوآورانه، و جرمی واگنر، Michal Mocny، و Rick Viscomi از Google.