PubConsent CMP, Chrome Geliştirici Araçları'nın yardımıyla tespit edilen yanıt verme sorunlarını düzeltmek için tarayıcının Scheduler API'lerini kullanan bir getiri stratejisi kullanarak müşterileri için INP'yi nasıl% 64'e kadar azalttı?
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. Üçüncü taraf komut dosyaları olarak CMP'ler, temel amacının yasalara uygunluğu sağlamanın yanı sıra performans ve kullanıcı deneyimi üzerinde de minimum etkiye sahip olmalıdır.
PubConsent CMP, PubTech'in en son ürünüdür. Temel olarak performansa odaklanarak tasarlanan PubConsent CMP, hafif olacak şekilde tasarlanmıştır. Bu sayede optimum kullanıcı deneyimi sağlanır ve web sitesinin genel performansı üzerinde en az düzeyde etki sağlanır.
Sonraki Boyamayla Etkileşim (INP) metriğinin kullanıma sunulması, PubTech'in CMP'mizin yanıt verme hızıyla ilgili sorunları keşfetmesini sağladı. Bu örnek olay incelemesinde PubTech, PubConsent CMP platformunda yanıt verme ile ilgili sorunlarını nasıl çözdüğünü ve Mart 2024'te Önemli Web Verileri'nden biri haline gelmeden önce INP'yi nasıl iyileştirdiğini göstererek bir CMP ürününde mümkün olan en iyi performansı sağlama konusunda kararlı bir kararlılığa sahip olduğunu gösterir.
PubTech performansa neden önem verir?
Çoğu CMP gibi PubConsent CMP'si de kullanıcı rızası yönetim işlevini, site sayfalarında üçüncü taraf komut dosyası olarak uygulanmış olarak sunar. Yanıt verme dahil olmak üzere CMP teklifimizin performans etkisini azaltmak, başarılı bir CMP entegrasyonunu garantilemek için çok önemlidir.
Performansa öncelik veren ve PubConsent CMP komut dosyasını hafif tutan web sitesi sahipleri, kullanıcı deneyiminin kalitesini korurken değerli Kullanıcı Rızası Yönetimi işlevlerini kullanıma sunma arasında hassas bir denge kurabilir.
PubTech, CMP'nin sağladığı işlevselliğin ve performans üzerindeki etkisinin önemini dikkate alarak aşağıdaki hedefleri belirledi:
- PubConsent CMP ürününün INP üzerindeki etkisini en aza indirin.
- CMP ürünüyle ilişkilendirilebilecek uzun görevleri azaltın.
- Sayfanın INP'sini olumsuz yönde etkileyebilecek toplam engelleme süresini (TBT) azaltın.
INP nasıl ölçüldü?
PubTech, Chrome Geliştirici Araçları'nı kullanarak ilk analizi yapmıştır ve yavaş etkileşimleri manuel olarak teşhis etmiştir. Bu iş akışı, PubTech'in sayfa duyarlılığını etkileyen belirli sorunları tespit etmesini sağladı. Örneğin, tüm çerezleri kabul etmek ve ardından çerez izni iletişim kutusunu kapatmak için CMP ürünü içindeki 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 tamamlanıncaya kadar iletişim kutusunun kapatıldığını gösterecek şekilde güncellenmedi.
Tüm çerezleri kabul etme düğmesi gibi, tüm çerezleri reddetme veya çerez tercihlerini özelleştirme düğmesinin tümü de PubConsent CMP mimarisinde aynı iş akışını izler. Bu nedenle, bu örnek olayda ayrıntılı olarak açıklanan iyileştirmeler, CMP ürünündeki bir dizi kullanıcı etkileşimini etkiledi.
![Kullanıcı PubConsent CMP'sinde "Tümünü Kabul Et" düğmesini tıkladıktan sonra bir görevin ne kadar uzun bir görevin kullanıcı arayüzünün güncellenmesini engellediğini gösteren akış. Uzun bir görevi oluşturan beş adım vardır. Bu durum, kullanıcı arayüzünün yavaş çalışmasına neden olur.](https://web.developers.google.cn/static/case-studies/pubconsent-inp/image/fig-1.png?authuser=5&hl=tr)
Bu gecikme, görev esnasında panelin kilitli durumda olduğu görsel olarak algılanmasına neden oldu. Oluşturma güncellemesini algılanabilir ş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'sinde farklı getiri stratejileri benimsendi.
Yüksek öncelikli görevler teslim etme
Aşağıdaki kod snippet'inde gösterilen yieldToMainUiBlocking
yöntemi, varsa scheduler.yield
sonucunu verir, ancak postTask
kullanılabilirse user-blocking
(yüksek) önceliğe sahip postTask
yöntemine geri döner ve sonunda hiçbir şey olmamasını sağlayarak yüksek öncelikli JavaScript görevlerini optimize etmek için tasarlanmıştır.
yieldToMainUiBlocking
yöntemi, dahili CMP ayarları işlemlerini ve getiri elde ederken bu önceliği koruması gereken yüksek öncelikli işleri yönetecek şekilde tasarlandığından burada setTimeout
kullanımından kaçınılmıştır. Bu durum, yazı yazıldığında yalnızca Chromium tabanlı tarayıcılarda kullanılabilen ve yalnızca bu planlama API'lerini uygulayan tarayıcıların bu örnek olayda ayrıntılı olarak açıklanan iyileştirmelerden yararlanabileceği anlamına gelir. Yine de bu yaklaşım, yüksek öncelikli görevler için kabul edilebilir, kademeli bir gelişme olarak görüldü.
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 plandaki görevlerden faydalanın
Aşağıdaki kod snippet'inde gösterilen yieldToMainBackground
yöntemi, user-visible
(orta) veya background
önceliğine sahip uzun görevleri ayırmak için kullanılır. Mantık, varsa scheduler.yield()
öğesini uygular, ancak orta öncelikli olarak postTask
kullanılması ve son olarak Chromium harici Tarayıcılarda setTimeout
kullanımına geri çekilmesi nedeniyle farklıdır.
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'sinde "Tümünü Kabul Et" düğmesini tıkladıktan sonra kullanıcı arayüzünün güncellenmesini engelleyen görevin ne kadar süreyle optimize edildiğini gösteren akış. Bu beş adım, artık mümkün olduğunda sonuç verir ve kullanıcı arayüzünün, oluşturma işlemini daha kısa sürede güncellemesini sağlar.](https://web.developers.google.cn/static/case-studies/pubconsent-inp/image/fig-2.png?authuser=5&hl=tr)
yieldToMainBackground
kullanarak sonuç vermenin, tarayıcının bir sonraki boyamayı (bu durumda CMP kullanıcı arayüzünü kapatma) nasıl daha erken oluşturmasını sağladığına dair görsel temsil.
PubTech, oluşturma düzeni optimizasyonu ile TBT'yi nasıl daha da azalttı?
Getiri stratejisi uygulandıktan sonra, INP'nin CMP için önemli ölçüde iyileştiği görüldü. Hatta etkinlik işleyicinin işleme süresini önemli ölçüde kısalttıktan sonra, Kullanıcı Arayüzünü Kapat işlemi için bir sonraki boyamada oluşturmada daha fazla iyileştirme yapma fırsatı bulundu. Bu işlem başlangıçta öğeleri DOM'den kaldırmak için tasarlanmıştır. Bu durum, özellikle önemli sayıda DOM düğümü bulunan web sitelerinde zorluklar yaratarak oluşturma işlerinde beklenmeyen bir artışa yol açıyordu.
![Chrome Geliştirici Araçları'ndaki Performans panelinin ekran görüntüsü. Bu ekranda, PubConsent CMP'sinde kullanıcı arayüzü iletişim kutusunu kapatmak için etkinlik çağrı yığınını içeren bir iz bölümü gösteriliyor. Kullanıcı arayüzü iletişim kutusunu kapatma görevi, etkileşimin sunum gecikmesine katkıda bulunan DOM düğümlerinin kaldırılmasını tetikler.](https://web.developers.google.cn/static/case-studies/pubconsent-inp/image/fig-3.png?authuser=5&hl=tr)
Öğeleri DOM'den kaldırmak için gereken oluşturma işi miktarındaki artışı ele almak amacıyla, ekibin "gecikme kaldırma" adını verdiği bir çözüm sunuldu. Bu yaklaşım, kullanıcı CMP izin iletişim kutusunu gizlemeye izin verdikten sonra ilk olarak display: none
CSS kuralını uygular. Ardından, CMP iletişim kutusuyla ilişkili DOM düğümlerinin kaldırılması, daha sonra requestIdleCallback
kullanılarak tarayıcının boşta olduğu bir zamana kaydırılır. Bu yaklaşımın, kullanıcı rızası alma iletişim kutusunu kapattığı anda DOM düğümlerini kaldırmaktan çok daha hızlı olduğu ortaya çıktı.
![Chrome Geliştirici Araçları'ndaki Performans panelinin, öncekiyle aynı izi gösteren, ancak optimize edilmiş ekran görüntüsü. PubConsent CMP'nin iletişim kutusu kapatıldığında yapılacak ilk işlem, CSS display: none kuralını kullanarak bunu gizlemektir. Ardından, tarayıcı boşta kaldığında DOM düğümünü kaldırma işlemi gerçekleştirilir.](https://web.developers.google.cn/static/case-studies/pubconsent-inp/image/fig-4.png?authuser=5&hl=tr)
PubTech, IAB TCF kitaplığını iyileştirerek INP'yi nasıl daha da azalttı?
CMP'nin yanıt verme sorunlarının çoğunu başarıyla çözdükten sonra, temel bağımlılıklarından biri olan IAB Şeffaflık ve Kullanıcı Rızası Çerçevesi (TCF) kitaplığında iyileştirme yapılması için daha fazla fırsat belirlendi.
Bu kitaplığın işlem açısından en pahalı bileşenleri, "dize oluşturma" ve "gönderim izni"ydi. Bu bileşenler, IAB TCF kitaplığının ayrılmaz parçalarıdır. Bu bileşenlerde aşağıdaki optimizasyonlar, PubTech'in ihtiyaçlarına özel olarak ayrı bir çatal içinde uygulanmıştır:
- Kullanıcının iznini okuması gereken her üçüncü taraf geri çağırma işlemi için yürütülen kod çözme işlemi için 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üler önlendi ve azaltıldı.
Bu optimizasyonlardan ilki, IAB TCF kitaplığına bağlanan her üçüncü taraf geri çağırma işlemi için CMP'nin harcadığı süreyi azalttı. İkinci optimizasyon, "derleme dizeleri" bileşeninin neden olduğu işleme süresini kısalttı. Aslında bu optimizasyon, bir kullanıcı her izin verdiğinde yürütülen döngülerin% 60'ına kadar azalmaya olanak tanıdı.
Sonuçlar
Önceden etkili olan stratejiler ve yeni oluşturma düzeni optimizasyonları sayesinde, CMP'nin INP'si%65'e varan oranda gelişme gösterdi. Bunun sonucunda PubConsent CMP'nin kullanıcı deneyiminin duyarlılığı büyük ölçüde iyileştirildi.Reklam isteklerinin ne zaman optimize edilebileceği optimize edildiğinde, bazı reklamların görüntülenebilirliği% 1,5 oranında iyileştirildi.
Bu iyileştirmelere ek olarak, IAB'nin TCF kitaplığında, etkilenen müşteriler için INP'nin mobil cihazlarda% 77'ye kadar iyileştiği gözlemlendi. Bunun sonucunda TCF kaynaklı uzun görevlerin sayısı %85'e kadar azaldı. Bu, bir sayfanın tüm yaşam döngüsü boyunca yürütülen her üçüncü taraf geri çağırma işleminin ek yükünü önemli ölçüde azaltmaya yardımcı oldu.
PubConsent CMP'yi kullanırken INP'yi geçen kaynak sayısı, mobil cihazlarda %13'ten% 55'e yükselerek% 400'den fazla arttı. Yapılan PubTech SDK optimizasyonları nedeniyle bazı müşterilerde sayfa INP'si 470 milisaniyeden 230 milisaniyeye düşürüldü.
![PubTech CMP kullanan siteler için kaynak INP geçiş oranlarının ekran görüntüsü. Masaüstünde geçme oranları% 84'ten %99, 12'ye yükseldi. Mobil cihazlarda geçme oranları yaklaşık% 22'den %55, 46'ya yükseldi.](https://web.developers.google.cn/static/case-studies/pubconsent-inp/image/fig-5.png?authuser=5&hl=tr)
![75. yüzdelik dilimde RUM verilerinden INP değerini gösteren kontrol panelinin ekran görüntüsü. Temmuz/Ağustos 2023'ten itibaren INP 500 milisaniyenin biraz altında kalmıştır. Ancak Şubat 2024'ün ortalarında INP 200 milisaniyenin biraz altında kalmıştır ve bu nedenle "İyi" eşiğine gelmiştir.](https://web.developers.google.cn/static/case-studies/pubconsent-inp/image/fig-6.png?authuser=5&hl=tr)
Sonuç
PubTech'in müşterileri, optimizasyon çalışmalarımız sonucunda elde edilen pozitif INP performansı ve iş metriği sonuçlarını hemen fark etti. PubConsent CMP'si için performansta daha fazla iyileştirme de değerlendiriliyor. Böylece, müşterilerin paha biçilmez Gerçek Kullanıcı İzleme (RUM) verilerinden yararlanıyor. Bu veriler hem regresyonları hem de ilerlemeleri yakından izleyerek PubTech'in sürekli iyileştirme çabalarını destekler.
Üçüncü bir taraf olan PubTech, işletme TPG'leri üzerindeki olumsuz etkilerden kaçınarak web performansını geniş ölçekte iyileştirme ve daha iyi yanıt verme olanağı sunma olanağına da sahip olduğunu fark etti. Bu tür iyileştirmeleri uygulamaya başlamak için hiçbir zaman geç değil!
Bu yenilik çalışmalarına destek veren PubTech CTO'su Luca Coppola ve Google'dan Jeremy Wagner, Michal Mocny ve Rick Viscomi'ye çok teşekkür ederiz.