Kegiatan selama beberapa bulan untuk meningkatkan Data Web Inti di halaman beranda Mail.ru menghasilkan peningkatan persentil ke-75 dalam persentil ke-75 dalam Pergeseran Tata Letak Kumulatif (CLS), yang meningkatkan waktu sesi rata-rata sebesar 2,7%, dan rasio konversi bagian inti sebesar lebih dari 10%.
Tempat kami memulai
Mail.ru adalah salah satu layanan email terkemuka di Internet berbahasa Rusia dan berada di 5 situs teratas di Rusia dalam hal traffic. Mail.ru adalah referensi penting bagi banyak orang. Google Cloud menerima ratusan juta kunjungan per bulan, dan merupakan portal tempat orang-orang dapat mengakses email, berita, media sosial, penelusuran internet berbasis performa, dan lain-lain.
Mail.ru ingin memberikan pengalaman pengguna berkualitas tinggi kepada pengunjungnya, sehingga upaya mereka mulai meningkatkan Data Web Inti. Sebelum membahas strategi pengoptimalan kami, beberapa detail teknis halaman beranda Mail.ru harus diperhatikan terlebih dahulu.
Meskipun project ini sudah lama dikembangkan menggunakan mesin template internal kami Fest, kami mulai bermigrasi ke Svelte 3 pada tahun 2019.
Svelte menerapkan reaktivitas dengan cara yang tidak menggunakan DOM Virtual, sehingga mengurangi penggunaan resource. Pendekatan Svelte menghapus fungsi yang tidak digunakan dari paket produksi karena kode yang menerapkannya tidak dihasilkan oleh compiler jika fungsi tidak digunakan. Kode yang tidak digunakan akan dihapus selama kompilasi sehingga menghasilkan paket yang lebih kecil. Tindakan ini dapat membantu mengurangi Total Blocking Time (TBT) selama startup halaman.
Melacak metrik performa
Sebelum mengoptimalkan Data Web Inti, sebaiknya evaluasi performa di lapangan. Sebelum Core Web Vitals, kami melacak metrik lain, seperti First Contentful Paint (FCP), di dasbor performa internal kami.
Skrip pengumpulan metrik kami diubah untuk mengumpulkan Data Web Inti dan mengirimkannya ke dasbor performa untuk visualisasi. Sesuai dengan rekomendasi Google, skrip kami menggunakan PerformanceObserver API untuk mendapatkan metrik, yang merupakan bagian dari "Platform" frontend universal di dalam Mail.ru.
Dasbor menampilkan metrik berikut untuk pengguna (nilai rata-rata untuk minggu yang dimulai dari 15-21 Maret 2021):
| Nama grup metrik | Data Web Inti | Data Web Lainnya | |||||
|---|---|---|---|---|---|---|---|
| Nama metrik | LCP | FID | CLS | FCP | TBT | TTI | |
| Pangsa pengguna sesuai dengan nilai minimum Data Web Inti | bagus | 52% | 92% | 33% | 35% | 42% | 43% |
| peningkatan kebutuhan | 19% | 5% | 23% | 38% | 16% | 25% | |
| buruk | 29% | 3% | 44% | 27% | 42% | 32% | |
Meningkatkan Data Web Inti
Meskipun banyak panduan tersedia untuk meningkatkan Data Web Inti, setiap project memiliki tantangan unik. Untuk halaman beranda Mail.ru, peluang berikut teridentifikasi:
- Menerapkan placeholder untuk banner iklan guna mengurangi CLS.
- Menggunakan rendering sisi server (SSR) untuk mengurangi Largest Contentful Paint (LCP).
- Pemisahan kode untuk mengurangi LCP dan Penundaan Input Pertama (FID).
Kerangka untuk peningkatan CLS
CLS adalah salah satu metrik kolom berperforma terburuk untuk halaman beranda Mail.ru. Pembuatan profil selanjutnya di halaman ini di panel Performance di Chrome DevTools menunjukkan bahwa iklan adalah sumber masalahnya. Guna meningkatkan stabilitas tata letak, tim kami memutuskan untuk menggunakan placeholder untuk memesan ruang iklan sebelum dimuat.
Saat menerapkan {i>placeholder<i}, langkah pertama adalah menentukan dimensi konten yang akan menggantikannya. Untungnya, versi desktop halaman beranda Mail.ru memiliki ukuran yang didokumentasikan secara ketat untuk iklan. Setelah berbicara dengan tim desain, kerangka UI animasi SVG digunakan sebagai placeholder karena mengurangi waktu pemuatan konten yang dirasakan.
Kembalinya SSR
Untuk memudahkan transisi dari Fest ke Svelte, kami secara bertahap menulis ulang project yang ada, bukan memulai dari awal. Pada Maret 2021, kami telah memigrasikan sebagian besar frontend ke Svelte, dan akhirnya membawa SSR ke aplikasi produksi kami setelah menanggulangi dan memperbaiki masalah performa backend.
Setelah menerapkan SSR, tim menemukan penyebab regresi CLS yang awalnya tidak diperhatikan: bagian berita tidak disisipkan pada saat merender konten pertama di halaman. Ada penundaan antara penggambaran awal markup halaman yang disediakan oleh server dan penyisipan bagian berita pada klien. Perilaku ini mengakibatkan pergeseran kerangka iklan, yang memperburuk CLS.
Meskipun DevTools Chrome menampilkan peristiwa Layout Shift, kami tidak dapat menemukan alasannya pada awalnya. Meskipun SSR sendiri bukan masalahnya, SSR membantu menemukan solusinya di kemudian hari. Memperbaiki kode yang menyebabkan penundaan pengecatan akan meningkatkan stabilitas tata letak komponen berita.
Efek lain yang dapat dimiliki SSR terhadap CLS adalah pergerakan komponen sebelum dan setelah hidrasi, yang dapat menyebabkan pergeseran tata letak lebih lanjut. Kami menemukan hal ini khususnya pada versi seluler dan perlu perhatian khusus pada markup komponen terhidrasi. Solusi yang baik untuk masalah ini adalah mentransfer sebanyak mungkin logika tampilan dari JavaScript ke CSS.
Pemisahan kode dan polyfill yang tidak digunakan
Untuk meningkatkan kecepatan pemuatan halaman yang dirasakan, Anda perlu menurunkan nilai LCP dan FID. Salah satu cara untuk melakukannya adalah melalui pemisahan kode. Selain halaman beranda Mail.ru, tim kami mengembangkan widget untuk navigasi portal. Saat ini, fitur ini disematkan di banyak project perusahaan kami.
Karena alasan historis, widget disisipkan di bagian paling awal halaman sebagai skrip pemuatan secara sinkron. Pangsa polyfill dalam skrip ini meningkat dari waktu ke waktu. Untuk membatasi efek performa negatif dari pemuatan polyfill ini, kami mengimplementasikan pemisahan kode untuk browser modern dan lama.
Kami memutuskan tidak menggunakan pola module/nomodule untuk memuat paket JavaScript untuk browser modern atau lama, karena atribut type="module" elemen <script> tidak menargetkan browser yang cukup modern untuk kebutuhan kita. Untuk mengatasi hal ini, Mail.ru menggunakan alat internal untuk mengidentifikasi versi browser modern di backend, dan dapat menyesuaikan dengan browser tersebut.
Setelah browser dapat diidentifikasi di backend, kami menerapkan pemisahan kode untuk browser modern dan lama. Hasilnya adalah pengurangan ukuran widget JavaScript yang dimuat secara sinkron untuk browser modern sebesar 43,3%. Praktik ini juga telah diterapkan ke beberapa skrip portal lainnya.
Selain pengurangan ukuran paket dan efek positif pada Data Web Inti, pemisahan kode juga meningkatkan pengalaman developer. Hanya 3,5% pengguna kami yang menggunakan browser lama dan pembagian tersebut sedang dalam tren menurun, sehingga menerapkan pemisahan kode memungkinkan developer kami menggunakan API browser terbaru tanpa menyebabkan penggelembungan polyfill yang diperlukan untuk browser lama kepada semua pengguna.
Hasil
Setelah upaya pengoptimalan, kami mengamati nilai rata-rata untuk pekan yang dimulai dari 24-30 Mei 2021 di data lapangan kami:
| Nama grup metrik | Data Web Inti | Data Web Lainnya | |||||
|---|---|---|---|---|---|---|---|
| Nama metrik | LCP | FID | CLS | FCP | TBT | TTI | |
| Pangsa pengguna sesuai dengan nilai minimum Data Web Inti | bagus | 58% (+6%) | 93% (+1%) | 93% (+60%) | 43% (+8%) | 49% (+7%) | 51% (+8%) |
| peningkatan kebutuhan | 18% | 4% | 3% | 34% | 17% | 24% | |
| buruk | 24% | 3% | 4% | 23% | 34% | 25% | |
Grafik di bawah menunjukkan perubahan nilai metrik performa halaman web menurut "Platform". Perhatikan dua tanggal penting pada grafik:
- 23 Maret 2021: rilis iterasi dengan bagian halaman terakhir yang dimigrasikan ke Svelte;
- 19 April 2021: rilis iterasi dengan SSR yang ditampilkan dan tata letak yang dimodifikasi untuk memperbaiki regresi CLS.
Penurunan nilai dari 1 Mei hingga 10 Mei karena hari libur bulan Mei di Rusia.
Hasil yang diperoleh menggunakan "Platform" sejalan dengan pertumbuhan nilai metrik dalam Laporan UX Chrome (CrUX).
Perbandingan rata-rata nilai durasi sesi pengguna satu minggu sebelum peluncuran peningkatan awal dan satu minggu setelah peluncuran menunjukkan pertumbuhan sebesar 2,7%. Selain itu, secara keseluruhan ada peningkatan konversi yang signifikan di sebagian besar bagian halaman. Secara khusus, konversi ke aplikasi email Mail.ru meningkat sebesar 11,6%, dan konversi bagian berita meningkat 13,5%.
181%
Peningkatan pangsa batas CLS yang baik
2,7%
Durasi sesi rata-rata yang lebih tinggi
13,5%
Peningkatan rasio konversi rubrik berita
Hasil paling tidak terduga yang kami dapatkan adalah peningkatan Rasio Klik-Tayang (CTR) sebesar 17,4% dari banner pemasaran (waktu renderingnya berkurang secara signifikan dengan diperkenalkannya tag SSR dan pramuat).
Setelah menganalisis bagian lainnya di halaman, kami melihat peningkatan performa yang signifikan pada sebagian besar halaman tersebut. Bahkan untuk bagian seperti Cuaca dan Virus Corona—yang tidak penting di halaman kami—kami melihat peningkatan konversi masing-masing sebesar 9,6% dan 9,5%.
Kesimpulan
Meningkatkan kinerja adalah hal yang menantang karena pekerjaan yang terlibat dapat berlangsung lama. Anda harus memantau perubahan metrik dari waktu ke waktu secara rutin dan memastikan bahwa semua fitur produk baru tidak menyebabkan regresi dalam Data Web Inti. Untuk mencapainya, kami memantau perubahan pada Data Web Inti dalam anggaran performa.
Yang terpenting, kami menekankan pentingnya Data Web Inti bagi semua anggota tim produk, mulai dari manajer dan desainer hingga penguji dan QA. Setiap anggota tim harus mengetahui metrik kinerja dan diberdayakan untuk meningkatkannya. Kami juga menerapkan tujuan pengoptimalan performa ke dalam proses bisnis kami secara rutin. Keberhasilan memberikan pengalaman pengguna berkualitas tinggi hanya dapat diwujudkan melalui upaya bersama oleh semua anggota tim.