Studi kasus tentang perubahan yang diterapkan GoDaddy untuk meningkatkan performa situs bagi jutaan situs, membantu mereka mencapai skor PageSpeed Insights dan Core Web Vitals yang baik.
GoDaddy adalah platform layanan terbesar di dunia untuk pengusaha di seluruh dunia. Kami memiliki misi untuk mendukung komunitas kami yang terdiri dari lebih dari 20 juta pelanggan—dan pengusaha di mana saja—dengan memberikan semua bantuan dan alat yang mereka butuhkan untuk berkembang di platform online.
Pada tahun 2019, GoDaddy meluncurkan Websites + Marketing dengan komitmen untuk memberikan alat dan layanan yang mudah digunakan dan membantu pemilik bisnis mencapai sasaran mereka. Websites + Marketing mengintegrasikan pembuatan situs dengan alat pemasaran dan e-commerce serta menggabungkannya dengan panduan terbaik di kelasnya untuk membantu pelanggan meraih kesuksesan dengan usaha baru mereka.
Sejak peluncuran Websites + Marketing, performa telah menjadi bagian penting dari produk dan sesuatu yang telah dipantau dan dikerjakan secara aktif. Dalam artikel ini, kami akan meninjau perjalanan GoDaddy dari menggunakan pengujian performa lab ke menggunakan data dunia nyata dengan Data Web Inti, dan serangkaian peningkatan yang dilakukan pada produk untuk mendapatkan rasio kelulusan yang sangat tinggi bagi situs pelanggan kami.
Melacak performa dengan Lighthouse
Kami telah mengandalkan data Lighthouse untuk pelacakan performa. Setiap kali situs dipublikasikan di platform ini, kami mengukur performanya menggunakan alat internal kami yang bernama "Lighthouse4u", yang menyediakan Google Lighthouse sebagai layanan https://github.com/godaddy/lighthouse4u. Hal ini memberi kami indikasi yang baik tentang performa situs secara umum di setelan lab.
Karena jutaan situs yang kami host di platform kami memiliki berbagai fitur dan konten, penting untuk menggabungkan data performa dengan metadata tentang setiap situs yang diuji (seperti template yang digunakan, jenis widget yang dirender, dan sebagainya). Hal ini memungkinkan kami menarik kesimpulan tentang fitur situs mana yang memiliki performa lebih rendah, sekaligus memberikan insight tentang tempat untuk mencari peningkatan.
Misalnya, hal ini membantu kami mengidentifikasi bahwa "modal pop-up" memiliki dampak negatif pada kecepatan halaman; situs dengan fitur ini berperforma 12 poin lebih rendah daripada tanpa fitur tersebut. Setelah melakukan pembaruan pada kode untuk menunda pemuatan JavaScript, kami meningkatkan skor Lighthouse sebesar 2 poin. Kami dapat menerapkan pembelajaran ini ke fitur lain seperti "banner cookie" yang dirender segera setelah halaman dimuat.
Selain melihat situs yang bermasalah berdasarkan fitur, kami melakukan analisis terhadap paket JavaScript dan melihat bahwa sebagian besar ukurannya berasal dari dependensi eksternal (immutable.js dan draft.js). Kami mengurangi ukuran paket dengan menyusun ulang konsumen untuk memuat dependensi secara lambat sesuai permintaan. Hal ini menghasilkan penurunan ukuran paket JavaScript umum sebesar lebih dari 50%, yang berubah dari lebih dari 200 KB menjadi sekitar 90 KB (diminifikasi). Ukuran paket yang lebih kecil memungkinkan browser memuat aset eksternal dan menjalankan skrip penting lebih awal dalam siklus proses pemuatan situs awal, sehingga menghasilkan peningkatan Largest Contentful Paint (LCP) dan First Input Delay (FID).
Berkat upaya berkelanjutan kami, skor Lighthouse situs pelanggan rata-rata meningkat dari sekitar 40 poin pada November 2020 menjadi di atas 70 poin pada Mei 2021. Namun, tidak semua upaya kami berhasil dan terkadang kami terkejut saat hasilnya tidak selalu konsisten antara yang diuji di lingkungan pengujian lokal dan hasil yang kami dapatkan di lapangan. Hasil lab sangat membantu, tetapi sudah waktunya untuk berfokus pada pengalaman pengguna yang sebenarnya yang diamati di lapangan.
Melacak data pengguna yang sebenarnya dengan Core Web Vitals
Setelah menambahkan library web-vitals ke situs pelanggan, kami dapat mengukur data di perangkat sebenarnya dari pengunjung sebenarnya, dengan hardware, kecepatan jaringan, interaksi pengguna (seperti men-scroll atau mengklik) tidak berada pada dasar pengukuran yang konsisten seperti di setelan lab menggunakan Lighthouse. Ini adalah langkah besar ke arah yang benar, karena sekarang kami memiliki data yang mewakili pengalaman pengunjung situs kami.
Berfokus pada link terlemah: Pergeseran Tata Letak Kumulatif (CLS)
Menganalisis data baru memberi kami perspektif baru tentang hal yang harus dilakukan untuk meningkatkan kecepatan situs. Karena upaya yang dilakukan untuk meningkatkan skor Lighthouse, LCP persentil ke-75 kami adalah 860 md dan FID pada nilai minimum yang sama adalah di bawah 10 md, sehingga kami mendapatkan rasio kelulusan yang tinggi untuk metrik ini di situs pelanggan: masing-masing 78% dan 98%. Namun, angka Pergeseran Tata Letak Kumulatif (CLS) terlihat cukup berbeda dari yang biasa kita lihat di Lighthouse. CLS kami pada persentil ke-75 adalah 0,17–di atas nilai minimum 0,1 untuk "lulus"–sehingga rasio lulus kami hanya 47% di seluruh situs kami.
Metrik tersebut menurunkan rasio kelulusan keseluruhan kami menjadi 40%, sehingga kami memutuskan untuk menetapkan sasaran ambisius untuk menaikkan angka tersebut menjadi di atas 60% pada akhir Agustus 2021. Untuk melakukannya, kita harus berfokus pada CLS.
Dalam kehidupan nyata, pengguna berinteraksi dengan halaman dan men-scroll melewati konten "di atas lipatan", yang merupakan sesuatu yang ditangkap Data Web Inti dengan lebih baik. Karena variabilitas dalam cara pengguna berinteraksi dengan situs saat pertama kali dimuat, CLS berbeda dengan data lab dan lapangan.
Cara lulus semua Data Web Inti
Meningkatkan performa memerlukan trial and error, dan setiap upaya tidak selalu berhasil seperti yang diharapkan. Namun, berikut beberapa peningkatan yang membantu kami mencapai sasaran.
Menyisakan ruang untuk memuat gambar secara drastis meningkatkan skor CLS karena mencegah konten di bawah gambar bergeser. Kami menggunakan properti aspect-ratio CSS untuk mengatasi hal ini di browser yang mendukungnya. Untuk gambar yang tidak ada, kami memuat gambar placeholder transparan yang di-cache dan berukuran hanya beberapa byte, sehingga dimuat hampir seketika.
Perilaku gambar umum ini memungkinkan kami menghitung tinggi gambar akhir terlebih dahulu selama rendering sisi server, berdasarkan lebar area pandang dan rasio aspek gambar. Hal ini menghasilkan markup HTML dengan ruang vertikal yang dicadangkan dengan tepat untuk gambar akhir. Peningkatan ini terutama terlihat di perangkat seluler, karena gambar dirender ke rentang penuh area pandang seluler.
Komponen tertentu di situs pelanggan kami memiliki konten dinamis (misalnya, daftar ulasan pelanggan eksternal) dan tidak dapat dikonversi menjadi CSS murni untuk memanfaatkan manfaat performa rendering sisi server. Area ini sulit untuk meningkatkan pergeseran tata letak karena konten (sehingga tinggi) akan bervariasi. Dalam kasus tersebut, kita menggabungkan komponen dalam penampung dengan min-height yang diterapkan, yang telah ditentukan berdasarkan pengamatan tinggi rata-rata untuk setiap komponen tertentu. min-height dihapus setelah komponen dinamis bagian dalam selesai dirender. Meskipun tidak sempurna, solusi ini memungkinkan kami mengurangi pergeseran tata letak secara signifikan.
Sembari berfokus pada peningkatan CLS, kami terus berupaya meningkatkan LCP. Di banyak situs, gambar adalah penyebab terbesar yang berkontribusi pada LCP dan bagi kami, ini adalah area yang jelas perlu ditingkatkan. Kami telah melakukan peningkatan pada gambar pemuatan lambat menggunakan IntersectionObserver, tetapi menyadari bahwa ukuran gambar tidak ditetapkan dengan cara yang paling optimal untuk setiap titik henti sementara (perangkat seluler, tablet, desktop, desktop besar), jadi kami memperbarui kode pembuatan gambar untuk membatasi dan menskalakan gambar per titik henti sementara, lalu menskalakan kembali resolusi berdasarkan kepadatan piksel. Sebagai contoh, tindakan ini mengurangi ukuran gambar besar tertentu dari 192 KB menjadi 102 KB.
Untuk merender situs dengan cepat di perangkat dengan koneksi jaringan yang buruk, kami menambahkan kode untuk menskalakan kualitas gambar secara dinamis berdasarkan kecepatan koneksi. Hal ini dapat dilakukan menggunakan properti downlink yang ditampilkan oleh navigator.connection. Kami menerapkan parameter kueri berbasis URL untuk mengurangi kualitas gambar melalui API aset kami berdasarkan kondisi jaringan tersebut.
Sejumlah bagian di situs pelanggan kami dimuat secara dinamis. Karena kita tahu bagian mana yang akan dirender di situs tertentu saat dipublikasikan, kita menggunakan petunjuk resource rel=preconnect untuk melakukan inisialisasi koneksi dan handshake yang diperlukan sebelumnya. Kami juga menggunakan petunjuk resource untuk memuat font dan resource penting lainnya dengan cepat.
Saat membuat situs, pelanggan menambahkan berbagai bagian yang mungkin memiliki skrip inline untuk memungkinkan fungsi yang berbeda. Menempatkan skrip ini secara inline di seluruh halaman HTML tidak selalu optimal untuk performa. Kami memutuskan untuk mengeksternalkan skrip ini agar browser dapat memuat dan mengurai konten skrip secara asinkron. Skrip yang baru dieksternalisasi juga dapat dibagikan di seluruh halaman. Hal ini memungkinkan peningkatan performa tambahan dalam bentuk penyimpanan data ke dalam cache browser dan CDN. Kami mempertahankan skrip penting secara inline agar browser dapat mengurai dan mengeksekusinya lebih cepat.
Hasil
Memfokuskan upaya kami pada CLS membuahkan hasil, rasio kelulusan Core Web Vitals kami meningkat dari sekitar 40% menjadi hampir 70%: peningkatan sebesar 75%.
Saat pengguna kembali ke platform kami untuk melakukan pembaruan dan memublikasikan ulang situs mereka, mereka akan mendapatkan peningkatan performa terbaru. Akibatnya, jumlah situs yang "lulus Core Web Vitals" terus meningkat seperti yang ditunjukkan pada diagram di bawah:
Kesimpulan
Menemukan area untuk peningkatan performa dan berhasil melacak progres sangat bergantung pada alat yang digunakan untuk pengukuran. Meskipun Lighthouse berguna untuk mengukur performa paruh atas halaman dalam "setelan lab", Lighthouse tidak secara akurat menangkap masalah performa yang hanya terjadi dari interaksi pengguna (seperti men-scroll halaman).
Melacak Core Web Vitals di dunia nyata dengan metadata memungkinkan kami memvisualisasikan, menargetkan, dan mengukur dampak peningkatan kami. Perjalanan untuk meningkatkan skor Core Web Vitals memungkinkan tim mengidentifikasi dan mengganti pola yang tidak berperforma yang ditemukan di seluruh codebase kami. Terkadang perubahan yang menjanjikan tidak memberikan dampak yang kami harapkan, terkadang sebaliknya. Dunia ini tidak sempurna, jadi Anda harus terus mencoba.