Sebuah studi kasus tentang perubahan yang diterapkan GoDaddy untuk meningkatkan performa situs bagi jutaan situs, membantu mereka mencapai skor PageSpeed Insights dan Data Web Inti yang baik.
GoDaddy adalah platform layanan terbesar di dunia untuk pewirausaha di seluruh dunia. Kami memiliki misi untuk memberdayakan komunitas kami di seluruh dunia yang terdiri dari 20 juta lebih pelanggan—dan pengusaha di mana saja—dengan memberi mereka semua bantuan dan alat yang mereka butuhkan untuk berkembang secara online.
Pada tahun 2019, GoDaddy meluncurkan Situs + Pemasaran dengan komitmen untuk memberikan alat dan layanan yang mudah digunakan dan membantu pemilik bisnis mencapai tujuan mereka. Situs + Pemasaran mengintegrasikan pembuatan situs dengan alat pemasaran dan e-commerce, serta memasangkannya dengan panduan terbaik di kelasnya untuk membantu pelanggan meraih kesuksesan dengan usaha baru mereka.
Sejak peluncuran Situs + Pemasaran, performa telah menjadi bagian penting dari produk dan sesuatu yang telah dipantau dan dikerjakan secara aktif. Dalam artikel ini, kita akan meninjau perjalanan GoDaddy dari menggunakan pengujian performa lab ke penggunaan data dunia nyata dengan Core Web Vitals, dan serangkaian peningkatan yang dilakukan pada produk untuk mendapatkan rasio kelulusan yang sangat tinggi untuk 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 hosting di platform kami memiliki beragam 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 untuk menarik kesimpulan tentang fitur {i>website<i} apa yang memiliki performa lebih rendah, sekaligus memberikan insight tentang apa yang perlu diperbaiki.
Misalnya, hal ini membantu kami mengidentifikasi bahwa "modal pop-up" berdampak negatif pada kecepatan halaman; situs dengan fitur ini memiliki performa 12 poin lebih rendah daripada tanpa modal. Setelah melakukan pembaruan pada kode untuk menunda pemuatan JavaScript, kami meningkatkan skor Lighthouse sebesar 2 poin. Kami dapat menerapkan pembelajaran ini pada fitur lain seperti "banner cookie" yang dirender segera setelah halaman dimuat.
Bersama dengan melihat situs bermasalah berdasarkan fitur, kami melakukan analisis paket JavaScript dan melihat bahwa sebagian besar ukurannya berasal dari dependensi eksternal (immutable.js dan draft.js). Kami mengurangi ukuran paket dengan merestrukturisasi konsumen ke dependensi pemuatan lambat sesuai permintaan. Hasilnya, ukuran paket JavaScript umum turun lebih dari 50%, yang awalnya berukuran lebih dari 200 KB menjadi sekitar 90 KB (diperkecil). Dengan ukuran paket yang lebih kecil, browser dapat memuat aset eksternal dan mengeksekusi skrip penting lebih awal dalam siklus proses pemuatan situs awal, sehingga menghasilkan Largest Contentful Paint (LCP) dan First Input Delay (FID).
Berkat upaya berkelanjutan kami, rata-rata skor Lighthouse situs pelanggan berubah 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 ketika hasilnya tidak selalu konsisten antara yang diuji di lingkungan pengujian lokal dan hasil yang kami dapatkan di lapangan. Hasil lab sangat membantu, tetapi inilah saatnya untuk fokus pada pengalaman pengguna yang nyata yang diamati di lapangan.
Melacak data pengguna sebenarnya dengan Data Web Inti
Setelah menambahkan library web-vitals ke situs pelanggan, kami dapat mengukur data di perangkat sebenarnya dari pengunjung sungguhan, dengan hardware, kecepatan jaringan, interaksi pengguna (seperti men-scroll atau mengklik) tidak pada dasar yang konsisten seperti di setelan lab yang menggunakan Lighthouse. Ini adalah langkah besar ke arah yang tepat, karena kami sekarang memiliki data yang mewakili pengalaman pengunjung situs kami.
Berfokus pada link terlemah: Pergeseran Tata Letak Kumulatif (CLS)
Menganalisis data baru memberi kita perspektif baru tentang apa yang harus dilakukan untuk meningkatkan kecepatan situs. Karena upaya yang telah dilakukan untuk meningkatkan skor Lighthouse, LCP persentil ke-75 kami adalah 860 md dan FID kami pada ambang batas yang sama di bawah 10 md, sehingga kami menikmati tingkat kelulusan yang tinggi untuk metrik ini di situs pelanggan kami: masing-masing 78% dan 98%. Namun, angka Pergeseran Tata Letak Kumulatif (CLS) terlihat sangat berbeda dari yang biasa kita gunakan di Lighthouse. CLS kami pada persentil ke-75 adalah 0,17–di atas ambang batas 0,1 untuk "lulus"–dan tingkat kelulusan kami dengan demikian hanya 47% di atas semua situs kami.
Metrik tersebut menurunkan tingkat kelulusan kami secara keseluruhan menjadi 40%, jadi kami memutuskan untuk menetapkan sasaran yang 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 "paruh atas", yang merupakan sesuatu yang ditangkap Data Web Inti dengan lebih baik. Karena variabilitas pada cara pengguna berinteraksi dengan situs saat situs pertama kali dimuat, CLS berbeda dengan data lab dan kolom.
Jalan untuk menyelesaikan semua Data Web Inti
Meningkatkan performa memerlukan proses uji coba-coba, dan setiap upaya tidak selalu berfungsi seperti yang diharapkan. Namun, berikut adalah beberapa peningkatan yang membantu kami mencapai tujuan.
Melakukan reservasi ruang untuk memuat gambar meningkatkan skor CLS secara drastis karena mencegah konten di bawah gambar bergeser. Kami menggunakan properti aspect-ratio CSS untuk mengatasi hal ini di browser yang mendukungnya. Bagi yang tidak memilikinya, kami memuat gambar placeholder transparan yang di-cache dan berukuran hanya beberapa byte, sehingga dimuat hampir secara instan.
Perilaku gambar generik ini memungkinkan kami menghitung sebelumnya tinggi gambar akhir selama rendering sisi server, berdasarkan lebar area pandang dan rasio aspek gambar. Hal ini menghasilkan markup HTML dengan ruang vertikal yang tepat untuk gambar akhir. Peningkatan ini khususnya dapat diamati di perangkat seluler, karena gambar dirender hingga seluruh 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 performa rendering sisi server. Ini adalah area yang sulit untuk ditingkatkan pergeseran tata letak karena konten (sehingga tingginya) akan bervariasi. Dalam kasus tersebut, kita menggabungkan komponen dalam penampung dengan min-height yang diterapkan, yang ditentukan sebelumnya berdasarkan pengamatan tinggi rata-rata untuk setiap komponen tertentu. min-height dihapus setelah komponen dinamis internal selesai dirender. Meskipun tidak sempurna, solusi ini memungkinkan kami banyak mengurangi pergeseran tata letak.
Sembari berfokus pada peningkatan CLS, kami terus berupaya memperbaiki LCP. Di banyak situs, gambar adalah penyebab terbesar yang berkontribusi terhadap LCP dan bagi kami hal itu merupakan area peningkatan yang jelas. 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 (seluler, tablet, desktop, desktop besar). Jadi, kami memperbarui kode pembuatan gambar untuk membatasi dan menskalakan gambar per titik henti sementara, lalu menskalakan lagi resolusi berdasarkan kepadatan piksel. Sebagai contoh, ukuran gambar besar tertentu berkurang dari 192 KB menjadi 102 KB.
Untuk merender situs dengan cepat pada perangkat yang memiliki koneksi jaringan buruk, kami menambahkan kode untuk menurunkan 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 Asset API kami berdasarkan kondisi jaringan tersebut.
Beberapa bagian 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. Membuat skrip ini menjadi 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 dieksternalkan juga dapat dibagikan di seluruh halaman. Hal ini memungkinkan peningkatan performa tambahan dalam bentuk penyimpanan cache browser dan CDN. Kami menjaga skrip penting tetap sebaris agar browser dapat mengurai dan mengeksekusinya dengan lebih cepat.
Hasil
Fokus kami pada CLS membuahkan hasil, rasio kelulusan Data Web Inti kami meningkat dari sekitar 40% menjadi hampir 70%: meningkat sebesar 75%.
Saat pengguna kembali ke platform kami untuk melakukan update dan memublikasikan ulang situs, mereka mendapatkan peningkatan performa terbaru. Oleh karena itu, jumlah situs yang berhasil "meneruskan Data Web Inti" terus berkembang seperti yang ditunjukkan pada diagram di bawah:
Kesimpulan
Menemukan area untuk peningkatan performa dan keberhasilan pelacakan progres sangat bergantung pada alat apa yang digunakan untuk pengukuran. Meskipun Lighthouse berguna untuk mengukur performa paruh atas dalam "setelan lab", Lighthouse tidak secara akurat merekam masalah performa yang hanya terjadi dari interaksi pengguna (seperti men-scroll halaman).
Melacak Data Web Inti dunia nyata dengan metadata memungkinkan kami memvisualisasikan, menargetkan, dan mengukur dampak peningkatan. Perjalanan untuk meningkatkan skor Data Web Inti memungkinkan tim mengidentifikasi dan mengganti pola yang tidak berperforma baik yang ditemukan di seluruh codebase kami. Terkadang perubahan yang menjanjikan tidak memiliki dampak yang hampir seperti yang kita harapkan, tetapi sebaliknya. Dunia ini tidak asli di luar sana, jadi Anda harus terus mencoba.