PubTech'in Kullanıcı Rızası Yönetim Platformu'nun müşterileri web sitelerinde INP'yi %64'e kadar azaltıp reklam görüntülenebilirliğini %1,5'e kadar nasıl iyileştirdiğini öğrenin.

PubConsent CMP, Chrome DevTools kullanılarak tespit edilen yanıt verme sorunlarını düzeltmek için tarayıcının Planlayıcı API'lerini kullanan bir verim stratejisi kullanarak müşterileri için INP'yi% 64'e varan oranda nasıl azalttı?

Marco Prontera
Marco Prontera
Gilberto Cocchi
Gilberto Cocchi

Kullanıcı Rızası Yönetim Platformları (CMP'ler), web sitelerinin çerez ve izleme teknolojilerinin kullanımı için kullanıcı izni alarak gizlilik yönetmeliklerine uymasına yardımcı olan araçlardır. CMP'ler, üçüncü taraf komut dosyaları olarak yasal uygunluğu sağlamanın birincil hedefine ek olarak performans ve kullanıcı deneyimi üzerinde minimum düzeyde etki de sağlamalıdır.

PubConsent CMP, PubTech'in en yeni ürünüdür. Öncelikli olarak performansa odaklanarak tasarlanan PubConsent CMP, hafif olması için tasarlanmıştır. Bu sayede, optimum kullanıcı deneyimi ve web sitesinin genel performansı üzerinde minimum düzeyde etki sağlanır.

Interaction to Next Paint (INP) metriğinin kullanıma sunulması, PubTech'in CMP'mizin duyarlılığıyla ilgili sorunları keşfetmesine olanak tanıdı. Bu örnek olayda PubTech, PubConsent CMP platformundaki duyarlılıkla ilgili sorunlarını nasıl çözdüğünü ve INP'yi Mart 2024'te Core Web Vitals'ın bir parçası olmadan önce nasıl iyileştirdiğini gösteriyor. Bu sayede, CMP ürününde mümkün olan en iyi performansı sağlamaya yönelik kararlılığını sergiliyor.

PubTech neden performansı önemser?

PubConsent CMP, çoğu CMP gibi kullanıcı rızası yönetim işlevini site sayfalarında üçüncü taraf komut dosyası olarak sunar. CMP teklifimizin performans üzerindeki etkisini (yanıt verme dahil) azaltmak, başarılı bir CMP entegrasyonu sağlamak için çok önemlidir.

Web sitesi sahipleri, performansa öncelik vererek ve PubConsent CMP komut dosyasını hafif tutarak kullanıcı deneyiminin kalitesini korurken değerli Kullanıcı Rızası Yönetimi işlevlerini dahil etme arasında hassas bir denge sağlayabilir.

CMP'nin sunduğu işlevselliğin önemi ve performans üzerindeki etkisi göz önüne alındığında PubTech aşağıdaki hedefleri belirledi:

  1. PubConsent CMP ürününün INP üzerindeki etkisini en aza indirin.
  2. CMP ürünüyle ilişkili uzun görevleri azaltın.
  3. Sayfanın INP'sini olumsuz yönde etkileyebilecek Toplam Engelleme Süresi'ni (TBT) azaltın.

INP nasıl ölçüldü?

PubTech, ilk analizi yapmak için Chrome Geliştirici Araçları'nı kullandı ve yavaş etkileşimleri manuel olarak teşhis etti. Bu iş akışı, PubTech'in sayfa duyarlılığını etkileyen belirli sorunları tespit etmesine olanak tanıdı. Örneğin, tüm çerezleri kabul etmek ve ardından çerez izni iletişim kutusunu kapatmak için CMP ürünü içinde yapılan bir tıklama etkileşimi, kullanıcı arayüzünde oluşturma güncellemesini geciktiren uzun bir göreve neden oldu. Aşağıdaki resimde de görebileceğiniz gibi, kullanıcı arayüzü uzun görev tamamlanana kadar iletişim kutusunun kapatıldığını göstermek için güncellenmedi.

Tüm çerezleri kabul etme düğmesi gibi, tüm çerezleri reddetme veya çerez tercihlerini özelleştirme düğmelerinin tümü PubConsent CMP mimarisinde aynı iş akışını izler. Bu nedenle, bu örnek olayda ayrıntılı olarak açıklanan iyileştirmeler CMP ürününde bir dizi kullanıcı etkileşimini etkiledi.

Kullanıcı, PubConsent CMP'de "Tümünü Kabul Et" düğmesini tıkladıktan sonra uzun bir görevin kullanıcı arayüzünün güncellenmesini nasıl engellediğini gösteren akış. Tek bir uzun görevi oluşturan beş adım vardır. Bu da kullanıcı arayüzünün yavaş görünmesine neden olur.
Kullanıcılar "Tümünü Kabul Et" düğmesini tıkladığında ne olacağının görsel gösterimi.

Bu gecikme, panelin görev sırasında kilitli durumda olduğu görsel algısına yol açıyordu. Oluşturma güncellemesini belirgin bir şekilde uzun bir süre boyunca engellediği için sayfanın INP'si olumsuz etkilendi.

INP'yi iyileştirmek için PubConsent CMP'de farklı getiri stratejileri benimsendi.

Yüksek öncelikli görevlerin tamamlanmasını sağlayın

Aşağıdaki kod snippet'inde gösterilen yieldToMainUiBlocking yöntemi, yüksek öncelikli JavaScript görevlerini optimize etmek için tasarlanmıştır. Bu yöntem, varsa scheduler.yield ile sonuç verir ancak postTask varsa user-blocking (yüksek) öncelikli postTask ile sonuç verir ve son olarak hiçbir sonuç vermez.

yieldToMainUiBlocking yöntemi, dahili CMP ayarlama işlemlerini ve üretkenlik sırasında bu önceliği koruması gereken yüksek öncelikli işleri işlemek için tasarlandığından burada setTimeout yönteminden kaçınılmıştır. Bu, yalnızca bu planlama API'lerini uygulayan tarayıcıların (bu makalenin yazıldığı sırada yalnızca Chromium tabanlı tarayıcılarda kullanılabilen) bu örnek olayda ayrıntılı olarak açıklanan iyileştirmelerden yararlanacağı anlamına gelmez. Yine de bu yaklaşım, bu yüksek öncelikli görevler için kabul edilebilir bir aşamalı iyileştirme olarak kabul edildi.

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);
  });
};

Orta ve arka plan görevlerinde getiri

Aşağıdaki kod snippet'inde gösterilen yieldToMainBackground yöntemi, user-visible (orta) veya background önceliğine sahip uzun görevleri bölmek için kullanılır. Mantık, mevcutsa scheduler.yield()'ü uygular ancak orta öncelikli postTask'ü kullanarak ve son olarak Chromium olmayan tarayıcılarda setTimeout'ye geri dönerek farklılık gösterir.

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);
  });
};
Kullanıcı, PubConsent CMP'de "Tümünü Kabul Et" düğmesini tıkladıktan sonra kullanıcı arayüzünün güncellenmesini engelleyen uzun görevin nasıl optimize edildiğini gösteren akış. Bu beş adım artık mümkün olduğunda uygulanarak kullanıcı arayüzünün oluşturma işlemini daha erken güncellemesine olanak tanır.
yieldToMainBackground kullanılarak verim sağlanmasının, tarayıcının sonraki boyamayı (bu durumda CMP kullanıcı arayüzünü kapatarak) daha erken oluşturmasını nasıl sağladığını gösteren görsel temsil.

PubTech, oluşturma düzeni optimizasyonuyla TBT'yi nasıl daha da azalttı?

Getir stratejisi uygulandıktan sonra, CMP için INP'nin önemli ölçüde iyileştiği tespit edildi. Aslında, etkinlik işleyicinin işleme süresi önemli ölçüde azaltıldıktan sonra Kullanıcı arayüzünü kapat işlemi için sonraki boyama işleminde daha fazla oluşturma iyileştirmesi yapma fırsatı bulundu. Bu işlem, başlangıçta öğeleri DOM'dan kaldırmak için tasarlanmıştır. Bu durum, özellikle çok sayıda DOM düğümü olan web sitelerinde zorluklara neden oldu ve oluşturma işleminde beklenmedik bir artışa yol açtı.

Chrome Geliştirici Araçları'ndaki Performans panelinin ekran görüntüsü. PubConsent CMP'de bir kullanıcı arayüzü iletişim kutusunu kapatmak için etkinlik çağrı yığınını içeren bir izleme bölümünü gösterir. Kullanıcı arayüzü iletişim kutusunu kapatma görevi, etkileşimin sunum gecikmesine neden olan DOM düğümlerinin kaldırılmasını tetikler.

Öğeleri DOM'dan kaldırmak için gereken oluşturma çalışmasının artması sorununu gidermek amacıyla, ekibin "tembel oluşturma işlemini geri alma" olarak adlandırdığı bir çözüm kullanıma sunuldu. Bu yaklaşımda, kullanıcı gizleme izni verdikten sonra CMP izin iletişim kutusuna önce bir display: none CSS kuralı uygulanır. Ardından, requestIdleCallback kullanılarak CMP iletişim kutusuyla ilişkili DOM düğümlerinin kaldırılması, tarayıcının boşta olduğu daha sonraki bir noktaya kaydırılır. Bu yaklaşımın, kullanıcı rıza iletişim kutusunu kapattığı anda DOM düğümlerini kaldırmaktan çok daha hızlı olduğu kanıtlandı.

Chrome Geliştirici Araçları'ndaki Performans panelinin ekran görüntüsü. Öncekiyle aynı izlemeyi gösterir ancak optimize edilmiştir. PubConsent CMP'sinin iletişim kutusu kapatıldığında ilk işlem, CSS display: none kuralını kullanarak iletişim kutusunu gizlemektir. Daha sonra tarayıcı boştayken DOM düğümü kaldırma işlemi gerçekleştirilir.
DOM kaldırma görevini değiştirerek INP iyileştirmesini vurgulayan DevTools ekran görüntüsü.

PubTech, IAB TCF kitaplığını iyileştirerek INP'yi nasıl daha da azalttı?

CMP'nin yanıt verme sorunlarının çoğu başarıyla çözüldükten sonra, ana bağımlılıklarından biri olan IAB Şeffaflık ve Kullanıcı Rızası Çerçevesi (TCF) kitaplığında daha fazla iyileştirme fırsatı tespit edildi.

Bu kitaplığın en pahalı bileşenleri "dize oluşturma" ve "izin gönderme" idi. Bu bileşenler, IAB TCF kitaplığının ayrılmaz parçalarıdır. Bu bileşenlerde aşağıdaki optimizasyonlar, özellikle PubTech'in ihtiyaçları için ayrı bir çatalda uygulandı:

  1. Kullanıcının iznini okuması gereken her üçüncü taraf geri çağırma işlemi için yürütülen kod çözme işleminde hesaplanan sonuçların yeniden kullanılması.
  2. Kullanıcı izin verdiğinde yürütülen yayıncı kısıtlamaları kodlama sürecinde gereksiz döngülerden kaçınıldı ve bu döngüler azaltıldı.

Bu optimizasyonlardan ilki, CMP'nin IAB TCF kitaplığına bağlanan her üçüncü taraf geri çağırma işleminde harcadığı süreyi azalttı. İkinci optimizasyon, "dize oluşturma" bileşeninin neden olduğu işleme süresini azalttı. Bu optimizasyon, kullanıcı her izin verdiğinde yürütülen döngülerin% 60'ına kadar azaltılmasına olanak tanıdı.

Sonuçlar

Daha önce verimli olan stratejiler ve yeni oluşturma düzeni optimizasyonları uygulandığında CMP'nin INP'si%65'e kadar iyileşti. Sonuç olarak, PubConsent CMP'nin kullanıcı deneyiminin duyarlılığı büyük ölçüde iyileştirildi ve reklamların ne zaman isteneceği optimize edilerek bazı reklamlarda görüntülenebilirlik% 1,5 oranında arttı.

Bu iyileştirmelere ek olarak, IAB'nin TCF kitaplığında, TCF'den kaynaklanan uzun görevlerin% 85'e varan oranda azaltılması sonucunda etkilenen müşteriler için mobil cihazlarda INP'nin %77'ye varan oranda iyileştiği gözlemlendi. Bu sayede, bir sayfanın tüm yaşam döngüsü boyunca yürütülen her üçüncü taraf geri çağırma işleminin ek maliyeti önemli ölçüde azaltıldı.

PubConsent CMP kullanılırken INP'yi ileten kaynak sayısı, mobil cihazlarda %13'ten% 55'e çıkarak% 400'den fazla arttı. PubTech SDK'sında yapılan optimizasyonlar nedeniyle bazı müşteriler için sayfa INP'si yarıdan fazla oranda (470 milisaniyeden 230 milisaniyeye) düşürüldü.

PubTech CMP'yi kullanan siteler için kaynak INP geçiş oranlarının ekran görüntüsü. Masaüstünde, geçiş oranları yaklaşık% 84'ten %99,12'ye yükseldi. Mobil cihazlarda geçiş oranları yaklaşık% 22'den %55, 46'ya yükseldi.
HTTP Archive ve Chrome Kullanıcı Deneyimi Raporu (CrUX) tarafından bildirildiği üzere, PubTech CMP kullanan siteler için kaynak INP geçiş oranı.
RUM verilerinden elde edilen INP'yi 75. yüzdelik dilimde gösteren bir kontrol panelinin ekran görüntüsü. Temmuz/Ağustos 2023'ten itibaren INP 500 milisaniyenin hemen altındadır ancak Şubat 2024'ün ortasına kadar INP 200 milisaniyenin hemen altına düşerek "İyi" eşiğine ulaşır.
Bu örnek olayda açıklanan SDK değişiklikleriyle ilişkili olarak PubConsent müşteri mobil INP veri iyileştirme trendi.

Sonuç

PubTech'in müşterileri, optimizasyon çalışmalarımızdan elde edilen olumlu INP performansını ve işletme metriği sonuçlarını hemen fark etti. Müşterilerinden elde edilen paha biçilmez gerçek kullanıcı izleme (RUM) verilerinden yararlanarak PubConsent CMP için daha fazla performans iyileştirmesi üzerinde çalışılıyor. Bu veriler hem gerileme hem de ilerlemeleri yakından takip ederek PubTech'in sürekli iyileştirme çalışmalarını yönlendirir.

Üçüncü taraf olarak PubTech, işletme TPG'leri üzerinde olumsuz etkilerden kaçınırken web performansını geniş ölçekte iyileştirme ve daha iyi yanıt verme fırsatı elde ettiğini de fark etti. Bu tür iyileştirmeleri uygulamaya başlamak için hiçbir zaman geç değildir.

Bu yenilik çalışmasını destekleyen PubTech CTO'su Luca Coppola'ya ve Google'dan Jeremy Wagner, Michal Mocny ve Rick Viscomi'ye özel teşekkürler.