Bagaimana situs Framer menjadi interaktif?

Secara dasar, situs web terdiri dari HTML dan untuk memungkinkan interaksi seperti klik tombol atau input teks, Anda memerlukan JavaScript. Untuk pemuatan awal yang cepat, Framer terlebih dahulu menyajikan HTML menggunakan rendering sisi server. Dengan cara ini, pengguna dan mesin pencari dapat segera melihat halaman tersebut.

Di saat yang sama, JavaScript yang diperlukan untuk proses juga dimuat, yang disebut dengan hidrasi (hydration). React menerima HTML dan menambahkan event listener, sehingga situs dapat merespons tindakan seperti klik atau scroll. Pada titik ini, situs menjadi 'interaktif'.

Beberapa elemen berbasis JavaScript membutuhkan data dari server untuk menjadi interaktif. Misalnya, di halaman utama Framer, data status login pengguna diambil dari server, ditandai dengan area berwarna merah.

Situs lain mungkin membutuhkan ulasan, artikel blog terbaru, atau cuaca. Mengambil semua data ini membutuhkan waktu, dan bisa berkelanjutan ketika satu permintaan data menggiring ke permintaan lainnya. Semua ini ditangani selama proses hidrasi.

Sekarang, kami akan menunjukkan hal teknis lebih lanjut untuk memperlihatkan apa yang sebenarnya terjadi. Jika Anda ingin melewati detail teknis, silakan langsung menuju bagian akhir.

React: Hubungan antara Suspense dan Hidrasi

Selama hidrasi, untuk memuat data, kita menggunakan fitur Suspense milik React. Suspense memberi tahu React bahwa “komponen ini sedang menunggu sesuatu”.

Sebelumnya, kita hanya menggunakan satu Suspense instance, seperti contoh sederhana berikut ini.

<App>
  <Suspense>
    <Page>
      <Header />
      <DataFetching content="blog" /> {/* ⬅️ Suspense 발생 */}
      <DataFetching content="footer" /> {/* ⬅️ Suspense 발생 */}
    </Page>
  </Suspense>
</App>

Artinya, setiap kali data ‘blog’ dan ‘footer’ dimuat, sebuah tag Suspense tunggal “Suspense boundary” diaktifkan. (Ini disebut ‘suspending’.) React memulai permintaan data kedua komponen ini secara paralel, tetapi masalah terjadi pada detail operasi.

Jika sebuah komponen suspend selama hidrasi untuk mendapatkan data dan lalu mendapatkan data, React akan memulai kembali hidrasi dari batas Suspense tempat komponen itu ditahan.

Artinya, pada contoh di atas, setiap kali data diminta, React memulai kembali rendering dari tag Suspense tunggal di bawah <App>. Misalnya, ketika data ‘blog’ diminta, React juga merender kembali <Header> dan dua <DataFetching> komponen anaknya. Hal yang sama terjadi saat data ‘footer’ diminta.

Artinya, bagian yang seharusnya hanya dirender sekali menjadi dirender berulang kali. Jika kita asumsi setiap pengumpul data memiliki komponen anak, maka terjadi total 12 kali render: <Page> dan <Header> dirender 3 kali, pengumpul data blog beserta anaknya 2 kali, dan pengumpul data footer serta anaknya 1 kali (= 6 + 4 + 2).

Hidrasi Lebih Cepat: Suspense yang Lebih Terperinci

Contoh di atas cepat untuk kasus kecil, tetapi jika diterapkan pada situs web dengan komponen ratusan hingga ribuan, performanya akan lambat. Kecepatan rendering juga bergantung pada perangkat (terutama CPU). Kecepatan perangkat pengguna bisa berbeda-beda, jadi memberikan pengalaman cepat yang konsisten bagi semua pengguna adalah kunci.

Pada awalnya, kami mencoba mengatasi ini dengan memoization ( React.memo), berpikir bahwa React tidak akan merender ulang komponen tersebut. Sayangnya, React tetap menjadwalkan rendering untuk komponen anak dari batas Suspense, jadi ini tidak efektif.

Untuk mengatasi masalah ini, diperlukan menambahkan batas Suspense yang lebih terperinci di sekitar komponen pemuatan data.

<App>
  <Suspense>
    <Page>
      <Header />
      <Suspense><DataFetching content="blog" /></Suspense> {/* 🎉 독립된 바운더리 */}
      <Suspense><DataFetching content="footer" /></Suspense> {/* 🎉 독립된 바운더리 */}
    </Page>
  </Suspense>
</App>

Sekarang, setiap batas Suspense dapat menangkap titik di mana komponen berhenti di dalam struktur tree-nya. React melanjutkan hidrasi tepat dari titik penangkapan komponen yang berhenti, tanpa perlu mengulangi seluruh proses render. Framer memperluas batas dari 1 menjadi 151 batas terperinci di halamannya.

Dengan cara ini, semua komponen hanya dirender sekali saat hidrasi, menjadikan proses hidrasi O(n) atau secepat linear bergantung pada jumlah node tree komponen (n). Proses ini cepat dan linear, tak peduli berapa banyak pengumpul data di dalam tree tersebut.

Arti bagi Situs Framer

Uji beta menunjukkan bahwa hidrasi menjadi 50-80% lebih cepat pada banyak perangkat, dan pada perangkat lambat, kecepatannya bisa meningkat hingga 200% lebih cepat, bergantung pada jumlah data yang diperlukan selama hidrasi. Hal ini mempercepat animasi scroll dan menjadikan titik interaksi antarmuka lebih cepat tersedia bagi pengguna.

(Kiri: Sebelumnya, Kanan: Sesudah, direkam pada M2 Pro dengan throttling CPU 6x dan jaringan 4G di Chrome terbaru.)

Kesimpulannya, animasi scroll kini berfungsi lebih cepat dan pengguna dapat berinteraksi dengan situs Framer lebih awal. Ada juga peningkatan pada halaman dengan banyak file SVG. Menginisiasi prosedur hidrasi bersamaan dengan pemuatan SVG. Berdasarkan hasil pengukuran di semua situs Framer yang dikunjungi melalui perangkat seluler, elemen seperti banner cookies muncul rata-rata 42% lebih cepat.

Bahkan, perubahan ini terasa pada perangkat cepat. Diuji pada Macbook Pro M2 Pro dengan jaringan 100Mbit/s, waktu penyelesaian hidrasi terlihat jauh lebih singkat.

(Kiri: Sebelum, Kanan: Setelah, direkam pada M2 Pro Mac dengan profil Chrome terbaru dan koneksi internet 100Mbit/s.)

Jika Anda pengguna Framer, perubahan ini akan diterapkan secara otomatis tanpa perlu tindakan tambahan. Dengan mempublikasikan ulang situs Anda, perubahan performa ini dapat langsung dirasakan. Kami berterima kasih kepada engineer performa Ivan Akulov yang telah mengidentifikasi dan memecahkan masalah ini.

Jika ada pertanyaan atau kekhawatiran terkait performa, silakan hubungi tim performa di forum komunitas.

Artikel ini diadaptasi dan diterjemahkan dari “Sites now become interactive 50% faster” dari blog resmi Framer.