PubConsent CMP'nin, Chrome Geliştirici Araçları kullanılarak belirlenen yanıt verme sorunlarını düzeltmek için tarayıcının Scheduler API'lerini kullanan bir getiri stratejisinden yararlanarak müşterilerinin INP'yi nasıl% 64'e kadar azalttığını öğrenin.
Kullanıcı Rızası Yönetim Platformları (CMP'ler), çerezlerin ve izleme teknolojilerinin kullanımı için kullanıcı izni alarak web sitelerinin gizlilikle ilgili yönetmeliklere uymasına yardımcı olan araçlardır. CMP'ler, üçüncü taraf komut dosyaları olarak temel amacının yasalara uygunluğu sağlamanın yanı sıra performans ve kullanıcı deneyimi üzerinde asgari düzeyde etki yaratması gerekir.
PubConsent CMP, PubTech'in en yeni ürünüdür. Temel olarak performansa odaklanan PubConsent CMP, hafif olacak, optimum kullanıcı deneyimi sağlayacak ve genel web sitesi performansı üzerinde minimum etki sağlayacak şekilde tasarlanmıştır.
Sonraki Boyamayla Etkileşim (INP) metriğinin kullanıma sunulması, PubTech'in CMP'mizin yanıt verme hızıyla ilgili sorunları keşfetmesine olanak tanıdı. Bu örnek olayda PubTech, PubConsent CMP platformunda yanıt verme sorunlarını nasıl çözdüğünü ve Mart 2024'te Önemli Web Verileri'nden biri olmadan önce INP'yi nasıl iyileştirdiğini göstererek bir CMP ürününde mümkün olan en iyi performansı sunmaya yönelik sarsılmaz bir kararlılığa sahip olduğunu gösteriyor.
PubTech performansı neden önemsiyor?
Çoğu CMP gibi PubConsent CMP'si de, site sayfalarında üçüncü taraf komut dosyası olarak uygulanan kullanıcı rızası yönetim işlevini sunar. CMP teklifimizin performans üzerindeki etkisini azaltmak (yanıt verme dahil), başarılı bir CMP entegrasyonunu garanti etmek 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önetim işlevlerinden yararlanma arasında hassas bir denge kurabilir.
CMP'nin sağladığı işlevlerin önemi ve performans üzerinde gösterebileceği etki göz önünde bulundurulduğunda 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çülür?
PubTech, ilk analizi yapmak ve yavaş etkileşimleri manuel olarak teşhis etmek için Chrome Geliştirici Araçları'nı kullandı. Bu iş akışı, PubTech'in sayfanın yanıt verme düzeyini etkileyen belirli sorunları tespit etmesine olanak tanıdı. Örneğin, CMP ürünü içinde tüm çerezleri kabul etmek ve ardından çerez izni iletişim kutusunu kapatmak için gerçekleştirilen bir tıklama etkileşimi, uzun bir görev nedeniyle kullanıcı arayüzünde oluşturma işleminin gecikmesine neden olmuştur. Aşağıdaki resimde görebileceğiniz gibi kullanıcı arayüzü, uzun görev tamamlanana kadar iletişim kutusunun kapatıldığını gösterecek şekilde güncellenmemiştir.
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ündeki bir dizi kullanıcı etkileşimini etkilemiştir.
Bu gecikme, görev sırasında panelin kilitli durumda olduğu görsel olarak algılanmasına yol açtı. Sayfa INP'si, oluşturma güncellemeyi algılanabilecek kadar uzun bir süre boyunca engellediği için sayfanın INP'si olumsuz yönde etkilendi.
PubTech, INP'yi düğmeler ve bağlantılar için nasıl optimize etti?
INP'yi iyileştirmek için PubConsent CMP'sinde farklı getiri stratejileri uygulandı.
Yüksek öncelikli görevler verin
Aşağıdaki kod snippet'inde gösterilen yieldToMainUiBlocking yöntemi, mevcutsa scheduler.yield ile sonuç elde ederek ancak postTask kullanılabilir olduğunda user-blocking (yüksek) öncelikli postTask değerine geri döner ve sonuç olarak hiçbir şeyi geri almayarak yüksek öncelikli JavaScript görevlerini optimize etmek için tasarlanmıştır.
yieldToMainUiBlocking yöntemi, dahili CMP ayarları işlemlerini ve getiri sırasında bu öncelikleri koruması gereken yüksek öncelikli işleri yönetmek için tasarlandığından burada setTimeout kullanılmamıştır. Bu durum, bu örnek olayda ayrıntılı olarak açıklanan iyileştirmelerden yalnızca şu anda yalnızca yazı yazıldığı sırada Chromium tabanlı tarayıcılarda kullanılabilen bu planlama API'lerini uygulayan tarayıcıların yararlanacağı anlamına gelir. 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 düzey ve arka plandaki görevlere odaklanın
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, varsa scheduler.yield() değerini uygular, ancak orta öncelikli postTask kullanıldığında ve son olarak Chromium dışı Tarayıcılarda setTimeout kullanıldığında 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 kullanarak veri üretmenin, tarayıcının bir sonraki boyayı (bu örnekte CMP kullanıcı arayüzü kapatılıyor) daha erken oluşturmasına nasıl olanak tanıdığını gösteren görsel temsil.
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üresini önemli ölçüde kısalttıktan sonra, Kullanıcı arayüzünü kapat işlemine yönelik bir sonraki boyama için daha fazla oluşturma iyileştirmesi yapma fırsatı keşfedildi. Bu işlem başlangıçta öğeleri DOM'den kaldıracak şekilde tasarlanmıştı. 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'den kaldırmak için gereken oluşturma işinin artan miktarını gidermek amacıyla ekibin "lazy de-rendering" adlı bir çözüm sunduğu ortaya çıktı. Bu yaklaşım, kullanıcı gizlemeye izin verdikten sonra CMP izin iletişim kutusuna ilk olarak bir display: none CSS kuralı uygular. Ardından, CMP iletişim kutusuyla ilişkili DOM düğümlerinin kaldırılması, requestIdleCallback kullanılarak tarayıcının boşta olduğu daha sonraki bir noktaya kaydırılır. Bu yaklaşımın, kullanıcının rıza iletişim kutusunu kapattığı anda DOM düğümlerini kaldırmaktan çok daha hızlı olduğu anlaşıldı.
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 işlem açısından en pahalı bileşenleri "derleme dizeleri"dir. ve "görev dağıtımı izni" içerir. Bu bileşenler, IAB TCF kitaplığının dahili 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ı:
- Kullanıcının iznini okuması gereken her üçüncü taraf geri çağırması için yürütülen kod çözme süreci için hesaplanan sonuçları yeniden kullanma.
- Kullanıcı izin verdiğinde yürütülen yayıncı kısıtlamaları kodlama sürecinde gereksiz döngüler önlendi ve 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, "derleme dizeleri"nin neden olduğu işleme süresini kısalttı bir bileşenidir. 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
Önceden etkili olan stratejiler ve yeni oluşturma düzeni optimizasyonları sayesinde CMP'nin INP'si%65'e varan bir oranda arttı. Sonuç olarak, PubConsent CMP'nin kullanıcı deneyiminin duyarlılığı büyük ölçüde iyileştirildi.Ayrıca reklamların istendiği zamanları optimize edilerek bazı reklamlarda görüntülenebilirlik% 1,5 oranında arttı.
Bu iyileştirmelere ek olarak, IAB'nin TCF kitaplığında, TCF'nin neden olduğu uzun görevlerin% 85'e kadar azalmasının sonucunda etkilenen müşteriler için mobil cihazlarda INP'nin %77'ye kadar arttığı gözlemlendi. Bu sayede, bir sayfanın tüm yaşam döngüsü boyunca yürütülen her üçüncü taraf geri çağırmasının ek yükü önemli ölçüde azaltıldı.
PubConsent CMP kullanırken INP ileten kaynak sayısında artış, mobil cihazlarda %13'ten% 55'e yükselerek% 400'ün üzerinde artış gösterdi. 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 regresyonları hem de ilerlemeleri yakından izleyerek PubTech'in sürekli iyileştirme çabalarını artırır.
Üçüncü taraf olan PubTech, web performansını geniş ölçekte iyileştirme ve daha iyi yanıt verme olanağı sunma ve aynı zamanda işletme TPG'leri üzerinde olumsuz etkilerden kaçınma imkanına sahip olduğunu da fark etti. Bu tür iyileştirmeleri uygulamaya başlamak için hiçbir zaman geç değil!
Bu yenilik çalışmalarını destekleyen PubTech CTO'su Luca Coppola'ya ve Google'dan Jeremy Wagner, Michal Mocny ve Rick Viscomi'ye özel teşekkürlerimizi sunuyoruz.