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 düşürdü?

Marco Prontera

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 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 sayfanın yanıt verme düzeyini 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üğmesi de PubConsent CMP mimarisinde aynı iş akışını uygular. Bu nedenle, bu örnek olayda ayrıntılı olarak açıklanan iyileştirmeler CMP ürününde bir dizi kullanıcı etkileşimini etkiledi.

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

PubTech, INP'yi düğmeler ve bağlantılar için nasıl optimize etti?

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 söz konusu yüksek öncelikli görevler için kabul edilebilir bir progresif geliştirme yöntemi olarak görülüyordu.

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 verim

Aşağıdaki kod snippet'inde gösterilen yieldToMainBackground yöntemi, user-visible (orta) veya background öncelikli uzun görevleri ayırmak için kullanılır. Mantık, kullanılabilirse 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);
  });
};

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

Getiri 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üne sahip web sitelerinde zorluklara yol açıyordu ve oluşturma işinde beklenmedik bir artışa yol açıyordu.

Öğ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 kaldırma" 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ı.

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, temel bağımlılıklarından birinde, IAB Şeffaflık ve Kullanıcı Rızası Çerçevesi (TCF) kitaplığı için daha fazla iyileştirme fırsatı belirlendi.

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. PubTech'in ihtiyaçlarına yönelik olarak, bu bileşenlere yönelik aşağıdaki optimizasyonlar 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 optimizasyonların ilki, IAB TCF kitaplığına bağlanan her bir üçüncü taraf geri çağırması için CMP'nin harcadığı süreyi azalttı. İkinci optimizasyon, "dize oluşturma" bileşeninin neden olduğu işleme süresini azalttı. Bu optimizasyon, kullanıcının her izin verdiğinde yürütülen döngülerin% 60'a kadar azaltılmasını sağladı.

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 bazı reklamlar için reklamların ne zaman isteneceği optimize edilerek 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ı. Bazı müşteriler için sayfa INP değeri, yapılan PubTech SDK optimizasyonları sayesinde yarıdan fazla azaltılarak 470 milisaniyeden 230 milisaniyeye düşürüldü.

Sonuç

PubTech'in müşterileri, optimizasyon çalışmalarımızın sonucunda ortaya çıkan olumlu INP performansını ve iş metriği sonuçlarını hemen fark etmeye başladı. PubConsent CMP'si için daha fazla performans iyileştirmesi yapılmaya başlandı ve müşterilerinden gelen paha biçilmez Gerçek Kullanıcı İzleme (RUM) verilerinden yararlanmak için çalışmaya devam ediyor. 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 çok 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.