Kinerja Front-End 2021: Mendefinisikan Lingkungan

Panduan ini telah didukung dengan baik oleh teman-teman kami di LogRocket, layanan yang menggabungkan pemantauan kinerja frontend , pemutaran ulang sesi, dan analisis produk untuk membantu Anda membangun pengalaman pelanggan yang lebih baik. LogRocket melacak metrik utama, termasuk. DOM selesai, waktu untuk byte pertama, penundaan input pertama, CPU klien dan penggunaan memori. Dapatkan uji coba gratis LogRocket hari ini.

Daftar isi

1. Persiapan: Perencanaan Dan Metrik
2. Menetapkan Tujuan yang Realistis
3. Mendefinisikan Lingkungan
4. Pengoptimalan Aset
5. Membangun Optimasi
6. Pengoptimalan Pengiriman
7. Jaringan, HTTP/2, HTTP/3
8. Pengujian Dan Pemantauan
9. Kemenangan Cepat
10. Semuanya dalam satu halaman
11. Unduh Daftar Periksa (PDF, Halaman Apple, MS Word)
12. Berlangganan buletin email kami agar tidak ketinggalan panduan berikutnya.

Mendefinisikan Lingkungan

1. Pilih dan siapkan alat build Anda.
   Jangan terlalu memperhatikan apa yang dianggap keren akhir-akhir ini. Tetap berpegang pada lingkungan Anda untuk membangun, baik itu Grunt, Gulp, Webpack, Parcel, atau kombinasi alat. Selama Anda mendapatkan hasil yang Anda butuhkan dan Anda tidak memiliki masalah dalam mempertahankan proses pembangunan Anda, Anda baik-baik saja.

   Di antara alat build, Rollup terus mendapatkan daya tarik, begitu pula Snowpack, tetapi Webpack tampaknya menjadi yang paling mapan, dengan ratusan plugin tersedia untuk mengoptimalkan ukuran build Anda. Hati-hati dengan Peta Jalan Webpack 2021.

   Salah satu strategi paling menonjol yang muncul baru-baru ini adalah Granular chunking dengan Webpack di Next.js dan Gatsby untuk meminimalkan kode duplikat. Secara default, modul yang tidak dibagikan di setiap titik masuk dapat diminta untuk rute yang tidak menggunakannya. Ini akhirnya menjadi overhead karena lebih banyak kode yang diunduh daripada yang diperlukan. Dengan chunking granular di Next.js, kita dapat menggunakan file manifes build sisi server untuk menentukan chunk keluaran mana yang digunakan oleh titik masuk yang berbeda.

   

   Dengan SplitChunksPlugin, beberapa potongan terpisah dibuat tergantung pada sejumlah kondisi untuk mencegah pengambilan kode duplikat di beberapa rute. Ini meningkatkan waktu buka halaman dan caching selama navigasi. Dikirim di Next.js 9.2 dan di Gatsby v2.20.7.

   Memulai dengan Webpack bisa jadi sulit. Jadi jika Anda ingin mendalami Webpack, ada beberapa sumber yang bagus di luar sana:

   • Dokumentasi Webpack — tentu saja — adalah titik awal yang baik, dan begitu pula Webpack — The Confusing Bits oleh Raja Rao dan An Annotated Webpack Config oleh Andrew Welch.
   • Sean Larkin memiliki kursus gratis di Webpack: The Core Concepts dan Jeffrey Way telah merilis kursus gratis yang fantastis di Webpack untuk semua orang. Keduanya adalah pengantar yang bagus untuk menyelam ke dalam Webpack.
   • Webpack Fundamentals adalah kursus 4 jam yang sangat komprehensif dengan Sean Larkin, dirilis oleh FrontendMasters.
   • Contoh Webpack memiliki ratusan konfigurasi Webpack siap pakai, dikategorikan berdasarkan topik dan tujuan. Bonus: ada juga konfigurator konfigurasi Webpack yang menghasilkan file konfigurasi dasar.
   • awesome-webpack adalah daftar kurasi dari sumber daya Webpack, perpustakaan, dan alat yang berguna, termasuk artikel, video, kursus, buku, dan contoh untuk proyek Angular, React, dan framework-agnostic.
   • Perjalanan menuju pembuatan aset produksi cepat dengan Webpack adalah studi kasus Etsy tentang bagaimana tim beralih dari menggunakan sistem pembangunan JavaScript berbasis RequireJS ke menggunakan Webpack dan bagaimana mereka mengoptimalkan pembangunan mereka, mengelola lebih dari 13.200 aset dalam rata-rata 4 menit .
   • Kiat kinerja Webpack adalah utas tambang emas oleh Ivan Akulov, yang menampilkan banyak kiat yang berfokus pada kinerja, termasuk yang secara khusus berfokus pada Webpack.
   • awesome-webpack-perf adalah repo GitHub tambang emas dengan alat dan plugin Webpack yang berguna untuk kinerja. Juga dikelola oleh Ivan Akulov.

1. Gunakan peningkatan progresif sebagai default.
   Namun, setelah bertahun-tahun, menjaga peningkatan progresif sebagai prinsip panduan arsitektur dan penerapan front-end Anda adalah taruhan yang aman. Rancang dan bangun pengalaman inti terlebih dahulu, lalu tingkatkan pengalaman dengan fitur-fitur canggih untuk browser yang mumpuni, menciptakan pengalaman yang tangguh. Jika situs web Anda berjalan cepat di mesin yang lambat dengan layar yang buruk di browser yang buruk di jaringan yang kurang optimal, maka itu hanya akan berjalan lebih cepat di mesin yang cepat dengan browser yang bagus di jaringan yang layak.

   Faktanya, dengan penyajian modul adaptif, kami tampaknya membawa peningkatan progresif ke tingkat lain, menyajikan pengalaman inti "ringan" ke perangkat kelas bawah, dan meningkatkan dengan fitur yang lebih canggih untuk perangkat kelas atas. Peningkatan progresif sepertinya tidak akan hilang dalam waktu dekat.

2. Pilih dasar kinerja yang kuat.
   Dengan begitu banyak hal yang tidak diketahui yang memengaruhi pemuatan — jaringan, pembatasan termal, pengusiran cache, skrip pihak ketiga, pola pemblokiran parser, I/O disk, latensi IPC, ekstensi yang diinstal, perangkat lunak antivirus dan firewall, tugas CPU latar belakang, kendala perangkat keras dan memori, perbedaan dalam L2/L3 caching, RTTS — JavaScript memiliki biaya pengalaman terberat, di samping font web memblokir rendering secara default dan gambar sering menghabiskan terlalu banyak memori. Dengan kemacetan kinerja yang berpindah dari server ke klien, sebagai pengembang, kami harus mempertimbangkan semua hal yang tidak diketahui ini dengan lebih detail.

   Dengan anggaran 170KB yang sudah berisi jalur kritis HTML/CSS/JavaScript, router, manajemen status, utilitas, kerangka kerja, dan logika aplikasi, kami harus memeriksa secara menyeluruh biaya transfer jaringan, waktu parse/kompilasi, dan biaya runtime. dari kerangka pilihan kita. Untungnya, kami telah melihat peningkatan besar selama beberapa tahun terakhir dalam seberapa cepat browser dapat mengurai dan mengkompilasi skrip. Namun eksekusi JavaScript masih menjadi hambatan utama, jadi memperhatikan waktu eksekusi skrip dan jaringan dapat berdampak.

   Tim Kadlec telah melakukan penelitian fantastis tentang kinerja kerangka kerja modern, dan merangkumnya dalam artikel "Kerangka kerja JavaScript memiliki biaya". Kami sering berbicara tentang dampak kerangka kerja mandiri, tetapi seperti yang dicatat oleh Tim, dalam praktiknya, tidak jarang ada banyak kerangka kerja yang digunakan . Mungkin jQuery versi lama yang perlahan-lahan bermigrasi ke kerangka kerja modern, bersama dengan beberapa aplikasi lawas yang menggunakan versi Angular yang lebih lama. Jadi, lebih masuk akal untuk mengeksplorasi biaya kumulatif byte JavaScript dan waktu eksekusi CPU yang dapat dengan mudah membuat pengalaman pengguna hampir tidak dapat digunakan, bahkan pada perangkat kelas atas.

   Secara umum, kerangka kerja modern tidak memprioritaskan perangkat yang kurang kuat , sehingga pengalaman di ponsel dan di desktop sering kali akan sangat berbeda dalam hal kinerja. Menurut penelitian, situs dengan React atau Angular menghabiskan lebih banyak waktu pada CPU daripada yang lain (yang tentu saja tidak berarti bahwa React lebih mahal pada CPU daripada Vue.js).

   Menurut Tim, satu hal yang jelas: "jika Anda menggunakan kerangka kerja untuk membangun situs Anda, Anda membuat trade-off dalam hal kinerja awal — bahkan dalam skenario terbaik."

1. Evaluasi kerangka kerja dan dependensi.
   Sekarang, tidak setiap proyek membutuhkan kerangka kerja dan tidak setiap halaman aplikasi satu halaman perlu memuat kerangka kerja. Dalam kasus Netflix, "menghapus React, beberapa perpustakaan dan kode aplikasi yang sesuai dari sisi klien mengurangi jumlah total JavaScript lebih dari 200KB, menyebabkan pengurangan lebih dari 50% pada Time-to-Interaktivitas Netflix untuk beranda keluar ." Tim kemudian memanfaatkan waktu yang dihabiskan oleh pengguna di halaman arahan untuk mengambil terlebih dahulu React untuk halaman berikutnya yang kemungkinan akan dikunjungi pengguna (baca terus untuk detailnya).

   Jadi bagaimana jika Anda menghapus kerangka kerja yang ada pada halaman kritis sama sekali? Dengan Gatsby, Anda dapat memeriksa gatsby-plugin-no-javascript yang menghapus semua file JavaScript yang dibuat oleh Gatsby dari file HTML statis. Di Vercel, Anda juga dapat mengizinkan penonaktifan JavaScript runtime dalam produksi untuk halaman tertentu (eksperimental).

   Setelah kerangka kerja dipilih, kami akan tetap menggunakannya selama setidaknya beberapa tahun, jadi jika kami perlu menggunakannya, kami perlu memastikan pilihan kami diinformasikan dan dipertimbangkan dengan baik — dan itu berlaku terutama untuk metrik kinerja utama yang kami peduli.

   Data menunjukkan bahwa, secara default, kerangka kerja cukup mahal: 58,6% halaman React mengirimkan lebih dari 1 MB JavaScript, dan 36% pemuatan halaman Vue.js memiliki First Contentful Paint <1,5s. Menurut sebuah studi oleh Ankur Sethi, "aplikasi React Anda tidak akan pernah memuat lebih cepat dari sekitar 1,1 detik pada rata-rata ponsel di India, tidak peduli seberapa banyak Anda mengoptimalkannya. Aplikasi Angular Anda akan selalu membutuhkan setidaknya 2,7 detik untuk boot. pengguna aplikasi Vue Anda perlu menunggu setidaknya 1 detik sebelum mereka dapat mulai menggunakannya." Anda mungkin tidak menargetkan India sebagai pasar utama Anda, tetapi pengguna yang mengakses situs Anda dengan kondisi jaringan yang kurang optimal akan memiliki pengalaman yang sebanding.

   Tentu saja dimungkinkan untuk membuat SPA dengan cepat, tetapi mereka tidak cepat keluar dari kotak, jadi kita perlu memperhitungkan waktu dan upaya yang diperlukan untuk membuat dan mempertahankannya dengan cepat. Mungkin akan lebih mudah dengan memilih biaya kinerja dasar yang ringan sejak awal.

   Jadi bagaimana kita memilih kerangka kerja ? Sebaiknya pertimbangkan setidaknya total biaya berdasarkan ukuran + waktu eksekusi awal sebelum memilih opsi; opsi ringan seperti Preact, Inferno, Vue, Svelte, Alpine atau Polymer dapat menyelesaikan pekerjaan dengan baik. Ukuran baseline Anda akan menentukan batasan untuk kode aplikasi Anda.

   Seperti yang dicatat oleh Seb Markbage, cara yang baik untuk mengukur biaya awal untuk kerangka kerja adalah dengan merender tampilan terlebih dahulu, lalu menghapusnya, lalu merendernya lagi karena ini dapat memberi tahu Anda bagaimana skala kerangka kerja. Render pertama cenderung menghangatkan sekelompok kode yang dikompilasi dengan malas, yang dapat dimanfaatkan oleh pohon yang lebih besar saat skala. Render kedua pada dasarnya adalah emulasi tentang bagaimana penggunaan kembali kode pada halaman memengaruhi karakteristik kinerja seiring dengan semakin kompleksnya halaman.

   Anda dapat mengevaluasi kandidat Anda (atau pustaka JavaScript apa pun secara umum) pada sistem penilaian skala 12 poin Sacha Greif dengan menjelajahi fitur, aksesibilitas, stabilitas, kinerja, ekosistem paket , komunitas, kurva pembelajaran, dokumentasi, perkakas, rekam jejak , tim, kompatibilitas, keamanan misalnya.

   

   Anda juga dapat mengandalkan data yang dikumpulkan di web dalam jangka waktu yang lebih lama. Misalnya, Perf Track melacak kinerja framework dalam skala besar, menampilkan skor Core Web Vitals teragregasi asal untuk situs web yang dibuat di Angular, React, Vue, Polymer, Preact, Ember, Svelte, dan AMP. Anda bahkan dapat menentukan dan membandingkan situs web yang dibuat dengan Gatsby, Next.js atau Create React App, serta situs web yang dibuat dengan Nuxt.js (Vue) atau Sapper (Svelte).

   Titik awal yang baik adalah memilih tumpukan default yang baik untuk aplikasi Anda. Gatsby (React), Next.js (React), Vuepress (Vue), Preact CLI, dan PWA Starter Kit menyediakan default yang wajar untuk pemuatan cepat di luar kotak pada rata-rata perangkat keras seluler. ​​Juga, lihat panduan kinerja khusus kerangka kerja web.dev untuk React dan Angular ( terima kasih, Phillip! ).

   Dan mungkin Anda bisa mengambil pendekatan yang sedikit lebih menyegarkan untuk membangun aplikasi satu halaman sekaligus — Turbolinks, library JavaScript 15KB yang menggunakan HTML alih-alih JSON untuk merender tampilan. Jadi ketika Anda mengikuti tautan, Turbolinks secara otomatis mengambil halaman, menukar <body> nya, dan menggabungkan <head> nya, semua tanpa menimbulkan biaya pemuatan halaman penuh. Anda dapat memeriksa detail cepat dan dokumentasi lengkap tentang tumpukan (Hotwire).

1. Render sisi klien atau rendering sisi server? Keduanya!
   Itu percakapan yang cukup panas untuk dilakukan. Pendekatan utama adalah menyiapkan semacam boot progresif: Gunakan rendering sisi server untuk mendapatkan First Contenful Paint yang cepat, tetapi juga sertakan beberapa JavaScript minimal yang diperlukan untuk menjaga waktu-untuk-interaktif tetap dekat dengan First Contentful Paint. Jika JavaScript datang terlambat setelah FCP, browser akan mengunci utas utama saat mem-parsing, mengkompilasi, dan mengeksekusi JavaScript yang ditemukan terlambat, sehingga membelenggu interaktivitas situs atau aplikasi.

   Untuk menghindarinya, selalu pisahkan eksekusi fungsi menjadi tugas-tugas asinkron yang terpisah, dan jika memungkinkan gunakan requestIdleCallback . Pertimbangkan pemuatan lambat bagian UI menggunakan dukungan import() dinamis WebPack, menghindari biaya pemuatan, penguraian, dan kompilasi hingga pengguna benar-benar membutuhkannya ( terima kasih Addy! ).

   Seperti disebutkan di atas, Time to Interactive (TTI) memberi tahu kita waktu antara navigasi dan interaktivitas. Secara rinci, metrik ditentukan dengan melihat jendela lima detik pertama setelah konten awal dirender, di mana tidak ada tugas JavaScript yang membutuhkan waktu lebih dari 50 md ( Tugas Panjang ). Jika tugas lebih dari 50 ms terjadi, pencarian untuk jendela lima detik akan dimulai kembali. Akibatnya, browser pertama-tama akan menganggap bahwa itu mencapai Interactive , hanya untuk beralih ke Frozen , hanya untuk akhirnya beralih kembali ke Interactive .

   Setelah kami mencapai Interactive , kami kemudian dapat — baik sesuai permintaan atau jika waktu memungkinkan — mem-boot bagian aplikasi yang tidak penting. Sayangnya, seperti yang diperhatikan oleh Paul Lewis, kerangka kerja biasanya tidak memiliki konsep prioritas sederhana yang dapat ditampilkan ke pengembang, dan karenanya booting progresif tidak mudah diterapkan dengan sebagian besar pustaka dan kerangka kerja.

   Tetap saja, kita sedang menuju ke sana. Saat ini ada beberapa pilihan yang dapat kita jelajahi, dan Houssein Djirdeh dan Jason Miller memberikan gambaran yang sangat baik tentang opsi ini dalam pembicaraan mereka tentang Rendering di Web dan tulisan Jason dan Addy tentang Arsitektur Front-End Modern. Ikhtisar di bawah ini didasarkan pada karya bintang mereka.

   • Rendering Sisi Server (SSR) Penuh
     Di SSR klasik, seperti WordPress, semua permintaan ditangani sepenuhnya di server. Konten yang diminta dikembalikan sebagai halaman HTML yang sudah jadi dan browser dapat langsung merendernya. Oleh karena itu, aplikasi SSR tidak dapat benar-benar menggunakan DOM API, misalnya. Kesenjangan antara First Contentful Paint dan Time to Interactive biasanya kecil, dan halaman dapat langsung dirender saat HTML dialirkan ke browser.

     Ini menghindari bolak-balik tambahan untuk pengambilan data dan pembuatan templat pada klien, karena ditangani sebelum browser mendapat respons. Namun, kami berakhir dengan waktu berpikir server yang lebih lama dan akibatnya Time To First Byte dan kami tidak menggunakan fitur aplikasi modern yang responsif dan kaya.

   • Rendering Statis
     Kami membangun produk sebagai aplikasi satu halaman, tetapi semua halaman dirender sebelumnya ke HTML statis dengan JavaScript minimal sebagai langkah pembuatan. Itu berarti bahwa dengan rendering statis, kami menghasilkan file HTML individual untuk setiap URL yang mungkin sebelumnya, yang merupakan sesuatu yang tidak dapat dilakukan oleh banyak aplikasi. Tetapi karena HTML untuk halaman tidak harus dibuat dengan cepat, kita dapat mencapai Time To First Byte yang cepat secara konsisten. Dengan demikian, kami dapat menampilkan halaman arahan dengan cepat dan kemudian mengambil kerangka SPA untuk halaman berikutnya. Netflix telah mengadopsi pendekatan ini untuk mengurangi pemuatan dan Time-to-Interactive sebesar 50%.

   • Rendering Sisi Server Dengan (Re)Hidrasi (Rendering Universal, SSR + CSR)
     Kita dapat mencoba menggunakan yang terbaik dari kedua dunia — pendekatan SSR dan CSR. Dengan campuran hidrasi, halaman HTML yang dikembalikan dari server juga berisi skrip yang memuat aplikasi sisi klien yang lengkap. Idealnya, itu mencapai First Contentful Paint (seperti SSR) yang cepat dan kemudian melanjutkan rendering dengan (re)hydration. Sayangnya, itu jarang terjadi. Lebih sering, halaman memang terlihat siap tetapi tidak dapat menanggapi masukan pengguna, menghasilkan klik marah dan pengabaian.

     Dengan React, kita dapat menggunakan modul ReactDOMServer pada server Node seperti Express, dan kemudian memanggil metode renderToString untuk merender komponen tingkat atas sebagai string HTML statis.

     Dengan Vue.js, kita dapat menggunakan vue-server-renderer untuk merender instance Vue ke dalam HTML menggunakan renderToString . Di Angular, kita dapat menggunakan @nguniversal untuk mengubah permintaan klien menjadi halaman HTML yang sepenuhnya dirender oleh server. Pengalaman yang sepenuhnya dirender server juga dapat dicapai dengan Next.js (React) atau Nuxt.js (Vue).

     

     Pendekatan ini memiliki kelemahan. Akibatnya, kami mendapatkan fleksibilitas penuh dari aplikasi sisi klien sambil memberikan rendering sisi server yang lebih cepat, tetapi kami juga berakhir dengan kesenjangan yang lebih panjang antara First Contentful Paint dan Time To Interactive dan peningkatan First Input Delay. Rehidrasi sangat mahal, dan biasanya strategi ini saja tidak akan cukup baik karena sangat menunda Time To Interactive.

   • Streaming Rendering Sisi Server Dengan Hidrasi Progresif (SSR + CSR)
     Untuk meminimalkan kesenjangan antara Time To Interactive dan First Contentful Paint, kami merender beberapa permintaan sekaligus dan mengirimkan konten dalam potongan saat dibuat. Jadi kita tidak perlu menunggu string penuh HTML sebelum mengirim konten ke browser, dan karenanya meningkatkan Time To First Byte.

     Di React, alih-alih renderToString() , kita bisa menggunakan renderToNodeStream() untuk menyalurkan respons dan mengirim HTML ke dalam potongan. Di Vue, kita bisa menggunakan renderToStream() yang bisa disalurkan dan dialirkan. Dengan React Suspense, kita mungkin menggunakan rendering asinkron untuk tujuan itu juga.

     Di sisi klien, daripada mem-boot seluruh aplikasi sekaligus, kami mem-boot komponen secara bertahap . Bagian dari aplikasi pertama-tama dipecah menjadi skrip mandiri dengan pemecahan kode, dan kemudian dihidrasi secara bertahap (sesuai urutan prioritas kami). Faktanya, kita bisa menghidrasi komponen penting terlebih dahulu, sedangkan sisanya bisa terhidrasi nanti. Peran rendering sisi klien dan sisi server kemudian dapat didefinisikan secara berbeda per komponen. Kami kemudian juga dapat menunda hidrasi beberapa komponen hingga terlihat, atau diperlukan untuk interaksi pengguna, atau saat browser tidak digunakan.

     Untuk Vue, Markus Oberlehner telah menerbitkan panduan untuk mengurangi Time To Interactive dari aplikasi SSR menggunakan hidrasi pada interaksi pengguna serta vue-lazy-hydration, plugin tahap awal yang memungkinkan hidrasi komponen pada visibilitas atau interaksi pengguna tertentu. Tim Angular mengerjakan hidrasi progresif dengan Ivy Universal. Anda juga dapat menerapkan hidrasi parsial dengan Preact dan Next.js.

   • Rendering Trisomorfik
     Dengan pekerja layanan di tempat, kita dapat menggunakan rendering server streaming untuk navigasi awal/non-JS, dan kemudian pekerja layanan mengambil rendering HTML untuk navigasi setelah diinstal. Dalam hal ini, pekerja layanan melakukan pra-perenderan konten dan mengaktifkan navigasi gaya SPA untuk merender tampilan baru di sesi yang sama. Bekerja dengan baik ketika Anda dapat berbagi templating dan kode perutean yang sama antara server, halaman klien, dan pekerja layanan.

   

   • CSR Dengan Prarendering
     Praperenderan mirip dengan perenderan sisi server tetapi alih-alih merender halaman di server secara dinamis, kami merender aplikasi ke HTML statis pada waktu pembuatan. Meskipun laman statis sepenuhnya interaktif tanpa banyak JavaScript sisi klien, pra- perenderan bekerja secara berbeda . Pada dasarnya ini menangkap keadaan awal aplikasi sisi klien sebagai HTML statis pada waktu pembuatan, sementara dengan prarender aplikasi harus di-boot pada klien agar halaman menjadi interaktif.

     Dengan Next.js, kita dapat menggunakan ekspor HTML statis dengan melakukan pra-render aplikasi ke HTML statis. Di Gatsby, generator situs statis open source yang menggunakan React, menggunakan metode renderToStaticMarkup alih-alih metode renderToString selama build, dengan potongan JS utama yang dimuat sebelumnya dan rute masa depan diambil sebelumnya, tanpa atribut DOM yang tidak diperlukan untuk halaman statis sederhana.

     Untuk Vue, kita dapat menggunakan Vuepress untuk mencapai tujuan yang sama. Anda juga dapat menggunakan prerender-loader dengan Webpack. Navi juga menyediakan rendering statis.

     Hasilnya adalah Time To First Byte dan First Contentful Paint yang lebih baik, dan kami mengurangi jarak antara Time To Interactive dan First Contentful Paint. Kami tidak dapat menggunakan pendekatan ini jika kontennya diperkirakan akan banyak berubah. Plus, semua URL harus diketahui sebelumnya untuk menghasilkan semua halaman. Jadi beberapa komponen mungkin dirender menggunakan prarendering, tetapi jika kita membutuhkan sesuatu yang dinamis, kita harus mengandalkan aplikasi untuk mengambil konten.

   • Rendering Sisi Klien (CSR) Penuh
     Semua logika, rendering, dan booting dilakukan pada klien. Hasilnya biasanya kesenjangan besar antara Time To Interactive dan First Contentful Paint. Akibatnya, aplikasi sering terasa lamban karena seluruh aplikasi harus di-boot pada klien untuk merender apa pun.

     Karena JavaScript memiliki biaya kinerja, seiring dengan bertambahnya jumlah JavaScript dengan suatu aplikasi, pemecahan kode yang agresif dan penundaan JavaScript akan mutlak diperlukan untuk menjinakkan dampak JavaScript. Untuk kasus seperti itu, rendering sisi server biasanya akan menjadi pendekatan yang lebih baik jika tidak banyak interaktivitas yang diperlukan. Jika ini bukan pilihan, pertimbangkan untuk menggunakan The App Shell Model.

     Secara umum, RSK lebih cepat dari CSR. Namun tetap saja, ini merupakan implementasi yang cukup sering untuk banyak aplikasi di luar sana.

   Jadi, sisi klien atau sisi server? Secara umum, sebaiknya batasi penggunaan kerangka kerja sisi klien sepenuhnya pada halaman yang benar-benar membutuhkannya. Untuk aplikasi tingkat lanjut, bukanlah ide yang baik untuk mengandalkan rendering sisi server saja. Rendering server dan rendering klien adalah bencana jika dilakukan dengan buruk.

   Baik Anda condong ke CSR atau SSR, pastikan Anda merender piksel penting sesegera mungkin dan meminimalkan kesenjangan antara rendering itu dan Time To Interactive. Pertimbangkan untuk melakukan pra-perenderan jika halaman Anda tidak banyak berubah, dan tunda booting kerangka kerja jika Anda bisa. Streaming HTML dalam potongan dengan rendering sisi server, dan terapkan hidrasi progresif untuk rendering sisi klien — dan hidrasi pada visibilitas, interaksi, atau selama waktu idle untuk mendapatkan yang terbaik dari kedua dunia.

1. Berapa banyak yang bisa kita layani secara statis?
   Baik Anda bekerja pada aplikasi besar atau situs kecil, ada baiknya mempertimbangkan konten apa yang dapat disajikan secara statis dari CDN (yaitu JAM Stack), daripada dihasilkan secara dinamis dengan cepat. Bahkan jika Anda memiliki ribuan produk dan ratusan filter dengan banyak pilihan personalisasi, Anda mungkin masih ingin menyajikan halaman arahan penting Anda secara statis, dan memisahkan halaman-halaman ini dari kerangka pilihan Anda.

   Ada banyak generator situs statis dan halaman yang mereka hasilkan seringkali sangat cepat. Semakin banyak konten yang dapat kami buat sebelumnya alih-alih menghasilkan tampilan halaman di server atau klien pada waktu permintaan, kinerja yang lebih baik akan kami capai.

   Dalam Membangun Situs Web Statis yang Dihidrasi Sebagian, Ditingkatkan Secara Progresif, Markus Oberlehner menunjukkan cara membuat situs web dengan generator situs statis dan SPA, sambil mencapai peningkatan progresif dan ukuran bundel JavaScript minimal. Markus menggunakan Eleventy dan Preact sebagai alatnya, dan menunjukkan cara menyiapkan alat, menambahkan hidrasi parsial, hidrasi malas, file entri klien, mengonfigurasi Babel untuk Preact dan menggabungkan Preact dengan Rollup — dari awal hingga akhir.

   Dengan JAMStack yang digunakan di situs besar akhir-akhir ini, pertimbangan kinerja baru muncul: waktu pembuatan . Faktanya, membangun bahkan ribuan halaman dengan setiap penerapan baru dapat memakan waktu beberapa menit, sehingga menjanjikan untuk melihat peningkatan bertahap di Gatsby yang meningkatkan waktu pembuatan hingga 60 kali , dengan integrasi ke dalam solusi CMS populer seperti WordPress, Contentful, Drupal, Netlify CMS dan lain-lain.

   

   Selain itu, Next.js mengumumkan pembuatan statis sebelumnya dan inkremental, yang memungkinkan kita untuk menambahkan halaman statis baru saat runtime dan memperbarui halaman yang ada setelah dibuat, dengan merender ulang di latar belakang saat lalu lintas masuk .

   Butuh pendekatan yang lebih ringan? Dalam ceramahnya tentang Eleventy, Alpine dan Tailwind: menuju Jamstack yang ringan, Nicola Goutay menjelaskan perbedaan antara CSR, SSR, dan segala sesuatu di antaranya, dan menunjukkan cara menggunakan pendekatan yang lebih ringan — bersama dengan repo GitHub yang menunjukkan pendekatan dalam praktek.

2. Pertimbangkan untuk menggunakan pola PRPL dan arsitektur shell aplikasi.
   Kerangka kerja yang berbeda akan memiliki efek yang berbeda pada kinerja dan akan memerlukan strategi pengoptimalan yang berbeda, jadi Anda harus memahami dengan jelas semua mur dan baut kerangka yang akan Anda andalkan. Saat membangun aplikasi web, lihat pola PRPL dan arsitektur shell aplikasi. Idenya cukup mudah: Dorong kode minimal yang diperlukan agar interaktif agar rute awal dapat dirender dengan cepat, lalu gunakan service worker untuk sumber daya caching dan pra-caching, lalu pemuatan lambat rute yang Anda butuhkan, secara asinkron.

1. Sudahkah Anda mengoptimalkan kinerja API Anda?
   API adalah saluran komunikasi aplikasi untuk mengekspos data ke aplikasi internal dan pihak ketiga melalui titik akhir . Saat merancang dan membangun API, kami memerlukan protokol yang masuk akal untuk mengaktifkan komunikasi antara server dan permintaan pihak ketiga. Representasional State Transfer ( REST ) adalah pilihan logis yang mapan: ini mendefinisikan serangkaian batasan yang diikuti pengembang untuk membuat konten dapat diakses dengan cara yang berkinerja baik, andal, dan skalabel. Layanan web yang sesuai dengan batasan REST, disebut layanan web RESTful .

   Seperti halnya permintaan HTTP lama, ketika data diambil dari API, setiap penundaan dalam respons server akan menyebar ke pengguna akhir, sehingga menunda rendering . Saat sumber daya ingin mengambil beberapa data dari API, ia perlu meminta data dari titik akhir yang sesuai. Komponen yang merender data dari beberapa sumber, seperti artikel dengan komentar dan foto penulis di setiap komentar, mungkin memerlukan beberapa perjalanan bolak-balik ke server untuk mengambil semua data sebelum dapat dirender. Selain itu, jumlah data yang dikembalikan melalui REST seringkali lebih dari yang dibutuhkan untuk merender komponen tersebut.

   Jika banyak sumber daya memerlukan data dari API, API mungkin menjadi penghambat kinerja. GraphQL memberikan solusi berkinerja untuk masalah ini. Per se, GraphQL adalah bahasa kueri untuk API Anda, dan runtime sisi server untuk mengeksekusi kueri dengan menggunakan sistem tipe yang Anda tetapkan untuk data Anda. Tidak seperti REST, GraphQL dapat mengambil semua data dalam satu permintaan , dan responsnya akan persis seperti yang diperlukan, tanpa pengambilan data yang berlebihan atau kurang seperti yang biasanya terjadi dengan REST.

   Selain itu, karena GraphQL menggunakan skema (metadata yang memberi tahu bagaimana data terstruktur), GraphQL sudah dapat mengatur data ke dalam struktur yang diinginkan, jadi, misalnya, dengan GraphQL, kita dapat menghapus kode JavaScript yang digunakan untuk menangani manajemen status, menghasilkan kode aplikasi yang lebih bersih yang berjalan lebih cepat di klien.

   Jika Anda ingin memulai GraphQL atau mengalami masalah kinerja, artikel ini mungkin cukup membantu:

   • A GraphQL Primer: Mengapa Kami Membutuhkan Jenis API Baru oleh Eric Baer,
   • A GraphQL Primer: Evolusi Desain API oleh Eric Baer,
   • Merancang server GraphQL untuk kinerja optimal oleh Leonardo Losoviz,
   • Performa GraphQL dijelaskan oleh Wojciech Trocki.

1. Apakah Anda akan menggunakan AMP atau Artikel Instan?
   Bergantung pada prioritas dan strategi organisasi Anda, Anda mungkin ingin mempertimbangkan untuk menggunakan AMP Google atau Artikel Instan Facebook atau Apple News Apple. Anda dapat mencapai kinerja yang baik tanpa mereka, tetapi AMP menyediakan kerangka kerja kinerja yang solid dengan jaringan pengiriman konten (CDN) gratis , sementara Artikel Instan akan meningkatkan visibilitas dan kinerja Anda di Facebook.

   Manfaat yang tampak nyata dari teknologi ini bagi pengguna adalah kinerja yang terjamin , jadi terkadang mereka bahkan lebih memilih tautan AMP-/Apple News/Halaman Instan daripada halaman "biasa" dan berpotensi membengkak. Untuk situs web dengan konten berat yang berurusan dengan banyak konten pihak ketiga, opsi ini berpotensi membantu mempercepat waktu render secara dramatis.

   Kecuali mereka tidak melakukannya. Menurut Tim Kadlec, misalnya, "Dokumen AMP cenderung lebih cepat daripada rekan-rekan mereka, tetapi mereka tidak selalu berarti sebuah halaman berkinerja baik. Bukan AMP yang membuat perbedaan terbesar dari perspektif kinerja."

   Manfaat bagi pemilik situs web jelas: dapat ditemukannya format ini di platform masing-masing dan peningkatan visibilitas di mesin telusur.

   Yah, setidaknya begitulah dulu. Karena AMP tidak lagi menjadi persyaratan untuk Berita Teratas , penayang mungkin beralih dari AMP ke tumpukan tradisional ( terima kasih, Barry! ).

   Namun, Anda juga dapat membuat AMP web progresif dengan menggunakan kembali AMP sebagai sumber data untuk PWA Anda. Kelemahan? Jelas, kehadiran di taman bertembok menempatkan pengembang dalam posisi untuk memproduksi dan memelihara versi terpisah dari konten mereka, dan dalam kasus Artikel Instan dan Apple News tanpa URL yang sebenarnya (terima kasih Addy, Jeremy!) .

2. Pilih CDN Anda dengan bijak.
   Seperti disebutkan di atas, tergantung pada seberapa banyak data dinamis yang Anda miliki, Anda mungkin dapat "mengalihdayakan" beberapa bagian konten ke generator situs statis, mendorongnya ke CDN dan menyajikan versi statis darinya, sehingga menghindari permintaan ke server. Faktanya, beberapa dari generator tersebut sebenarnya adalah kompiler situs web dengan banyak pengoptimalan otomatis yang disediakan di luar kotak. Saat kompiler menambahkan optimasi dari waktu ke waktu, output yang dikompilasi menjadi lebih kecil dan lebih cepat dari waktu ke waktu.

   Perhatikan bahwa CDN juga dapat menyajikan (dan membongkar) konten dinamis. Jadi, tidak perlu membatasi CDN Anda ke aset statis. Periksa kembali apakah CDN Anda melakukan kompresi dan konversi (mis. pengoptimalan gambar dan pengubahan ukuran di tepi), apakah mereka menyediakan dukungan untuk pekerja server, pengujian A/B, serta menyertakan sisi tepi, yang merakit bagian halaman statis dan dinamis di tepi CDN (yaitu server yang paling dekat dengan pengguna), dan tugas lainnya. Juga, periksa apakah CDN Anda mendukung HTTP melalui QUIC (HTTP/3).

   Katie Hempenius telah menulis panduan fantastis untuk CDN yang memberikan wawasan tentang cara memilih CDN yang baik , cara menyempurnakannya, dan semua hal kecil yang perlu diingat saat mengevaluasinya. Secara umum, adalah ide yang baik untuk menyimpan konten seagresif mungkin dan mengaktifkan fitur kinerja CDN seperti Brotli, TLS 1.3, HTTP/2, dan HTTP/3.

   Catatan : berdasarkan penelitian oleh Patrick Meenan dan Andy Davies, prioritas HTTP/2 secara efektif rusak pada banyak CDN, jadi berhati-hatilah saat memilih CDN. Patrick memiliki detail lebih lanjut dalam ceramahnya tentang Prioritas HTTP/2 ( terima kasih, Barry! ).

   

   Saat memilih CDN, Anda dapat menggunakan situs perbandingan ini dengan gambaran rinci tentang fitur-fiturnya:

   • Perbandingan CDN, matriks perbandingan CDN untuk Cloudfront, Aazure, KeyCDN, Fastly, Verizon, Stackpach, Akamai, dan banyak lainnya.
   • CDN Perf mengukur kecepatan kueri untuk CDN dengan mengumpulkan dan menganalisis 300 juta pengujian setiap hari, dengan semua hasil berdasarkan data RUM dari pengguna di seluruh dunia. Periksa juga perbandingan Kinerja DNS dan Perbandingan Kinerja Cloud.
   • CDN Planet Guides memberikan ikhtisar CDN untuk topik tertentu, seperti Serve Stale, Purge, Origin Shield, Prefetch, dan Compression.
   • Almanak Web: Adopsi dan Penggunaan CDN memberikan wawasan tentang penyedia CDN teratas, manajemen RTT dan TLS mereka, waktu negosiasi TLS, adopsi HTTP/2, dan lainnya. (Sayangnya, datanya hanya dari 2019).

Daftar isi

1. Persiapan: Perencanaan Dan Metrik
2. Menetapkan Tujuan yang Realistis
3. Mendefinisikan Lingkungan
4. Pengoptimalan Aset
5. Membangun Optimasi
6. Pengoptimalan Pengiriman
7. Jaringan, HTTP/2, HTTP/3
8. Pengujian Dan Pemantauan
9. Kemenangan Cepat
10. Semuanya dalam satu halaman
11. Unduh Daftar Periksa (PDF, Halaman Apple, MS Word)
12. Berlangganan buletin email kami agar tidak ketinggalan panduan berikutnya.