Studi kasus beberapa perubahan besar yang diperkenalkan di Wix guna meningkatkan performa pemuatan situs untuk jutaan situs, sehingga memungkinkan mereka menerima skor Data Web Inti dan PageSpeed Insights yang baik.
Berkat pemanfaatan standar industri, penyedia cloud, dan kemampuan CDN, yang dikombinasikan dengan penulisan ulang besar-besaran pada runtime situs kami, persentase situs Wix yang mencapai skor persentil ke-75 yang baik pada semua metrik Data Web Inti meningkat lebih dari tiga kali lipat tahun ke tahun, menurut data dari CrUX dan HTTPArchive.
Wix mengadopsi budaya yang berorientasi performa, dan peningkatan lebih lanjut akan terus diluncurkan kepada pengguna. Karena kami berfokus pada KPI performa, kami memperkirakan jumlah situs yang memenuhi nilai minimum Data Web Inti bertambah.
Ringkasan
Dunia performa yang sangat rumit, dengan banyak variabel dan seluk-beluk. Riset menunjukkan bahwa kecepatan situs memiliki dampak langsung terhadap 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 peringkat Google Penelusuran.
Tantangan unik di Wix adalah mendukung jutaan situs, yang beberapa di antaranya dibuat bertahun-tahun lalu dan belum diperbarui sejak saat itu. Kami memiliki berbagai alat dan artikel untuk membantu pengguna melakukan analisis dan peningkatan performa situs mereka.
Wix adalah lingkungan yang terkelola dan tidak semuanya ada di tangan pengguna. Berbagi infrastruktur umum menghadirkan banyak tantangan bagi semua situs ini, tetapi juga membuka peluang bagi peningkatan besar secara keseluruhan, yaitu memanfaatkan ekonomi dari skala.
Berbicara dalam bahasa yang sama
Salah satu kesulitan utama terkait performa adalah menemukan terminologi umum untuk membahas berbagai aspek pengalaman pengguna, sambil mempertimbangkan performa teknis dan performa yang dirasakan. Dengan menggunakan bahasa yang sama dan terdefinisi dengan baik dalam organisasi, kami dapat dengan mudah mendiskusikan dan mengategorikan berbagai bagian dan kompromi teknis, memperjelas laporan performa, dan sangat membantu kami memahami aspek apa yang harus kami fokuskan untuk meningkatkan kualitas terlebih dahulu.
Kami menyesuaikan semua pemantauan dan diskusi internal kami untuk menyertakan metrik standar industri seperti Data Web, yang mencakup:
Kompleksitas situs dan skor performa
Sangat mudah untuk membuat situs yang dapat dimuat secara instan asalkan Anda membuatnya sangat sederhana hanya dengan menggunakan HTML dan menayangkannya melalui CDN.
Namun, kenyataannya adalah situs menjadi semakin kompleks dan canggih, beroperasi lebih seperti aplikasi, bukan dokumen, dan fungsi pendukung seperti blog, solusi e-commerce, kode kustom, dll.
Wix menawarkan berbagai template yang sangat besar, sehingga memungkinkan penggunanya membuat situs dengan mudah dengan berbagai kemampuan bisnis. Fitur tambahan tersebut sering kali menimbulkan beberapa biaya performa.
Perjalanan
Pada awalnya, ada HTML
Setiap kali dimuat, halaman web akan 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 - waktu ke byte pertama).
Lama: rendering sisi klien (CSR)
Saat mengoperasikan sistem berskala besar, Anda selalu memiliki kompromi yang perlu dipertimbangkan, seperti performa, keandalan, dan biaya. Hingga beberapa tahun yang lalu, Wix menggunakan rendering sisi klien (CSR), dengan konten HTML sebenarnya dibuat melalui JavaScript di sisi klien (yaitu di browser) yang memungkinkan kami mendukung situs dalam skala besar tanpa memiliki biaya operasional backend yang besar.
CSR memungkinkan kami menggunakan dokumen HTML umum, yang pada dasarnya kosong. Yang dilakukan hanya memicu download kode dan data yang diperlukan yang kemudian digunakan untuk menghasilkan HTML lengkap di perangkat klien.
Hari ini: rendering sisi server (SSR)
Beberapa tahun yang lalu, kami beralih ke rendering sisi server (SSR), karena hal itu bermanfaat bagi SEO dan performa, sehingga 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 pintu 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 tampilan yang besar.
Memperkenalkan penyimpanan dalam cache di beberapa lokasi
Sebagian besar HTML untuk setiap situs bersifat statis, tetapi memiliki beberapa kekurangan:
- KPI tersebut sering berubah. Setiap kali pengguna mengedit situsnya, atau melakukan perubahan pada data situs, seperti pada inventaris toko situs.
- Situs tersebut memiliki data dan cookie tertentu yang spesifik untuk pengunjung, artinya 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 dalam keranjang, atau chat yang dimulai pengunjung dengan bisnis sebelumnya, dan lainnya.
- Tidak semua halaman dapat disimpan dalam cache. Misalnya, halaman dengan kode pengguna kustom di dalamnya, yang menampilkan waktu saat ini sebagai bagian dari dokumen, tidak memenuhi syarat untuk disimpan dalam cache.
Awalnya, kami mengambil pendekatan yang relatif aman dalam menyimpan HTML dalam cache tanpa data pengunjung, dan kemudian hanya memodifikasi bagian tertentu dari respons HTML dengan cepat untuk setiap pengunjung, untuk setiap cache ditemukan.
Solusi CDN internal
Kami melakukannya dengan menerapkan solusi internal: Menggunakan Varnish HTTP Cache untuk membuat proxy dan membuat cache, Kafka untuk pesan pembatalan validasi, dan layanan berbasis Scala/Netty yang menjadi proxy respons HTML ini, tetapi mengubah HTML serta menambahkan data dan cookie khusus pengunjung ke respons yang di-cache.
Solusi ini memungkinkan kami men-deploy komponen yang 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 yang memenuhi syarat untuk disimpan dalam cache. Menayangkan situs dari lokasi tambahan mengurangi latensi jaringan antara klien dan server yang menyalurkan respons HTML, dengan mendekatkan konten kepada pengunjung situs.
Kami juga mulai meng-cache respons API hanya baca tertentu dengan menggunakan solusi yang sama dan membatalkan cache pada setiap perubahan pada konten situs. Misalnya, daftar postingan blog di situs akan di-cache dan menjadi tidak valid saat postingan dipublikasikan/diubah.
Mengurangi kerumitan
Menerapkan penyimpanan cache meningkatkan performa secara substansial, terutama pada fase TTFB dan FCP, serta meningkatkan keandalan kami dengan menyajikan konten dari lokasi yang lebih dekat ke pengguna akhir.
Namun, kebutuhan untuk memodifikasi HTML untuk setiap respons menyebabkan kompleksitas yang tidak perlu, yang jika dihapus, akan memunculkan peluang untuk peningkatan performa lebih lanjut.
Penyimpanan cache browser (dan persiapan untuk CDN)
~ 13%
Permintaan HTML disalurkan langsung dari cache browser, sehingga menghemat banyak bandwidth dan mengurangi waktu pemuatan untuk tampilan berulang
Langkah berikutnya adalah menghapus data khusus pengunjung ini sepenuhnya dari HTML, dan mengambilnya dari endpoint terpisah, yang dipanggil oleh klien untuk tujuan ini, setelah HTML masuk.
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 interaktivitas halaman penuh.
Hal ini memungkinkan kami mengaktifkan penyimpanan HTML dalam cache browser, yang berarti bahwa browser kini menyimpan respons HTML untuk kunjungan berulang, dan hanya memanggil server untuk memvalidasi bahwa konten tidak berubah. Hal ini dilakukan menggunakan ETag HTTP, yang pada dasarnya adalah ID yang ditetapkan ke versi resource HTML tertentu. Jika kontennya 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, repositori dapat di-cache di mana saja, sehingga membuka pintu untuk menggunakan penyedia CDN yang memiliki kehadiran geografis yang jauh lebih baik di ratusan lokasi di seluruh dunia.
DNS, SSL, dan HTTP/2
Jika cache diaktifkan, waktu tunggu berkurang dan bagian penting lainnya dari koneksi awal menjadi lebih substansial. Meningkatkan infrastruktur dan pemantauan jaringan memungkinkan kami meningkatkan waktu DNS, koneksi, dan SSL.
HTTP/2 diaktifkan untuk semua domain pengguna, sehingga mengurangi jumlah koneksi yang diperlukan dan overhead yang disertakan dengan setiap koneksi baru. Perubahan ini relatif mudah untuk di-deploy, sekaligus memanfaatkan manfaat performa dan ketahanan yang disertakan pada HTTP/2.
Kompresi Brotli (vs. gzip)
21 - 25%
Pengurangan ukuran transfer file median
Secara tradisional, semua file dikompresi menggunakan kompresi gzip, yang merupakan opsi kompresi HTML yang paling umum di web. Protokol kompresi ini awalnya diterapkan hampir 30 tahun yang lalu.
Kompresi Brotli yang lebih baru memperkenalkan peningkatan kompresi tanpa kompromi yang nyaris tanpa kompromi, dan perlahan-lahan menjadi lebih populer, seperti yang dijelaskan dalam Bab kompresi Web Almanac tahunan. API ini telah didukung oleh semua browser utama untuk sementara waktu.
Kami mengaktifkan dukungan Brotli pada proxy nginx di edge, untuk semua klien yang mendukungnya.
Beralih ke penggunaan kompresi Brotli mengurangi ukuran transfer file median kami sebesar 21% menjadi 25%, yang menghasilkan pengurangan penggunaan bandwidth dan waktu pemuatan yang lebih baik.
Jaringan penayangan konten (CDN)
Pilihan 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 penyedia DNS kami, untuk secara otomatis memilih CDN berperforma terbaik sesuai dengan jaringan dan asal klien. Dengan begitu, kami dapat menyalurkan file statis dari lokasi terbaik untuk setiap pengunjung, dan menghindari masalah ketersediaan di CDN tertentu.
Segera hadir... domain pengguna yang dilayani oleh CDN
Bagian terakhir dari teka-teki ini adalah menampilkan bagian terakhir dan yang paling penting, melalui CDN: HTML dari domain pengguna.
Seperti yang dijelaskan di atas, kami membuat solusi internal kami sendiri untuk meng-cache dan menayangkan hasil HTML dan API khusus situs. Mempertahankan solusi ini di begitu banyak region baru juga memerlukan biaya operasional, dan menambahkan lokasi baru menjadi proses yang perlu kami kelola dan optimalkan.
Saat ini, kami berintegrasi dengan berbagai penyedia CDN untuk mendukung penayangan seluruh situs Wix langsung dari lokasi CDN untuk meningkatkan distribusi server kami di seluruh dunia, sehingga lebih meningkatkan waktu respons. Hal ini merupakan tantangan karena banyaknya domain yang kami layani, yang memerlukan penghentian SSL di edge.
Integrasi dengan CDN membuat situs Wix semakin dekat dengan pelanggan dan memberikan peningkatan yang lebih besar pada pengalaman pemuatan, termasuk teknologi yang lebih baru seperti HTTP/3 tanpa upaya tambahan dari pihak kami.
Penjelasan singkat tentang pemantauan performa
Jika Anda menjalankan situs Wix, Anda mungkin bertanya-tanya bagaimana hal ini memengaruhi hasil performa situs Wix Anda, dan bagaimana perbandingan kami dengan platform situs lain.
Sebagian besar pekerjaan yang dilakukan di atas telah di-deploy dalam setahun terakhir, dan beberapa masih sedang diluncurkan.
Web Almanac dari HTTPArchive baru-baru ini memublikasikan edisi 2020 yang mencakup bab yang sangat baik tentang pengalaman pengguna CMS. Perlu diingat bahwa sebagian besar 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 memberi pengguna platform yang dapat mereka gunakan untuk membuat situs seperti yang mereka bayangkan, tanpa mengorbankan performa.
DebugBear baru-baru ini merilis Tinjauan Performa Pembuat Situs yang sangat menarik, yang membahas beberapa area yang saya sebutkan di atas dan memeriksa performa situs yang sangat sederhana yang dibangun di setiap platform. Situs ini dibuat hampir dua tahun lalu, dan tidak pernah dimodifikasi sejak saat itu, tetapi platform ini terus meningkat, dan performa situs bersamanya, yang dapat disaksikan dengan melihat datanya selama satu setengah tahun terakhir.
Kesimpulan
Kami harap pengalaman kami dapat menginspirasi Anda untuk menerapkan budaya berorientasi performa di organisasi Anda dan bahwa informasi di atas bermanfaat dan berlaku untuk platform atau situs Anda.
Ringkasnya:
- Pilih kumpulan metrik yang dapat Anda lacak secara konsisten menggunakan alat yang didukung oleh industri. Kami merekomendasikan 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. Kami mengundang Anda untuk mengajukan pertanyaan, berbagi ide di Twitter dan GitHub, serta bergabung dalam percakapan performa web di channel favorit Anda.