Studi kasus tentang beberapa perubahan besar yang diperkenalkan di Wix untuk meningkatkan performa pemuatan situs bagi jutaan situs, sehingga membuka jalan bagi mereka untuk menerima skor PageSpeed Insights dan Core Web Vitals yang baik.
Berkat memanfaatkan standar industri, penyedia cloud, dan kemampuan CDN, dikombinasikan dengan penulisan ulang besar-besaran runtime situs kami, persentase situs Wix yang mencapai skor persentil ke-75 yang baik di semua metrik Core Web Vitals lebih dari tiga kali lipat dari tahun ke tahun, menurut data dari CrUX dan HTTPArchive.
Wix mengadopsi budaya yang berorientasi pada performa, dan peningkatan lebih lanjut akan terus diluncurkan kepada pengguna. Seiring dengan fokus kami pada KPI performa, kami berharap akan melihat peningkatan jumlah situs yang lulus batas Data Web Inti.
Ringkasan
Dunia performa sangat kompleks, dengan banyak variabel dan kerumitan. Riset menunjukkan bahwa kecepatan situs memiliki dampak langsung pada rasio konversi dan pendapatan untuk bisnis. Dalam beberapa tahun terakhir, industri ini lebih menekankan pada visibilitas performa dan membuat web lebih cepat. Mulai Mei 2021, sinyal pengalaman halaman akan disertakan dalam penentuan peringkat Google Penelusuran.
Tantangan unik di Wix adalah mendukung jutaan situs, beberapa di antaranya dibuat bertahun-tahun yang lalu dan belum pernah diupdate sejak saat itu. Kami memiliki berbagai alat dan artikel untuk membantu pengguna kami mengetahui tindakan yang dapat mereka lakukan untuk menganalisis dan meningkatkan performa situs mereka.
Wix adalah lingkungan terkelola dan tidak semuanya berada di tangan pengguna. Berbagi infrastruktur umum menghadirkan banyak tantangan bagi semua situs ini, tetapi juga membuka peluang untuk peningkatan besar secara menyeluruh, yaitu memanfaatkan ekonomi skala.
Berbicara dalam bahasa yang sama
Salah satu kesulitan inti terkait performa adalah menemukan terminologi umum untuk mendiskusikan berbagai aspek pengalaman pengguna, sekaligus mempertimbangkan performa teknis dan yang dirasakan. Dengan menggunakan bahasa umum yang telah ditentukan dengan baik dalam organisasi, kami dapat dengan mudah mendiskusikan dan mengategorikan berbagai bagian teknis dan kompromi, memperjelas laporan performa kami, dan sangat membantu untuk memahami aspek apa yang harus kami fokuskan untuk ditingkatkan terlebih dahulu.
Kami menyesuaikan semua pemantauan dan diskusi internal untuk menyertakan metrik standar industri seperti Data Web, yang mencakup:
Skor kompleksitas dan performa situs
Membuat situs yang dimuat secara instan cukup mudah selama Anda membuatnya sangat sederhana hanya menggunakan HTML dan menayangkannya melalui CDN.
Namun, kenyataannya situs menjadi semakin kompleks dan canggih, beroperasi lebih seperti aplikasi, bukan dokumen, dan mendukung fungsi seperti blog, solusi e-commerce, kode kustom, dll.
Wix menawarkan berbagai template yang sangat banyak, sehingga penggunanya dapat membuat situs dengan banyak kemampuan bisnis dengan mudah. Fitur tambahan tersebut sering kali disertai dengan beberapa biaya performa.
Perjalanan
Awalnya, ada HTML
Setiap kali dimuat, halaman selalu dimulai dengan permintaan awal ke URL untuk mengambil dokumen HTML. Respons HTML ini memicu semua permintaan klien tambahan dan logika browser untuk menjalankan dan merender situs Anda. Ini adalah bagian terpenting dari pemuatan halaman, karena tidak ada yang terjadi hingga awal respons tiba (dikenal sebagai TTFB - time to first byte).
Dulu: rendering sisi klien (CSR)
Saat mengoperasikan sistem skala besar, Anda selalu memiliki kompromi yang perlu dipertimbangkan, seperti performa, keandalan, dan biaya. Hingga beberapa tahun yang lalu, Wix menggunakan rendering sisi klien (CSR), yang konten HTML-nya sebenarnya dihasilkan melalui JavaScript di sisi klien (yaitu di browser) sehingga kami dapat mendukung situs berskala tinggi tanpa memiliki biaya operasional backend yang besar.
CSR memungkinkan kami menggunakan dokumen HTML umum, yang pada dasarnya kosong. Yang dilakukannya hanya memicu download kode dan data yang diperlukan, yang kemudian digunakan untuk membuat HTML lengkap di perangkat klien.
Hari ini: rendering sisi server (SSR)
Beberapa tahun yang lalu, kami beralih ke rendering sisi server (SSR), karena hal tersebut bermanfaat bagi SEO dan performa, meningkatkan waktu visibilitas halaman awal dan memastikan pengindeksan yang lebih baik untuk mesin telusur yang tidak memiliki dukungan penuh untuk menjalankan JavaScript.
Pendekatan ini meningkatkan pengalaman visibilitas, terutama pada perangkat/koneksi yang lebih lambat, dan membuka peluang untuk pengoptimalan performa lebih lanjut. Namun, hal ini juga berarti bahwa untuk setiap permintaan halaman web, respons HTML unik dibuat dengan cepat, yang jauh dari optimal, terutama untuk situs dengan jumlah penayangan yang besar.
Memperkenalkan penyimpanan dalam cache di beberapa lokasi
HTML untuk setiap situs sebagian besar bersifat statis, tetapi memiliki beberapa pengecualian:
- Data ini sering berubah. Setiap kali pengguna mengedit situsnya, atau membuat perubahan pada data situs, seperti pada inventaris toko situs.
- Cookie dan data tertentu di dalamnya bersifat khusus pengunjung, yang berarti dua orang yang mengunjungi situs yang sama akan melihat HTML yang agak berbeda. Misalnya, untuk mendukung fitur produk seperti mengingat item yang dimasukkan pengunjung ke keranjang, atau chat yang dimulai pengunjung dengan bisnis sebelumnya, dan lainnya.
- Tidak semua halaman dapat di-cache. Misalnya, halaman dengan kode pengguna kustom, yang menampilkan waktu saat ini sebagai bagian dari dokumen, tidak memenuhi syarat untuk penyimpanan dalam cache.
Awalnya, kami menggunakan pendekatan yang relatif aman untuk meng-cache HTML tanpa data pengunjung, lalu hanya mengubah bagian respons HTML tertentu secara langsung untuk setiap pengunjung, untuk setiap hit cache.
Solusi CDN internal
Kami melakukannya dengan men-deploy solusi internal: Menggunakan Cache HTTP Varnish untuk proxy dan cache, Kafka untuk pesan pembatalan validasi, dan layanan berbasis Scala/Netty yang melakukan proxy respons HTML ini, tetapi memutasi HTML dan menambahkan data dan cookie khusus pengunjung ke respons yang di-cache.
Solusi ini memungkinkan kami men-deploy komponen ramping ini di lebih banyak lokasi geografis dan beberapa region penyedia cloud, yang tersebar di seluruh dunia. Pada tahun 2019, kami memperkenalkan lebih dari 15 wilayah baru, dan secara bertahap mengaktifkan penyimpanan dalam cache untuk lebih dari 90% kunjungan halaman kami yang memenuhi syarat untuk penyimpanan dalam cache. Menayangkan situs dari lokasi tambahan mengurangi latensi jaringan antara klien dan server yang menayangkan respons HTML, dengan mendekatkan konten ke pengunjung situs.
Kami juga mulai meng-cache respons API hanya baca tertentu dengan menggunakan solusi yang sama dan membatalkan validasi cache pada setiap perubahan pada konten situs. Misalnya, daftar postingan blog di situs di-cache dan tidak valid saat postingan dipublikasikan/diubah.
Mengurangi kompleksitas
Penerapan caching meningkatkan performa secara substansial, terutama pada fase TTFB dan FCP, serta meningkatkan keandalan kami dengan menayangkan konten dari lokasi yang lebih dekat dengan pengguna akhir.
Namun, kebutuhan untuk mengubah HTML untuk setiap respons menyebabkan kompleksitas yang tidak perlu, yang jika dihapus, akan memberikan peluang untuk peningkatan performa lebih lanjut.
Cache browser (dan persiapan untuk CDN)
~ 13%
Permintaan HTML ditayangkan langsung dari cache browser, menghemat banyak bandwidth dan mengurangi waktu pemuatan untuk penayangan berulang
Langkah berikutnya adalah benar-benar menghapus data khusus pengunjung ini dari HTML sepenuhnya, dan mengambilnya dari endpoint terpisah, yang dipanggil oleh klien untuk tujuan ini, setelah HTML datang.
Kami dengan hati-hati memigrasikan data dan cookie ini ke endpoint baru, yang dipanggil pada setiap pemuatan halaman, tetapi menampilkan JSON ramping, yang hanya diperlukan untuk proses hidrasi, untuk mencapai interaksi halaman penuh.
Hal ini memungkinkan kami mengaktifkan penyimpanan cache browser untuk HTML, yang berarti browser sekarang menyimpan respons HTML untuk kunjungan berulang, dan hanya memanggil server untuk memvalidasi bahwa konten belum berubah. Hal ini dilakukan menggunakan ETag HTTP, yang pada dasarnya adalah ID yang ditetapkan ke versi tertentu dari resource HTML. Jika konten masih sama, respons 304 Not Modified akan dikirim oleh server kami ke klien, tanpa isi.
Selain itu, perubahan ini berarti bahwa HTML kami tidak lagi khusus pengunjung dan tidak berisi cookie. Dengan kata lain, konten tersebut pada dasarnya dapat di-cache di mana saja, sehingga membuka peluang untuk menggunakan penyedia CDN yang memiliki kehadiran geografis yang jauh lebih baik di ratusan lokasi di seluruh dunia.
DNS, SSL, dan HTTP/2
Dengan mengaktifkan cache, waktu tunggu berkurang dan bagian penting lainnya dari koneksi awal menjadi lebih substansial. Meningkatkan infrastruktur jaringan dan pemantauan memungkinkan kami meningkatkan waktu DNS, koneksi, dan SSL.
HTTP/2 diaktifkan untuk semua domain pengguna, sehingga mengurangi jumlah koneksi yang diperlukan dan overhead yang menyertai setiap koneksi baru. Perubahan ini relatif mudah di-deploy, sekaligus memanfaatkan manfaat performa dan ketangguhan yang disertakan dengan HTTP/2.
Kompresi Brotli (vs. gzip)
21 - 25%
Pengurangan ukuran transfer file median
Secara tradisional, semua file kami dikompresi menggunakan kompresi gzip, yang merupakan opsi kompresi HTML yang paling umum di web. Protokol kompresi ini awalnya diimplementasikan hampir 30 tahun yang lalu.
Kompresi Brotli yang lebih baru memperkenalkan peningkatan kompresi dengan hampir tidak ada kompromi, dan perlahan menjadi lebih populer, seperti yang dijelaskan dalam Kompresi Web di Web Almanac tahunan. API ini telah didukung oleh semua browser utama selama beberapa waktu.
Kami mengaktifkan dukungan Brotli di proxy nginx kami di edge, untuk semua klien yang mendukungnya.
Beralih menggunakan kompresi Brotli mengurangi ukuran transfer file median sebesar 21% hingga 25% sehingga mengurangi penggunaan bandwidth dan meningkatkan waktu pemuatan.
Jaringan penayangan konten (CDN)
Pemilihan CDN dinamis
Di Wix, kami selalu menggunakan CDN untuk menayangkan semua kode dan gambar JavaScript di situs pengguna.
Baru-baru ini, kami berintegrasi dengan solusi dari penyedia DNS kami, untuk secara otomatis memilih CDN berperforma terbaik sesuai dengan jaringan dan asal klien. Hal ini memungkinkan kami menayangkan file statis dari lokasi terbaik untuk setiap pengunjung, dan menghindari masalah ketersediaan di CDN tertentu.
Segera hadir… domain pengguna yang ditayangkan oleh CDN
Bagian terakhir dari teka-teki ini adalah menayangkan bagian terakhir, dan paling penting, melalui CDN: HTML dari domain pengguna.
Seperti yang dijelaskan di atas, kami membuat solusi internal sendiri untuk meng-cache dan menayangkan hasil HTML dan API khusus situs. Mempertahankan solusi ini di begitu banyak wilayah baru juga memiliki biaya operasional, dan menambahkan lokasi baru menjadi proses yang perlu kami kelola dan terus optimalkan.
Saat ini kami berintegrasi dengan berbagai penyedia CDN untuk mendukung penayangan seluruh situs Wix langsung dari lokasi CDN guna meningkatkan distribusi server kami di seluruh dunia, sehingga meningkatkan waktu respons lebih lanjut. Hal ini merupakan tantangan karena banyaknya domain yang kami layani, yang memerlukan penghentian SSL di edge.
Berintegrasi dengan CDN akan mendekatkan situs Wix kepada pelanggan dan membawa lebih banyak peningkatan pada pengalaman pemuatan, termasuk teknologi yang lebih baru seperti HTTP/3 tanpa upaya tambahan dari pihak kami.
Pengantar tentang pemantauan performa
Jika menjalankan situs Wix, Anda mungkin bertanya-tanya bagaimana hal ini memengaruhi hasil performa situs Wix Anda, dan bagaimana kami dibandingkan dengan platform situs lainnya.
Sebagian besar pekerjaan yang dilakukan di atas telah di-deploy dalam setahun terakhir, dan beberapa masih diluncurkan.
Web Almanac oleh HTTPArchive baru-baru ini memublikasikan edisi 2020 yang menyertakan bab yang bagus tentang pengalaman pengguna CMS. Perlu diingat bahwa banyak angka yang dijelaskan dalam artikel ini berasal dari pertengahan tahun 2020.
Kami menantikan laporan yang diperbarui pada tahun 2021, dan secara aktif memantau laporan CrUX untuk situs kami serta metrik performa internal kami.
Kami berkomitmen untuk terus meningkatkan waktu pemuatan dan menyediakan platform bagi pengguna kami tempat mereka dapat membuat situs seperti yang mereka bayangkan, tanpa mengorbankan performa.
DebugBear baru-baru ini merilis Ulasan Performa Pembuat Situs yang sangat menarik, yang membahas beberapa area yang saya sebutkan di atas dan memeriksa performa situs yang sangat sederhana yang dibuat di setiap platform. Situs ini dibuat hampir dua tahun lalu, dan tidak diubah sejak saat itu, tetapi platform ini terus ditingkatkan, dan performa situsnya juga meningkat, yang dapat dilihat dengan melihat datanya selama satu setengah tahun terakhir.
Kesimpulan
Kami harap pengalaman kami menginspirasi Anda untuk mengadopsi budaya berorientasi performa di organisasi Anda dan detail di atas bermanfaat serta dapat diterapkan di platform atau situs Anda.
Ringkasnya:
- Pilih serangkaian metrik yang dapat Anda lacak secara konsisten menggunakan alat yang didukung oleh industri. Sebaiknya gunakan Data Web Inti.
- Manfaatkan cache browser dan CDN.
- Bermigrasi ke HTTP/2 (atau HTTP/3 jika memungkinkan).
- Gunakan kompresi Brotli.
Terima kasih telah mempelajari kisah kami dan kami mengundang Anda untuk mengajukan pertanyaan, membagikan ide di Twitter dan GitHub, serta bergabung dalam percakapan performa web di saluran favorit Anda.