nereden başladık #
Mail.ru, Rusça konuşulan İnternet’teki önde gelen e-posta hizmetlerinden biridir ve trafik açısından Rusya’nın ilk 5 sitesinde. Mail.ru, birçok kişi için önemli bir kaynaktır. Ayda birkaç yüz milyon ziyaret alıyor ve insanların e-postaya, haberlere, sosyal medyaya, performanslı internet aramalarına ve daha fazlasına erişebildiği bir portal.
Mail.ru, ziyaretçilerine yüksek kaliteli bir kullanıcı deneyimi sunmak istedi, bu nedenle Önemli Web Verilerini iyileştirme çalışmaları başladı. Optimizasyon stratejimizi tartışmadan önce, Mail.ru ana sayfasının birkaç teknik detayına dikkat edilmelidir.
Proje uzun süredir şirket içi şablonlama motorumuz kullanılarak geliştirilmiş olsa da Şenlikgöç etmeye başladık İnce 3 2019’da
Svelte, reaktiviteyi şu şekilde uygular: Sanal DOM kullanmazbu da onu daha az kaynak yoğun hale getirir. Svelte’nin yaklaşımı, kullanılmayan işlevleri üretim paketlerinden kaldırır çünkü işlevler kullanılmıyorsa bunları uygulayan kod derleyici tarafından oluşturulmaz. Derleme sırasında kullanılmayan kod kaldırılarak daha küçük paketler elde edilir. Bu, sayfa başlatma sırasında Toplam Engelleme Süresinin (TBT) azaltılmasına yardımcı olabilir.
İzleme performansı metrikleri #
Önemli Web Verilerini optimize etmeden önce sahadaki performansı değerlendirmek faydalı olacaktır. Core Web Vitals’tan önce, First Contentful Paint (FCP) gibi diğer ölçümleri dahili performans kontrol panelimizde izliyorduk.
Ölçüm toplama komut dosyamız, Önemli Web Verilerini toplayacak ve bunları görselleştirme için performans panomuza iletecek şekilde değiştirildi. Google’ın önerileri doğrultusunda, komut dosyamız şunları kullanır: PerformanceObserver API’si parçası olan metrikleri elde etmek için evrensel ön uç “Platform” Mail.ru içinde.
Pano, kullanıcılar için aşağıdaki metrikleri gösterdi (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 | TBT | TTI | |
| Önemli Web Verileri eşiklerine göre kullanıcı payı | iyi | %52 | %92 | %33 | %35 | %42 | %43 |
| ihtiyaç iyileştirme | %19 | %5 | %23 | %38 | %16 | %25 | |
| fakir | %29 | %3 | %44 | %27 | %42 | %32 | |
Önemli Web Verilerini İyileştirme #
Core Web Vitals’ı iyileştirmek için pek çok kılavuz bulunsa da, her projenin kendine özgü zorlukları vardır. Mail.ru ana sayfası için aşağıdaki fırsatlar belirlendi:
CLS iyileştirmesi için iskeletler #
CLS, Mail.ru ana sayfası için en kötü performans gösteren alan ölçümlerinden biriydi. Bu sayfanın müteakip profil oluşturma Verim panel Chrome’un DevTools’u, sorunun kaynağının reklamlar olduğunu ortaya çıkardı. Düzen kararlılığını iyileştirmek için ekibimiz, yüklenmeden önce reklamlara yer ayırmak için yer tutucular kullanmaya karar verdi.
Yer tutucuları uygularken ilk adım, yer tutucuların yerini alacak içeriğin boyutlarını belirlemektir. Şans eseri, Mail.ru ana sayfasının masaüstü sürümü, reklamlar için kesinlikle belgelenmiş boyutlara sahiptir. Tasarım ekibiyle görüştükten sonra, SVG animasyonlu UI iskeletleri şu şekilde yer tutucu olarak kullanıldı: içeriğin algılanan yükleme süresini azaltırlar.
SSR’nin dönüşü #
Fest’ten Svelte’ye geçişi kolaylaştırmak için baştan başlamak yerine mevcut projeyi adım adım yeniden yazdık. Mart 2021’e kadar, ön ucun çoğunu Svelte’ye taşımıştık ve sonunda arka uç performans sorunlarını önceliklendirip düzelttikten sonra SSR’yi üretim uygulamamıza getirdik.
Ekip, SSR’yi uyguladıktan sonra, başlangıçta fark edilmeyen CLS gerilemesinin nedenini keşfetti: sayfadaki ilk içerik işlenirken haber bölümü eklenmemişti. Sunucu tarafından sağlanan sayfa işaretlemesinin ilk boyaması ile istemciye haber bölümünün eklenmesi arasında bir gecikme oldu. Bu davranış, CLS’yi kötüleştiren bir reklam iskeleti kaymasıyla sonuçlandı.
Chrome’un DevTools’u Layout Shift olaylarını gösterse de ilk başta bunun nedenini bulamadık. SSR’nin kendisi sorun olmasa da, daha sonra çözümün keşfedilmesine yardımcı oldu. Boyama gecikmesinden sorumlu olan kodun düzeltilmesi, haber bileşeninin düzen kararlılığını iyileştirdi.
SSR’nin CLS üzerinde sahip olabileceği bir başka etki de, daha fazla düzen değişikliğine yol açabilen, hidrasyondan önce ve sonra bileşenlerin hareketidir. Bununla özellikle mobil sürümde karşılaştık ve sulu bileşen işaretlemesine özel dikkat gösterilmesini gerektirdi. Bu soruna iyi bir çözüm, mümkün olduğunca çok görüntüleme mantığını JavaScript’ten CSS’ye aktarmaktı.
Kod bölme ve kullanılmayan çoklu doldurmalar #
Algılanan sayfa yükleme hızını iyileştirmek için LCP ve FID değerlerinin düşürülmesi için çalışma yapılması gerekiyordu. Bunu başarmanın bir yolu kod bölmedir. Mail.ru ana sayfasına ek olarak, ekibimiz portalda gezinmek için bir pencere öğesi geliştiriyor. Şu anda yerleşiktir Firmamızın birçok projesi.
Widget, tarihsel nedenlerden dolayı sayfanın en başına eşzamanlı olarak yüklenen bir komut dosyası olarak eklenir. Bu komut dosyasındaki çoklu dolguların payı zamanla arttı. Bu çoklu doldurmaları yüklemenin olumsuz performans etkilerini sınırlamak için hem modern hem de eski tarayıcılar için kod bölmeyi uyguladık.
aleyhine karar verdik module/nomodule model modern veya eski tarayıcılar için JavaScript paketlerini yüklemek için <script> elementler type="module" bağlanmak ihtiyaçlarımızı karşılayacak kadar modern olan tarayıcıları hedeflemedi. Mail.ru, bunu ele almak için arka uçtaki modern tarayıcı sürümlerini belirlemek için şirket içi bir araç kullanır ve bu tarayıcılara uygun şekilde uyum sağlayabilir.
Arka uçta tarayıcılar tanımlandıktan sonra, modern ve eski tarayıcılar için kod ayırmayı uyguladık. Sonuç, modern tarayıcılar için eşzamanlı olarak yüklenen JavaScript widget’ının boyutunda %43,3’lük bir azalma oldu. Bu uygulama diğer bazı portal betiklerine de uygulanmıştır.
Paket boyutunu küçültme ve Önemli Web Verileri üzerindeki olumlu etkilerine ek olarak kod bölme, geliştirici deneyimini de geliş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ölmeyi uygulamak, geliştiricilerimizin eski tarayıcılar için gerekli olan çoklu doldurma şişkinliğini tüm kullanıcılara sunmadan en son tarayıcı API’lerini kullanmalarına olanak sağladı.
Sonuçlar #
Optimizasyon çalışmasının ardından saha verilerimizde 24-30 Mayıs 2021 haftasına ait ortalama değerleri gözlemledik:
| Metrik grubu adı | Önemli Web Verileri | Diğer Web Verileri | |||||
|---|---|---|---|---|---|---|---|
| Metrik adı | LCP | FID | CLS | FCP | TBT | TTI | |
| Önemli Web Verileri eşiklerine göre kullanıcı payı | iyi | %58 (+%6) | %93 (+%1) | %93 (+%60) | %43 (+%8) | %49 (+%7) | %51 (+%8) |
| ihtiyaç iyileştirme | %18 | %4 | %3 | %34 | %17 | %24 | |
| fakir | %24 | %3 | %4 | %23 | %34 | %25 | |
Aşağıdaki grafikler, “Platform”a göre web sayfası performans metrik değerlerindeki değişiklikleri göstermektedir. Grafiklerdeki iki önemli tarihi not edin:
- 23 Mart 2021: Svelte’ye taşınan son sayfa bölümleriyle yinelemenin yayınlanması;
- 19 Nisan 2021: CLS regresyonlarını düzeltmek için döndürülen SSR ve düzen ile yinelemenin yayınlanması.
1 Mayıs’tan 10 Mayıs’a kadar olan değerlerdeki düşüş, Rusya’daki Mayıs tatillerinden kaynaklanmaktadır.
“Platform” kullanılarak elde edilen sonuçlar, metrik değerlerin büyümesiyle uyumludur. Chrome UX Raporu (CrUX).
İlk iyileştirmelerin kullanıma sunulmasından bir hafta önceki ve kullanıma sunulmasından bir hafta sonraki ortalama kullanıcı oturumu süresi değerlerinin karşılaştırılması, %2,7’lik bir büyüme 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ına yönelik dönüşümler %11,6, haber bölümünün dönüşümü ise %13,5 arttı.
Aldığımız en beklenmedik sonuç, pazarlama banner’ının Tıklama Oranında (TO) %17,4’lük bir artış oldu (oluşturma süresi, SSR ve ön yükleme etiketlerinin kullanıma sunulmasıyla önemli ölçüde azaldı).
Sayfadaki geri kalan bölümleri analiz ettikten sonra, büyük çoğunluğunda önemli performans artışı fark ettik. Sayfamızda anahtar olmayan Hava Durumu ve Coronavirüs gibi bölümler için bile dönüşümde sırasıyla %9,6 ve %9,5 artış görüyoruz.
Çözüm #
Performansı artırmak, işin uzaması nedeniyle zordur. Metriklerdeki değişiklikleri zaman içinde düzenli olarak izlemeli ve tüm yeni ürün özelliklerinin Önemli Web Verilerinde gerilemeye neden olmadığından emin olmalısınız. Bunu başarmak için performans bütçemizde Önemli Web Verilerindeki değişiklikleri izliyoruz.
En önemlisi, yöneticiler ve tasarımcılardan test uzmanlarına ve KG’ye kadar ürün ekibimizin tüm üyeleri için Önemli Web Verilerinin önemini vurguladık. Her ekip üyesi, performans metriklerinin farkında olmalı ve bunları iyileştirme yetkisine sahip olmalıdır. Performans optimizasyon hedeflerini de iş süreçlerimize düzenli bir şekilde dahil ediyoruz. Yüksek kaliteli bir kullanıcı deneyiminin başarılı bir şekilde sağlanması, ancak tüm ekip üyelerinin ortak çabasıyla mümkündür.