Mail.ru'nun ana sayfasındaki Core Web Vitals'ı iyileştirmek için birkaç ay süren çalışmalar sonucunda, Cumulative Layout Shift'te (CLS) 75. yüzdelik dilimde% 60'lık bir artış görüldü. Bu sayede, ortalama oturum süresi% 2,7 ve temel bölümlerin dönüşüm oranları %10'dan fazla arttı.
Nereden başladık
Mail.ru, Rusça konuşulan İnternet'teki lider e-posta hizmetlerinden biridir ve trafik açısından Rusya'nın en iyi 5 sitesindedir. Mail.ru birçok kişi için önemli bir kaynaktır. Ayda birkaç yüz milyon ziyaret alan site, kullanıcıların e-posta, haberler, sosyal medya, performansla ilgili internet aramaları ve daha fazlasına erişebildiği bir portaldır.
Mail.ru, ziyaretçilerine yüksek kaliteli bir kullanıcı deneyimi sunmak istediğinden, Core Web Vitals'ı geliştirmeye yönelik çalışmalar başladı. Optimizasyon stratejimizden bahsetmeden önce, Mail.ru ana sayfasıyla ilgili birkaç teknik ayrıntıyı belirtmek istiyoruz.
Proje, şirket içi şablon oluşturma motorumuz Fest kullanılarak uzun süredir geliştirilmiş olsa da, 2019'da Svelte 3'e taşınmaya başladık.
Svelte, tepkiyi sanal DOM kullanmayan bir şekilde uyguladığı için kaynak kullanımını daha az artırır. Svelte'ın yaklaşımı, kullanılmayan işlevleri üretim paketlerinden kaldırır çünkü işlevler kullanılmadığı takdirde bunları uygulayan kod derleyici tarafından oluşturulmaz. Kullanılmayan kod, derleme sırasında kaldırılarak daha küçük paketler oluşturulur. Bu, sayfa başlatılırken Toplam Engelleme Süresi'nin (TBT) azaltılmasına yardımcı olabilir.
Performans metriklerini izleme
Önemli Web Verileri'ni optimize etmeden önce Sahadaki performansı değerlendirmek yararlı olur. Core Web Vitals'dan önce, dahili performans kontrol panelimizde First Contentful Paint (FCP) gibi diğer metrikleri izliyorduk.
Metrik toplama komut dosyamız, Önemli Web Verileri'ni toplayacak ve görselleştirme için performans kontrol panelimize iletecek şekilde değiştirildi. Komut dosyamız, Google'ın önerileri doğrultusunda, metrikleri elde etmek için Mail.ru içindeki evrensel ön uç "Platform"un bir parçası olan PerformanceObserver API'sini kullanır.
Kontrol panelinde kullanıcılar için şu metrikler gösteriliyordu (15-21 Mart 2021 haftası için ortalama değerler):
| Metrik grubu adı | Önemli Web Verileri | Diğer Web Verileri | |||||
|---|---|---|---|---|---|---|---|
| Metrik adı | LCP | FID | CLS | FCP | Henüz Belli Değil | TTI | |
| Önemli Web Verileri eşiklerine uygun kullanıcı payı | iyi | %52 | %92 | %33 | %35 | %42 | %43 |
| iyileştirme-ihtiyaçları | %19 | %5 | %23 | %38 | %16 | %25 | |
| yetersiz | %29 | %3 | %44 | %27 | %42 | %32 | |
Core Web Vitals'ı İyileştirme
Core Web Vitals'ı iyileştirmek için pek çok yol gösterici yeterli olsa da her projenin kendine özgü zorlukları vardır. Mail.ru ana sayfası için aşağıdaki fırsatlar tespit edilmiştir:
- CLS'yi azaltmak amacıyla reklam banner'ları için yer tutucular uygulama.
- Largest Contentful Paint (LCP) değerini azaltmak için sunucu tarafı oluşturma (SSR) kullanma.
- LCP ve First Input Delay (FID) verilerini azaltmak için kod bölme.
CLS'yi iyileştirmek için iskeletler
CLS, Mail.ru ana sayfasının en kötü performans gösteren alan metriklerinden biriydi. Chrome Geliştirici Araçları'nın Performans panelinde bu sayfanın daha sonra ele alınması, sorunun kaynağının reklamlar olduğunu ortaya çıkardı. Ekibimiz, düzen kararlılığını iyileştirmek amacıyla, reklamlar yüklenmeden önce yer ayırtmak için yer tutucular kullanmaya karar verdi.
Yer tutucuları uygularken ilk adım, bunların yerini alacak içeriğin boyutlarını belirlemektir. Neyse ki, Mail.ru ana sayfasının masaüstü sürümünde reklamlara ilişkin boyutlar kesin olarak belirtilmektedir. Tasarım ekibiyle konuştuktan sonra, içeriğin algılanan yüklenme süresini azaltmaları için SVG animasyonlu kullanıcı arayüzü iskeletleri yer tutucu olarak kullanıldı.
SSR'nin dönüşü
Fest'ten Svelte'a geçişi kolaylaştırmak için mevcut projeyi baştan yazmak yerine adım adım yeniden yazdık. Mart 2021'de ön ucun çoğunu Svelte'a taşıdık ve son olarak, arka uç performans sorunlarını öncelik sırasına koyup düzelttikten sonra SSR'yi üretim uygulamamıza getirdik.
Ekip, SSR'yi uyguladıktan sonra, CLS regresyonunun nedenini başlangıçta fark edilmedi: Sayfadaki ilk içerik oluşturulduğu anda haber bölümü eklenmemişti. Sunucu tarafından sağlanan sayfa işaretlemesinin ilk boyanması ile istemciye haber bölümünün eklenmesi arasında bir gecikme vardı. Bu davranış, CLS'yi kötüleştiren bir reklam iskelet değişikliğine yol açtı.
Chrome'un Geliştirici Araçları, Layout Shift etkinliklerini gösterse de başta bunun nedenini bulamadık. Sorun SSR'nin kendisi olmasa da, daha sonra çözümün keşfedilmesine yardımcı olmuştur. Boyama gecikmesinden sorumlu kodun düzeltilmesi, haber bileşeninin düzen kararlılığını iyileştirdi.
SSR'nin CLS üzerindeki bir başka etkisi de hidrasyondan önce ve sonra bileşenlerin hareket etmesidir. Bu da daha fazla düzen kaymasına yol açabilir. Bu sorunla özellikle mobil sürümde karşılaştık ve akışkan bileşen işaretlemesine özellikle dikkat edilmesi gerekiyordu. Mümkün olduğunda JavaScript'ten CSS'ye görüntüleme mantığı aktarmak, bu sorun için iyi bir çözümdür.
Kod bölme ve kullanılmayan çoklu dolgular
Algılanan sayfa yükleme hızını iyileştirmek için LCP ve FID değerlerinin azaltılması gerekiyordu. Bunu sağlamanın bir yolu da kod bölmeyi kullanmaktır. Ekibimiz, Mail.ru ana sayfasına ek olarak, portalda gezinmeye yönelik bir widget geliştirmektedir. Şu anda şirketimizin birçok projesinde yerleşik durumdadır.
Geçmişteki nedenlerle, widget sayfanın en başına eşzamanlı yüklenen bir komut dosyası olarak eklenir. Bu komut dosyasındaki çoklu dolguların payı zaman içinde arttı. Bu çoklu dolguları yüklemenin olumsuz performans etkilerini sınırlandırmak amacıyla hem modern hem de eski tarayıcılar için kod bölmeyi uyguladık.
<script> öğesinin type="module" özelliği ihtiyaçlarımıza göre yeterince modern olan tarayıcıları hedeflemediğinden, modern veya eski tarayıcılar için JavaScript paketlerini yükleme module/nomodule kalıbına itiraz ettik. Bu sorunu çözmek için Mail.ru arka uçta modern tarayıcı sürümlerini tanımlamak üzere şirket içi bir araç kullanıyor ve bu tarayıcılara uygun şekilde uyarlayabiliyor.
Tarayıcılar arka uçta tanımlanabildikten sonra modern ve eski tarayıcılar için kod bölme işlemini uyguladık. Sonuçta modern tarayıcılar için eşzamanlı yüklenen JavaScript widget'ı boyutunda% 43,3 küçülme oldu. Bu uygulama, diğer bazı portal komut dosyalarına da uygulandı.
Kod bölme, paket boyutunun küçültülmesini ve Core Web Vitals üzerindeki olumlu etkilerinin yanı sıra geliştirici deneyimini de iyileştirir. Kullanıcılarımızın yalnızca% 3,5'i eski tarayıcıları kullanıyor ve bu paylaşım düşüş eğiliminde.Bu nedenle kod bölmenin uygulanması geliştiricilerimizin, eski tarayıcılar için gereken polyfill şişesini tüm kullanıcılara sunmadan en yeni tarayıcı API'lerini kullanabilmelerini sağladı.
Sonuçlar
Optimizasyon çalışmasından sonra, alan verilerimizde 24-30 Mayıs 2021 haftası için ortalama değerleri gözlemledik:
| Metrik grubu adı | Önemli Web Verileri | Diğer Web Verileri | |||||
|---|---|---|---|---|---|---|---|
| Metrik adı | LCP | FID | CLS | FCP | Henüz Belli Değil | TTI | |
| Önemli Web Verileri eşiklerine uygun kullanıcı payı | iyi | %58 (+%6) | %93 (+%1) | %93 (+%60) | %43 (+%8) | %49 (+%7) | %51 (+%8) |
| iyileştirme-ihtiyaçları | %18 | %4 | %3 | %34 | %17 | %24 | |
| yetersiz | %24 | %3 | %4 | %23 | %34 | %25 | |
Aşağıdaki grafiklerde, "Platforma" göre web sayfası performans metriği değerlerindeki değişiklikler gösterilmektedir. Grafiklerdeki iki önemli tarihe dikkat edin:
- 23 Mart 2021: Son sayfa bölümleriyle iterasyon yani yinelemenin Svelte'a taşınması;
- 19 Nisan 2021: Döndürülen SSR ve düzen, CLS regresyonlarını düzeltmek için değiştirilmiş iterasyonun kullanıma sunulması.
1 Mayıs ile 10 Mayıs arasındaki değerlerde yaşanan düşüş, Rusya'daki Mayıs tatillerinden kaynaklanmaktadır.
"Platform" kullanılarak elde edilen sonuçlar, Chrome Kullanıcı Deneyimi Raporu'ndaki (CrUX) metrik değerlerindeki artışla uyumludur.
Ortalama kullanıcı oturumu süresi değerlerinin, ilk iyileştirmelerin kullanıma sunulmasından bir hafta önce ve kullanıma sunulduktan bir hafta sonraki sürenin karşılaştırmasında% 2,7'lik bir büyüme olduğu görülmektedir. Ayrıca, sayfanın çoğu bölümündeki dönüşümlerde genel olarak önemli bir artış vardır. Özellikle Mail.ru e-posta uygulamasının dönüşümleri %11,6, haber bölümünün dönüşümü ise %13,5 arttı.
%181
İyi CLS eşiğinin payında artış
%2,7
Daha yüksek ortalama oturum süresi
%13,5
Haber bölümü dönüşüm oranında artış
En beklenmedik sonuç, pazarlama banner'ının Tıklama Oranında (TO) %17,4'lük bir artış oldu (SSR ve önceden yükleme etiketlerinin sunulmasıyla oluşturma süresi önemli ölçüde azaldı).
Sayfadaki geri kalan bölümleri analiz ettikten sonra, bunların büyük çoğunluğunda önemli bir performans iyileşmesi olduğunu fark ettik. Sayfamızın temel öğeleri arasında yer almayan Hava Durumu ve Koronavirüs gibi bölümlerde bile dönüşüm oranlarında sırasıyla% 9,6 ve %9,5 artış görüyoruz.
Sonuç
Çalışmaların uzun sürmesi nedeniyle performansı iyileştirmek zordur. Metriklerde zaman içindeki değişiklikleri düzenli olarak izlemeli ve tüm yeni ürün özelliklerinin Önemli Web Verileri'nde regresyona neden olmadığından emin olmalısınız. Bunu başarmak için performans bütçesinde Core Web Vitals'taki değişiklikleri izleriz.
En önemlisi, yöneticilerden tasarımcılara, test kullanıcılarına ve kalite güvencesine kadar ürün ekibimizin tüm üyelerine Core Web Vitals'ın önemini vurguladık. Her ekip üyesi, performans metriklerinden haberdar olmalı ve bunları iyileştirme konusunda güçlü olmalıdır. Ayrıca, performans optimizasyonu hedeflerini iş süreçlerimize düzenli olarak dahil ediyoruz. Yüksek kaliteli bir kullanıcı deneyimini başarıyla sunmak yalnızca tüm ekip üyelerinin ortak çabasıyla mümkündür.