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ı?
Kullanıcı Rızası Yönetim Platformları (CMP'ler), web sitelerinin çerez ve izleme teknolojileri 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:
- PubConsent CMP ürününün INP üzerindeki etkisini en aza indirin.
- CMP ürünüyle ilişkili uzun görevleri azaltın.
- 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.
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 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, varsa scheduler.yield ile sonuç vererek ancak postTask varsa user-blocking (yüksek) öncelikli postTask'ye geri dönerek ve sonunda hiçbir şeye geri dönmeyerek yüksek öncelikli JavaScript görevlerini optimize etmek için tasarlanmıştır.
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 verim
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, 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);
});
};
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 düşürdü?
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 bir 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 zorluklar yarattı ve oluşturma işleminde beklenmedik bir artışa neden oldu.
Öğ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ı.
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ı:
- 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ı.
- 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ü.
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 ç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.