Mail.ru'nun ana sayfasındaki Core Web Vitals'ı iyileştirmek için birkaç ay süren çalışma, kümülatif düzen kayması (CLS) metriğinin 75. yüzdelik diliminde% 60 artış sağladı. Bu artış, ortalama oturum süresini% 2,7 ve temel bölümlerin dönüşüm oranlarını %10'dan fazla artırdı.
Başladığımız yer
Mail.ru, Rusça konuşulan internetteki lider e-posta hizmetlerinden biridir ve trafik açısından Rusya'daki ilk 5 site arasındadır. Mail.ru, birçok kullanıcı için önemli bir kaynaktır. Ayda birkaç yüz milyon ziyaret alan bu portalda kullanıcılar e-posta, haberler, sosyal medya, performans odaklı internet aramaları ve daha birçok hizmete erişebilir.
Mail.ru, ziyaretçilerine yüksek kaliteli bir kullanıcı deneyimi sunmak istediği için Core Web Vitals'i iyileştirmeye yönelik çalışmalara başladı. Optimizasyon stratejimizi tartışmadan önce, Mail.ru ana sayfasıyla ilgili birkaç teknik ayrıntıya dikkat çekmek isteriz.
Proje uzun süredir şirket içi şablonlama motorumuz Fest kullanılarak geliştiriliyordu ancak 2019'da Svelte 3'e geçmeye başladık.
Svelte, reaktifliği Sanal DOM'u kullanmayan bir şekilde uygular. Bu da Svelte'i daha az kaynak yoğun hale getirir. Svelte'in yaklaşımı, kullanılmayan işlevleri üretim paketlerinden kaldırır. Bunun nedeni, işlevler kullanılmadığında bunları uygulayan kodun derleyici tarafından oluşturulmamasıdır. Derleme sırasında kullanılmayan kod kaldırılır. Bu sayede daha küçük paketler oluşturulur. Bu, sayfanın başlatılması sırasında Toplam Engelleme Süresi'ni (TBT) azaltmaya yardımcı olabilir.
Performans metriklerini izleme
Core Web Vitals'ı optimize etmeden önce sahada performansı değerlendirmek faydalı olur. Core Web Vitals'tan önce, dahili performans kontrol panelimizde ilk zengin içerikli boyama (FCP) gibi diğer metrikleri izliyorduk.
Metrik toplama komut dosyamız, Core Web Vitals'ı toplayıp görselleştirme için performans kontrol panelimize iletecek şekilde değiştirildi. Google'ın önerileri doğrultusunda, komut dosyamız metrik elde etmek için PerformanceObserver API'yi kullanır. Bu API, Mail.ru'daki evrensel ön uç "Platform"'un bir parçasıdır.
Kontrol panelinde, kullanıcılar için aşağıdaki metrikler gösteriliyordu (15-21 Mart 2021 haftasının ortalama değerleri):
| Metrik grubu adı | Önemli Web Verileri | Diğer Web Vitals metrikleri | |||||
|---|---|---|---|---|---|---|---|
| Metrik adı | LCP | FID | CLS | FCP | TBT | TTI | |
| Core Web Vitals eşiklerine göre kullanıcıların payı | iyi | %52 | %92 | %33 | %35 | %42 | %43 |
| needs-improvement | %19 | %5 | %23 | %38 | %16 | %25 | |
| yetersiz | %29 | %3 | %44 | %27 | %42 | %32 | |
Core Web Vitals'ı iyileştirme
Core Web Vitals'ı iyileştirmeyle ilgili birçok kılavuz olsa da her projenin kendine özgü zorlukları vardır. Mail.ru ana sayfası için aşağıdaki fırsatlar tespit edildi:
- CLS'yi azaltmak için reklam banner'ları için yer tutucular uygulama
- Largest Contentful Paint (LCP)'yi azaltmak için sunucu tarafı oluşturma (SSR) özelliğini kullanma
- LCP ve First Input Delay (FID)'i azaltmak için kod bölme.
CLS iyileştirmesi için iskeletler
CLS, Mail.ru ana sayfası için en kötü performans gösteren alan metriklerinden biriydi. Ardından, Chrome'un Geliştirici Araçları'ndaki Performans panelinde bu sayfanın profillenmesi, sorunun kaynağının reklamlar olduğunu ortaya çıkardı. Ekibimiz, düzen kararlılığını iyileştirmek için reklamlar yüklenmeden önce reklamlar için yer ayırmak üzere 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 reklam boyutları net bir şekilde belirtilmiş. Tasarım ekibiyle görüştükten sonra, içeriğin yüklenmesinin algılanan süresini kısalttığı için yer tutucu olarak SVG animasyonlu kullanıcı arayüzü iskeletleri kullanıldı.
SSR'nin dönüşü
Fest'ten Svelte'ye geçişi kolaylaştırmak için baştan başlamak yerine mevcut projeyi kademeli olarak yeniden yazdık. Mart 2021'e kadar kullanıcı arayüzünün büyük bir kısmını Svelte'ye taşıdık ve arka uç performans sorunlarını tespit edip düzelttikten sonra SSR'yi üretim uygulamamıza ekledik.
SSR'yi uyguladıktan sonra ekip, başlangıçta fark edilmeyen CLS gerileme nedenini keşfetti: Haber bölümü, sayfadaki ilk içerik oluşturulurken eklenmemişti. Sunucu tarafından sağlanan sayfa işaretlemesinin ilk boyanması ile istemciye haber bölümünün eklenmesi arasında gecikme vardı. Bu davranış, reklam iskeletinin kaymasına neden olarak CLS'yi kötüleştirdi.
Chrome'un Geliştirici Araçları, düzen kayması etkinlikleri gösterse de bunun nedenini ilk başta bulamadık. SSR sorunun kendisi olmasa da daha sonra çözümün bulunmasına yardımcı oldu. Boyama gecikmesinden sorumlu kodun düzeltilmesi, haber bileşeninin düzen kararlılığını iyileştirdi.
SSR'nin CLS'yi etkileyebileceği bir diğer faktör de bileşenlerin, hidrasyondan önce ve sonra hareket etmesidir. Bu da daha fazla düzen kaymasına neden olabilir. Bu sorunla özellikle mobil sürümde karşılaştık ve bu sorun, canlı bileşen işaretlemesine özel dikkat gösterilmesini gerektiriyordu. Bu soruna iyi bir çözüm, mümkün olduğunda JavaScript'ten CSS'ye mümkün olduğunca fazla görüntüleme mantığını aktarmaktı.
Kod bölme ve kullanılmayan çoklu dolgular
Algılanan sayfa yükleme hızını artırmak için LCP ve FID değerlerinin düşürülmesi gerekiyordu. Bunu yapmanın bir yolu kod bölme yöntemidir. Ekibimiz, Mail.ru ana sayfasının yanı sıra portalda gezinmek için bir widget da geliştiriyor. Şu anda şirketimizin birçok projesinde kullanılıyor.
Geçmişe dayalı nedenlerle widget, senkronize olarak yüklenen bir komut dosyası olarak sayfanın en başına eklenir. Bu komut dosyasındaki polyfill'lerin payı zaman içinde arttı. Bu polyfill'lerin yüklenmesinin olumsuz performans etkilerini sınırlamak için hem modern hem de eski tarayıcılarda kod bölme özelliğini uyguladık.
<script> öğesinin type="module" özelliği, ihtiyaçlarımıza yetecek kadar modern tarayıcıları hedeflemediğinden, modern veya eski tarayıcılar için JavaScript paketlerini yüklemek üzere module/nomodule kalıbını kullanmamaya karar verdik. Mail.ru, bu sorunu gidermek için arka uçta modern tarayıcı sürümlerini tanımlamak üzere şirket içi bir araç kullanır ve bu tarayıcılara uygun şekilde uyum sağlayabilir.
Tarayıcı arka uçta tanımlandıktan sonra, modern ve eski tarayıcılar için kod bölme özelliğini uyguladık. Sonuç olarak, modern tarayıcılar için eşzamanlı olarak yüklenen JavaScript widget'ının boyutu% 43,3 oranında küçültüldü. Bu uygulama diğer bazı portal komut dosyalarına da uygulandı.
Kod bölme, paket boyutunu küçültmenin ve Core Web Vitals'ı olumlu etkilemenin 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 pay düşüş eğiliminde.Bu nedenle, kod bölme özelliğini uygulamak, geliştiricilerimizin eski tarayıcılar için gerekli olan polyfill şişmesini tüm kullanıcılara sunmadan en son tarayıcı API'lerini kullanmasına olanak tanıdı.
Sonuçlar
Optimizasyon çalışmasından sonra, saha verilerimizde 24-30 Mayıs 2021 haftası için ortalama değerleri gözlemledik:
| Metrik grubu adı | Önemli Web Verileri | Diğer Web Vitals metrikleri | |||||
|---|---|---|---|---|---|---|---|
| Metrik adı | LCP | FID | CLS | FCP | TBT | TTI | |
| Core Web Vitals eşiklerine göre kullanıcıların payı | iyi | %58 (+6%) | %93 (+1%) | %93 (+60%) | %43 (+8%) | %49 (+%7) | %51 (+8%) |
| needs-improvement | %18 | %4 | %3 | %34 | %17 | %24 | |
| yetersiz | %24 | %3 | %4 | %23 | %34 | %25 | |
Aşağıdaki grafikler, web sayfası performans metrikleri değerlerinde "Platform"a göre yapılan değişiklikleri gösterir. Grafiklerdeki iki önemli tarihi not edin:
- 23 Mart 2021: Son sayfa bölümlerinin Svelte'ye taşındığı iterasyonun yayınlanması;
- 19 Nisan 2021: Döngünün, döndürülen SSR ve CLS gerilemelerini düzeltmek için değiştirilmiş düzenle yayınlanması.
1 Mayıs ile 10 Mayıs arasındaki değerlerdeki düşüş, Rusya'da Mayıs ayındaki tatillerden kaynaklanmaktadır.
"Platform" kullanılarak elde edilen sonuçlar, Chrome Kullanıcı Deneyimi Raporu'ndaki (CrUX) metrik değerlerinin artışıyla paraleldir.
İlk iyileştirmelerin kullanıma sunulmasından bir hafta önce ve kullanıma sunulmasından bir hafta sonra ortalama kullanıcı oturum süresi değerlerinin karşılaştırması% 2,7'lik bir artış olduğunu gösteriyor. Ayrıca, sayfanın çoğu bölümünde dönüşümde genel olarak önemli bir artış var. Özellikle Mail.ru e-posta uygulamasındaki dönüşümler %11,6, haber bölümünün dönüşümü ise %13,5 arttı.
%181
İyi CLS eşiğinin payını artırma
2,7%
Daha yüksek ortalama oturum süresi
13,5%
Haberler bölümünün dönüşüm oranını artırma
Elde ettiğimiz en beklenmedik sonuç, pazarlama banner'ının tıklama oranında (TO) %17,4 artış elde etmemiz oldu (SSR ve ön yükleme etiketlerinin kullanılması, banner'ın oluşturma süresini önemli ölçüde azalttı).
Sayfadaki diğer bölümleri analiz ettikten sonra, bunların büyük çoğunluğunda önemli ölçüde performans artışı olduğunu fark ettik. Sayfamızda önemli olmayan Hava Durumu ve Koronavirüs gibi bölümlerde bile dönüşümde sırasıyla% 9,6 ve %9,5 artış görüyoruz.
Sonuç
Performansı iyileştirmek, ilgili çalışmanın uzun sürmesi nedeniyle zordur. Zaman içinde metriklerdeki değişiklikleri düzenli olarak izlemeniz ve tüm yeni ürün özelliklerinin Temel Web Vitals'ta gerilemelere neden olmadığından emin olmanız gerekir. Bunu başarmak için performans bütçemizde Core Web Vitals'taki değişiklikleri izleriz.
En önemlisi, yöneticilerden tasarımcılara, test uzmanlarından kalite kontrolü ekibine kadar ürün ekibimizin tüm üyelerine Core Web Vitals'in önemini vurguladık. Her ekip üyesi, performans metriklerinden haberdar olmalı ve bunları iyileştirme yetkisine sahip olmalıdır. Ayrıca performans optimizasyonu hedeflerini düzenli aralıklarla iş süreçlerimize dahil ederiz. Yüksek kaliteli bir kullanıcı deneyimi sunmak yalnızca tüm ekip üyelerinin ortak çabasıyla mümkündür.