Setelah beberapa bulan melakukan upaya untuk meningkatkan Core Web Vitals di halaman beranda Mail.ru, persentil ke-75 Cumulative Layout Shift (CLS) meningkat sebesar 60%, sehingga meningkatkan waktu sesi rata-rata sebesar 2,7% dan rasio konversi bagian inti sebesar lebih dari 10%.
Awal mulanya
Mail.ru adalah salah satu layanan email terkemuka di Internet berbahasa Rusia dan termasuk dalam 5 situs teratas di Rusia dalam hal traffic. Mail.ru adalah referensi penting bagi banyak orang. Google menerima ratusan juta kunjungan per bulan, dan merupakan portal tempat orang dapat mengakses email, berita, media sosial, penelusuran internet performa, dan lainnya.
Mail.ru ingin memberikan pengalaman pengguna berkualitas tinggi kepada pengunjungnya, sehingga upaya untuk meningkatkan Data Web Inti dimulai. Sebelum membahas strategi pengoptimalan, beberapa detail teknis halaman beranda Mail.ru harus diperhatikan terlebih dahulu.
Meskipun project ini telah lama dikembangkan menggunakan mesin pembuatan template internal kami, Fest, kami mulai bermigrasi ke Svelte 3 pada tahun 2019.
Svelte menerapkan reaktivitas dengan cara yang tidak menggunakan Virtual DOM, sehingga tidak terlalu banyak menggunakan 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. Hal 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.
Skrip pengumpulan metrik kami diubah untuk mengumpulkan Core Web Vitals dan mengirimkannya ke dasbor performa kami 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 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% |
| needs-improvement | 19% | 5% | 23% | 38% | 16% | 25% | |
| buruk | 29% | 3% | 44% | 27% | 42% | 32% | |
Meningkatkan Core Web Vitals
Meskipun ada banyak panduan untuk meningkatkan Core Web Vitals, setiap project memiliki tantangan yang unik. Untuk halaman beranda Mail.ru, peluang berikut telah diidentifikasi:
- 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).
Skeleton untuk peningkatan CLS
CLS adalah salah satu metrik kolom berperforma terburuk untuk halaman beranda Mail.ru. Pembuatan profil halaman ini berikutnya di panel Performa DevTools Chrome mengungkapkan bahwa iklan adalah sumber masalahnya. Untuk meningkatkan stabilitas tata letak, tim kami memutuskan untuk menggunakan placeholder guna mencadangkan ruang untuk iklan sebelum dimuat.
Saat menerapkan placeholder, langkah pertama adalah menentukan dimensi konten yang akan menggantikannya. Untungnya, halaman beranda Mail.ru versi desktop memiliki ukuran yang didokumentasikan secara ketat untuk iklan. Setelah berdiskusi dengan tim desain, kerangka UI animasi SVG digunakan sebagai placeholder karena kerangka ini mengurangi waktu pemuatan konten yang dirasakan.
Kembalinya SSR
Untuk memudahkan transisi dari Fest ke Svelte, kami menulis ulang project yang ada secara bertahap, bukan memulai dari awal. Pada Maret 2021, kami telah memigrasikan sebagian besar frontend ke Svelte, dan akhirnya menghadirkan SSR ke aplikasi produksi kami setelah melakukan triage dan memperbaiki masalah performa backend.
Setelah menerapkan SSR, tim menemukan penyebab regresi CLS yang awalnya tidak diketahui: bagian berita tidak disisipkan pada saat merender konten pertama di halaman. Ada penundaan antara proses awal pembuatan markup halaman yang disediakan oleh server dan penyisipan bagian berita di klien. Perilaku ini menyebabkan pergeseran kerangka iklan, yang memperburuk CLS.
Meskipun DevTools Chrome menampilkan peristiwa Layout Shift, kami tidak dapat menemukan alasannya pada awalnya. Meskipun SSR itu sendiri bukan masalahnya, SSR membantu menemukan solusinya nanti. Memperbaiki kode yang bertanggung jawab atas penundaan proses menggambar akan meningkatkan stabilitas tata letak komponen berita.
Efek lain yang dapat ditimbulkan SSR pada CLS adalah pergerakan komponen sebelum dan sesudah hidrasi, yang dapat menyebabkan pergeseran tata letak lebih lanjut. Kami mengalami hal ini terutama pada versi seluler dan memerlukan perhatian khusus pada markup komponen yang di-hydrate. Solusi yang baik untuk masalah ini adalah mentransfer sebanyak mungkin logika tampilan dari JavaScript ke CSS jika memungkinkan.
Pemisahan kode dan polyfill yang tidak digunakan
Untuk meningkatkan kecepatan pemuatan halaman yang dirasakan, perlu dilakukan tindakan untuk mengurangi nilai LCP dan FID. Salah satu cara untuk mencapainya adalah melalui pemisahan kode. Selain halaman beranda Mail.ru itu sendiri, tim kami sedang mengembangkan widget untuk navigasi portal. Saat ini, kode ini disematkan di banyak project perusahaan kami.
Karena alasan historis, widget disisipkan di awal halaman sebagai skrip yang dimuat secara sinkron. Pangsa polyfill dalam skrip ini meningkat dari waktu ke waktu. Untuk membatasi efek negatif pada performa saat memuat polyfill ini, kami menerapkan pemisahan kode untuk browser modern dan lama.
Kami memutuskan untuk 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 kami. Untuk mengatasi hal ini, Mail.ru menggunakan alat internal untuk mengidentifikasi versi browser modern di backend, dan dapat beradaptasi 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 sebesar 43,3% untuk browser modern. Praktik ini juga telah diterapkan ke beberapa skrip portal lainnya.
Selain pengurangan ukuran paket dan efek positif pada Core Web Vitals, pemisahan kode juga meningkatkan pengalaman developer. Hanya 3,5% pengguna kami yang menggunakan browser lama dan pangsa tersebut cenderung menurun.Dengan menerapkan pemisahan kode, developer kami dapat menggunakan API browser terbaru tanpa memperkenalkan pembesaran polyfill yang diperlukan untuk browser lama kepada semua pengguna.
Hasil
Setelah upaya pengoptimalan, kami mengamati nilai rata-rata untuk minggu 24-30 Mei 2021 dalam 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%) |
| needs-improvement | 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 diubah untuk memperbaiki regresi CLS.
Penurunan nilai dari 1 Mei hingga 10 Mei disebabkan oleh hari libur Mei di Rusia.
Hasil yang diperoleh menggunakan "Platform" sejalan dengan pertumbuhan nilai metrik di Laporan UX Chrome (CrUX).
Perbandingan nilai durasi sesi pengguna rata-rata seminggu sebelum peluncuran peningkatan awal dan seminggu setelah peluncuran menunjukkan pertumbuhan sebesar 2,7%. Selain itu, terdapat peningkatan konversi yang signifikan secara keseluruhan di sebagian besar bagian halaman. Secara khusus, konversi ke aplikasi email Mail.ru meningkat sebesar 11,6%, konversi bagian berita meningkat sebesar 13,5%.
181%
Meningkatkan pangsa nilai minimum CLS yang baik
2,7%
Durasi sesi rata-rata yang lebih tinggi
13,5%
Peningkatan rasio konversi bagian berita
Hasil yang paling tidak terduga yang kami dapatkan adalah peningkatan Rasio Klik-Tayang (CTR) banner pemasaran sebesar 17,4% (waktu renderingnya berkurang secara signifikan dengan diperkenalkannya SSR dan tag pramuat).
Setelah menganalisis bagian lainnya di halaman, kami melihat peningkatan performa yang signifikan di sebagian besar bagian 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 performa merupakan tantangan karena pekerjaan yang terlibat mungkin akan berlangsung lama. Anda harus memantau perubahan metrik secara rutin dari waktu ke waktu dan memastikan bahwa semua fitur produk baru tidak menyebabkan regresi pada Data Web Inti. Untuk mencapai hal ini, kami memantau perubahan Core Web Vitals di anggaran performa.
Yang terpenting, kami menekankan pentingnya Core Web Vitals kepada semua anggota tim produk kami, mulai dari pengelola dan desainer hingga penguji dan QA. Setiap anggota tim harus mengetahui metrik performa dan diberi kemampuan untuk meningkatkannya. Kami juga menggabungkan tujuan pengoptimalan performa ke dalam proses bisnis kami secara berkala. Keberhasilan dalam memberikan pengalaman pengguna berkualitas tinggi hanya dapat dilakukan melalui upaya bersama oleh semua anggota tim.