INP'yi düzeltmeyle ilgili Economic Times arayışı

TBT'yi 30 kat azaltıp Next.js'e geçiş yapan The Ecomonic Times, INP'yi yaklaşık dört kat azalttı. Bu da hemen çıkma oranında% 50'lik bir düşüşe ve sayfa görüntüleme sayısında% 43'lük bir artışa yol açtı.

Daya Ram Yadav
Daya Ram Yadav
Saurabh Rajpal
Saurabh Rajpal

Interaction to Next Paint (INP), bir web sitesinin kullanıcı girişine yanıt verme hızını değerlendiren bir metriktir. Sayfanın kullanıcı etkileşimlerine hızlı yanıt vermesi, sayfanın duyarlılığının iyi olduğunu gösterir. Bir sayfanın INP değeri ne kadar düşükse kullanıcı etkileşimlerine o kadar iyi yanıt verebilir.

İyi INP değerleri 200 milisaniye veya daha az, kötü değerler 500 milisaniyeden fazladır. Bu değerler arasındaki değerlerde iyileştirme yapılması gerekir.

Bulanık başlangıç

Google, INP'yi ilk olarak Core Web Vitals metriklerinden biri haline gelebilecek deneysel bir metrik olarak kullanıma sunduğunda Economic Times ekibi, dünya standartlarında bir kullanıcı deneyimi sunmak temel işletme değerlerimiz açısından çok önemli olduğundan, INP'yi Core Web Vitals metriği haline gelmeden önce düzeltme görevini üstlendi.

INP, bugüne kadar çözülmesi en zor metriklerden biri olmuştur. Başlangıçta, INP'nin etkili bir şekilde nasıl ölçüleceği net değildi. Bu süreci daha da zorlaştıran, gerçek kullanıcı izleme (RUM) sağlayıcılarının çoğunun henüz bu özelliği desteklememesi de dahil olmak üzere topluluk desteğinin olmamasıydı. Ancak Chrome Kullanıcı Deneyimi Raporu (CrUX), web-vitals JavaScript kitaplığı gibi Google RUM araçlarımız ve bunları destekleyen diğer araçlar sayesinde, ilerleyeceğimiz yolu değerlendirirken nerede olduğumuzu anlayabildik. Başladığımızda kaynak düzeyinde INP'miz 1.000 milisaniyeye yakındı.

Alanda INP'yi düzeltirken ortaya çıkan bir şey, hedeflenecek laboratuvar metriklerinden birinin Toplam Engelleme Süresi (TBT) olabileceğiydi. Geçmişe Dönüş özelliği, topluluk tarafından zaten iyi biliniyor ve destekleniyor. Core Web Vitals eşiklerini zaten karşılıyor olsak da TBT konusunda o kadar iyi değildik. Başladığımızda bu süre 3 saniyenin üzerindeydi.

Geçmişe Dönen Zaman Kapsülü özelliği nedir ve bu özelliği iyileştirmek için hangi adımları attık?

TBT, bir web sayfasının sayfa yükleme sırasında kullanıcı girişine yanıt verme hızını ölçen bir laboratuvar metriğidir. Yürütülmesi 50 milisaniyeden uzun süren tüm görevler uzun görev olarak kabul edilir ve 50 milisaniye eşiğinin üzerindeki süre engelleme süresi olarak bilinir.

TBT, sayfa yükleme sırasındaki tüm uzun görevlerin engelleme süresinin toplamı alınarak hesaplanır. Örneğin, yükleme sırasında iki uzun görev varsa engelleme süresi aşağıdaki şekilde belirlenir:

  • A görevi 80 milisaniye (50 milisaniyeden 30 milisaniye daha uzun) sürer.
  • Görev B 100 milisaniye (50 milisaniyeden 50 milisaniye daha uzun) sürer.

Sayfanın TBT değeri: 80 milisaniye (30 + 50). TBT ne kadar düşük olursa o kadar iyidir. TBT ayrıca INP ile iyi bir korelasyona sahiptir.

Aşağıda, iyileştirme adımları uygulanmadan önceki ve uygulandıktan sonraki TBT'mizin kısa bir laboratuvar karşılaştırması verilmiştir:

Chrome Geliştirici Araçları'nın performans panelinde gösterildiği gibi, başlatma sırasındaki uzun görevlerin birleştirilmiş resmi ve sayfa metriklerinin raporu. Ana iş parçacığı,sayfa yükleme sırasında 3.260 milisaniye boyunca engellendi.
TBT'yi optimize etmeden önce başlatma sırasındaki ana mesaj dizisi. TBT 3.260 milisaniyedir.
Chrome Geliştirici Araçları'nın performans panelinde gösterildiği gibi, başlatma sırasındaki uzun görevlerin birleştirilmiş resmi ve sayfa metriklerinin raporu. Ana iş parçacığı, sayfa yükleme sırasında 120 milisaniye boyunca engellenir.
TBT'yi optimize ettikten sonra başlatma sırasındaki ana iş parçacığı. TBT 120 milisaniyedir.

Ana iş parçacığının işini en aza indirme

Tarayıcının ana iş parçacığı; HTML'yi ayrıştırmaktan, DOM'u oluşturmaktan, CSS'yi ayrıştırıp stilleri uygulamaya ve JavaScript'i değerlendirmeye ve yürütmeye kadar her şeyi yönetir. Ana iş parçacığı, kullanıcı etkileşimlerini (ör. tıklama, dokunma ve tuş basma) de yönetir. Ana iş parçacığı başka bir iş yapmakla meşgulse kullanıcı girişlerine verimli bir şekilde yanıt vermeyebilir ve bu da sarsıntılı bir kullanıcı deneyimine yol açabilir.

Abonelik durumuna göre reklam yayınlamak için kullanıcı kimliğini algılayan kendi algoritmalarımız ve A/B testi, analizler ve daha fazlası için üçüncü taraf komut dosyaları olduğundan bu bizim için en zor görevdi.

İlk başta, daha az kritik işletme öğelerinin yüklenmesine öncelik vermeme gibi küçük adımlar attık. İkinci olarak, kritik olmayan işler için requestIdleCallback kullandık. Bu, TBT'yi azaltmaya yardımcı olabilir.

if ('requestIdleCallback' in window) {
 
this.requestIdleCallbackId = requestIdleCallback(fetchMarketsData.bind(this), {timeout: 3000});
} else {
  fetchMarketsData
(); // Fallback in case requestIdleCallback is not supported
}

requestIdleCallback kullanılırken zaman aşımı belirtilmesi önerilir. Belirtilen süre dolduktan sonra geri çağırma çağrılmamışsa geri çağırma işleminin zaman aşımından hemen sonra yürütülmesini sağlar.

Komut dosyası değerlendirme süresini en aza indirme

Ayrıca, Yüklenebilir bileşenler'i kullanarak üçüncü taraf kitaplıklarını geç yükledik. Ayrıca, Chrome Geliştirici Araçları'ndaki kapsam aracını kullanarak sayfanın profilini çıkararak kullanılmayan JavaScript ve CSS'leri de kaldırdık. Bu sayede, sayfa yükleme sırasında daha az kod göndermek için ağaç sallama işleminin gerekli olduğu alanları belirleyebildik ve dolayısıyla uygulamanın ilk paket boyutunu küçülttük.

Chrome Geliştirici Araçları'ndaki kapsam aracının ekran görüntüsü. Burada araç, sayfa yükleme sırasında JavaScript ve CSS dosyalarının kullanılmayan bölümlerini gösterir.

DOM boyutunu küçültme

Lighthouse'a göre büyük DOM boyutları bellek kullanımını artırır, stil yeniden hesaplamalarının uzun sürmesine neden olur ve yüksek maliyetli düzen yeniden düzenlemeleri üretir.

Lighthouse'taki DOM boyutu denetiminin ekran görüntüsü. Bildirilen DOM öğelerinin sayısı 2.706 öğedir.

DOM düğümlerinin sayısını iki şekilde azalttık:

  • Öncelikle, menü öğelerimizi kullanıcının isteği üzerine (tıklamayla) oluşturduk. DOM boyutu yaklaşık 1.200 düğüm azaltıldı.
  • İkinci olarak, daha az önemli widget'ları yavaş yükledik.

Tüm bu çabalar sayesinde TBT'yi önemli ölçüde azalttık ve INP'miz de buna bağlı olarak neredeyse %50 oranında azaldı:

CrUX'taki INP denetiminin ekran görüntüsü. Sayfanın INP değeri 539 milisaniyedir ve bu değer "yetersiz" eşiğini aşar.

Bu noktada, TBT'yi (ve dolaylı olarak INP'yi) daha da azaltmak için kolayca uygulayabileceğimiz çözümler neredeyse tükenmişti ancak iyileştirmeye çok yer olduğunu biliyorduk. Bu noktada, özel olarak oluşturulmuş kullanıcı arayüzü şablonumuzu React'in en son sürümüne ve Next.js'e yükseltmeye karar verdik. Böylece, bileşenlerin gereksiz yere yeniden oluşturulmasını önlemek için kancalardan daha iyi yararlanabilecektik.

Web sitesinin diğer bölümlerine kıyasla daha sık güncellemeler ve nispeten daha az trafik nedeniyle konu sayfalarımızı Next.js'e taşımaya başladık. Ayrıca, kritik olmayan görevleri ertelemek için requestIdleCallBack gibi tekniklerin yanı sıra ana iş parçacığındaki ek ağır işleri web işçilerine aktarmak için PartyTown'u kullandık.

INP'nin iyileştirilmesi The Economic Times'a nasıl yardımcı oldu?

Kaynaktaki mevcut TBT ve INP

Bu gönderi yayınlanırken kaynağımızın TBT değeri 120 milisaniyeydi. Bu değer, optimizasyon çalışmalarımıza başladığımızdaki 3.260 milisaniyeden daha düşüktü. Benzer şekilde, optimizasyon çalışmalarımız sonrasında kaynağımızın INP'si 257 milisaniyeye düştü. Bu değer, 1.000 milisaniyeden fazlaydı.

CrUX'taki INP denetiminin ekran görüntüsü. Sayfanın INP değeri 257 milisaniyedir ve bu değer "iyileştirme gerektiriyor" eşikleri dahilindedir.

INP CrUX trendi

Konu sayfalarında alınan trafik, genel trafiğin çok daha küçük bir bölümünü temsil eder. Bu nedenle, deneme yapmak için ideal bir yerdi. CrUX sonuçları ve işletme sonuçları çok cesaret vericiydi. Daha fazla avantaj elde etmek için çabalarımızı web sitesinin tamamına yaymamıza yol açtı.

Temmuz 2022'den Ekim 2022'ye kadar olan dört aylık dönemde CrUX'ta görselleştirilen INP dağılımları ekran görüntüsü. "Yetersiz" ve "İyileştirme gerekiyor" eşiklerindeki değerler biraz düştü, "İyi" eşikindeki değerler ise arttı.

Akamai mPulse TBT Analizi

RUM çözümümüz olarak, sahada TBT'yi ölçen Akamai mPulse'ı kullanırız. TBT'de tutarlı bir düşüş gözlemledik. Bu düşüş, INP'yi azaltma çalışmalarımızın sonuçlarıyla açıkça ilişkili. Aşağıdaki ekran görüntüsünde görüldüğü gibi, TBT değerleri sonunda yaklaşık 5 saniyeden alanda yaklaşık 200 milisaniyeye düştü.

Yaklaşık bir ay boyunca TBT'de düşüş gösteren Akamai mPulse grafiğinin ekran görüntüsü.

İşletme sonucu

Genel olarak, TBT'yi 30 kat azaltma çalışmalarımız ve Next.js'e geçişimiz, INP'yi yaklaşık 4 kat azaltmamıza yardımcı oldu. Bu da konu sayfalarında hem hemen çıkma oranında% 50'lik bir düşüşe hem de sayfa görüntüleme sayısında% 43'lük bir artışa yol açtı.

Sayfa görüntüleme sayısının hemen çıkma oranıyla karşılaştırıldığı Google Analytics ekran görüntüsü. The Economic Times web sitesinde INP'de yapılan optimizasyonlar sayesinde hemen çıkma oranında% 50 düşüş ve sayfa görüntüleme sayısında% 43 artış elde edildi.

Sonuç

Özetlemek gerekirse INP, Economic Times web sitesinin bazı bölümlerindeki çalışma zamanındaki performans sorunlarını belirlemeye büyük ölçüde yardımcı oldu. İşle ilgili sonuçları olumlu yönde etkileyen en etkili metriklerden biri olduğu kanıtlanmıştır. Bu çalışmanın sonucunda gözlemlediğimiz çok cesaret verici rakamlar sayesinde, optimizasyon çalışmalarımızı web sitemizin diğer alanlarına ölçeklendirmek ve ek avantajlardan yararlanmak için motive olduk.