Kinerja Front-End 2021: Jaringan, HTTP/2, HTTP/3

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.

Jaringan, HTTP/2, HTTP/3

1. Apakah penjepretan OCSP diaktifkan?
   Dengan mengaktifkan OCSP stapel di server Anda, Anda dapat mempercepat handshake TLS Anda. Protokol Status Sertifikat Online (OCSP) dibuat sebagai alternatif untuk protokol Daftar Pencabutan Sertifikat (CRL). Kedua protokol tersebut digunakan untuk memeriksa apakah sertifikat SSL telah dicabut.

   Namun, protokol OCSP tidak mengharuskan browser menghabiskan waktu mengunduh dan kemudian mencari daftar informasi sertifikat, sehingga mengurangi waktu yang diperlukan untuk jabat tangan.

2. Sudahkah Anda mengurangi dampak pencabutan sertifikat SSL?
   Dalam artikelnya tentang "Biaya Kinerja Sertifikat EV", Simon Hearne memberikan gambaran umum yang bagus tentang sertifikat umum, dan dampak pilihan sertifikat terhadap kinerja secara keseluruhan.

   Seperti yang ditulis Simon, di dunia HTTPS, ada beberapa jenis tingkat validasi sertifikat yang digunakan untuk mengamankan lalu lintas:

   • Validasi Domain (DV) memvalidasi bahwa pemohon sertifikat memiliki domain,
   • Validasi Organisasi (OV) memvalidasi bahwa organisasi memiliki domain,
   • Extended Validation (EV) memvalidasi bahwa organisasi memiliki domain, dengan validasi yang ketat.

   Penting untuk dicatat bahwa semua sertifikat ini sama dalam hal teknologi; mereka hanya berbeda dalam informasi dan properti yang disediakan dalam sertifikat tersebut.

   Sertifikat EV mahal dan memakan waktu karena memerlukan manusia untuk meninjau sertifikat dan memastikan validitasnya. Sertifikat DV, di sisi lain, sering diberikan secara gratis — misalnya oleh Let's Encrypt — otoritas sertifikat otomatis terbuka yang terintegrasi dengan baik ke banyak penyedia hosting dan CDN. Faktanya, pada saat penulisan, ini mendukung lebih dari 225 juta situs web (PDF), meskipun hanya menghasilkan 2,69% halaman (dibuka di Firefox).

   Jadi apa masalahnya? Masalahnya adalah bahwa sertifikat EV tidak sepenuhnya mendukung stapel OCSP yang disebutkan di atas. Sementara stapel memungkinkan server untuk memeriksa dengan Otoritas Sertifikat jika sertifikat telah dicabut dan kemudian menambahkan ("staple") informasi ini ke sertifikat, tanpa menstaples klien harus melakukan semua pekerjaan, menghasilkan permintaan yang tidak perlu selama negosiasi TLS . Pada koneksi yang buruk, ini mungkin berakhir dengan biaya kinerja yang nyata (1000ms+).

   Sertifikat EV bukanlah pilihan yang bagus untuk kinerja web, dan mereka dapat menyebabkan dampak yang jauh lebih besar pada kinerja daripada sertifikat DV. Untuk kinerja web yang optimal, selalu sajikan sertifikat DV yang dijilid OCSP. Mereka juga jauh lebih murah daripada sertifikat EV dan lebih sedikit kerumitan untuk mendapatkannya. Yah, setidaknya sampai CRlite tersedia.

   

   Catatan : Dengan QUIC/HTTP/3 pada kami, perlu dicatat bahwa rantai sertifikat TLS adalah satu-satunya konten berukuran variabel yang mendominasi jumlah byte di QUIC Handshake. Ukurannya bervariasi antara beberapa ratus bye dan lebih dari 10 KB.

   Jadi menyimpan sertifikat TLS kecil sangat berarti di QUIC/HTTP/3, karena sertifikat besar akan menyebabkan banyak jabat tangan. Selain itu, kita perlu memastikan bahwa sertifikat dikompresi, karena jika tidak, rantai sertifikat akan terlalu besar untuk dimuat dalam satu penerbangan QUIC.

   Anda dapat menemukan lebih banyak detail dan petunjuk untuk masalah dan solusi di:

   • Sertifikat EV Membuat Web Lambat dan Tidak Dapat Diandalkan oleh Aaron Peters,
   • Dampak pencabutan sertifikat SSL pada kinerja web oleh Matt Hobbs,
   • Biaya Kinerja Sertifikat EV oleh Simon Hearne,
   • Apakah jabat tangan QUIC memerlukan kompresi agar cepat? oleh Patrick McManus.
3. Sudahkah Anda mengadopsi IPv6?
   Karena kami kehabisan ruang dengan IPv4 dan jaringan seluler utama mengadopsi IPv6 dengan cepat (AS hampir mencapai ambang adopsi IPv6 50%), sebaiknya perbarui DNS Anda ke IPv6 agar tetap antipeluru di masa mendatang. Pastikan saja bahwa dukungan tumpukan ganda disediakan di seluruh jaringan — ini memungkinkan IPv6 dan IPv4 berjalan secara bersamaan satu sama lain. Lagi pula, IPv6 tidak kompatibel dengan versi sebelumnya. Selain itu, penelitian menunjukkan bahwa IPv6 membuat situs web tersebut 10 hingga 15% lebih cepat karena penemuan tetangga (NDP) dan pengoptimalan rute.
4. Pastikan semua aset dijalankan melalui HTTP/2 (atau HTTP/3).
   Dengan Google mendorong ke arah web HTTPS yang lebih aman selama beberapa tahun terakhir, beralih ke lingkungan HTTP/2 jelas merupakan investasi yang bagus. Faktanya, menurut Web Almanac, 64% dari semua permintaan sudah berjalan melalui HTTP/2.

   Penting untuk dipahami bahwa HTTP/2 tidak sempurna dan memiliki masalah prioritas, tetapi didukung dengan sangat baik; dan, dalam banyak kasus, Anda lebih baik melakukannya.

   Peringatan: HTTP/2 Server Push sedang dihapus dari Chrome, jadi jika implementasi Anda bergantung pada Server Push, Anda mungkin perlu mengunjunginya kembali. Sebagai gantinya, kita mungkin melihat Petunjuk Awal, yang sudah terintegrasi sebagai eksperimen di Fastly.

   Jika Anda masih menjalankan HTTP, tugas yang paling memakan waktu adalah bermigrasi ke HTTPS terlebih dahulu, lalu menyesuaikan proses build Anda untuk memenuhi multiplexing dan paralelisasi HTTP/2. Membawa HTTP/2 ke Gov.uk adalah studi kasus yang fantastis untuk melakukan hal itu, menemukan jalan melalui CORS, SRI, dan WPT di sepanjang jalan. Untuk sisa artikel ini, kami berasumsi bahwa Anda beralih ke atau sudah beralih ke HTTP/2.

1. Terapkan HTTP/2 dengan benar.
   Sekali lagi, melayani aset melalui HTTP/2 dapat mengambil manfaat dari perbaikan sebagian dari cara Anda melayani aset sejauh ini. Anda harus menemukan keseimbangan yang baik antara modul pengemasan dan memuat banyak modul kecil secara paralel. Pada akhirnya, permintaan terbaik tetap tidak ada permintaan, namun, tujuannya adalah untuk menemukan keseimbangan yang baik antara pengiriman aset pertama yang cepat dan caching.

   Di satu sisi, Anda mungkin ingin menghindari penggabungan aset sama sekali, alih-alih memecah seluruh antarmuka Anda menjadi banyak modul kecil, mengompresinya sebagai bagian dari proses pembuatan dan memuatnya secara paralel. Perubahan dalam satu file tidak memerlukan seluruh style sheet atau JavaScript untuk diunduh ulang. Ini juga meminimalkan waktu penguraian dan menjaga muatan halaman individual tetap rendah.

   Di sisi lain, kemasan tetap penting. Dengan menggunakan banyak skrip kecil, kompresi keseluruhan akan terganggu dan biaya pengambilan objek dari cache akan meningkat. Kompresi paket besar akan mendapat manfaat dari penggunaan kembali kamus, sedangkan paket kecil yang terpisah tidak. Ada pekerjaan standar untuk mengatasinya, tetapi itu masih jauh untuk saat ini. Kedua, browser belum dioptimalkan untuk alur kerja seperti itu. Misalnya, Chrome akan memicu komunikasi antar-proses (IPC) linier dengan jumlah sumber daya, sehingga menyertakan ratusan sumber daya akan memiliki biaya runtime browser.

   

   

   Namun, Anda dapat mencoba memuat CSS secara progresif. Faktanya, CSS in-body tidak lagi memblokir rendering untuk Chrome. Tetapi ada beberapa masalah prioritas sehingga tidak semudah itu, tetapi layak untuk dicoba.

   Anda bisa lolos dengan penggabungan koneksi HTTP/2, yang memungkinkan Anda menggunakan domain sharding sambil memanfaatkan HTTP/2, tetapi mencapai ini dalam praktiknya sulit, dan secara umum, itu tidak dianggap sebagai praktik yang baik. Selain itu, HTTP/2 dan Integritas Subsumber daya tidak selalu aktif.

   Apa yang harus dilakukan? Nah, jika Anda menggunakan HTTP/2, mengirim sekitar 6–10 paket sepertinya merupakan kompromi yang layak (dan tidak terlalu buruk untuk browser lawas). Eksperimen dan ukur untuk menemukan keseimbangan yang tepat untuk situs web Anda.

2. Apakah kami mengirim semua aset melalui satu koneksi HTTP/2?
   Salah satu keuntungan utama HTTP/2 adalah memungkinkan kita mengirim aset melalui kabel melalui satu koneksi. Namun, terkadang kami mungkin telah melakukan kesalahan — misalnya memiliki masalah CORS, atau salah mengonfigurasi atribut crossorigin , sehingga browser terpaksa membuka koneksi baru.

   Untuk memeriksa apakah semua permintaan menggunakan koneksi HTTP/2 tunggal, atau ada sesuatu yang salah dikonfigurasi, aktifkan kolom "ID Koneksi" di DevTools → Jaringan. Misalnya, di sini, semua permintaan berbagi koneksi yang sama (286) — kecuali manifest.json, yang membuka koneksi terpisah (451).

1. Apakah server dan CDN Anda mendukung HTTP/2?
   Server dan CDN yang berbeda (masih) mendukung HTTP/2 secara berbeda. Gunakan Perbandingan CDN untuk memeriksa opsi Anda, atau dengan cepat mencari tahu bagaimana kinerja server Anda dan fitur mana yang dapat Anda harapkan untuk didukung.

   Konsultasikan penelitian luar biasa Pat Meenan tentang prioritas HTTP/2 (video) dan uji dukungan server untuk prioritas HTTP/2. Menurut Pat, direkomendasikan untuk mengaktifkan kontrol kemacetan BBR dan menyetel tcp_notsent_lowat ke 16KB agar prioritas HTTP/2 bekerja dengan andal di kernel Linux 4.9 dan yang lebih baru ( terima kasih, Yoav! ). Andy Davies melakukan penelitian serupa untuk prioritas HTTP/2 di seluruh browser, CDN, dan Layanan Cloud Hosting.

   Saat menggunakannya, periksa kembali apakah kernel Anda mendukung TCP BBR dan aktifkan jika memungkinkan. Saat ini digunakan di Google Cloud Platform, Amazon Cloudfront, Linux (misalnya Ubuntu).

2. Apakah kompresi HPACK sedang digunakan?
   Jika Anda menggunakan HTTP/2, periksa kembali apakah server Anda menerapkan kompresi HPACK untuk header respons HTTP guna mengurangi overhead yang tidak perlu. Beberapa server HTTP/2 mungkin tidak sepenuhnya mendukung spesifikasi, dengan HPACK sebagai contohnya. H2spec adalah alat yang hebat (jika sangat rinci secara teknis) untuk memeriksanya. Algoritma kompresi HPACK cukup mengesankan, dan berhasil.
3. Pastikan keamanan di server Anda antipeluru.
   Semua implementasi browser HTTP/2 dijalankan di atas TLS, jadi Anda mungkin ingin menghindari peringatan keamanan atau beberapa elemen di halaman Anda tidak berfungsi. Periksa kembali apakah header keamanan Anda disetel dengan benar, hilangkan kerentanan yang diketahui, dan periksa pengaturan HTTPS Anda.

   Selain itu, pastikan bahwa semua plugin eksternal dan skrip pelacakan dimuat melalui HTTPS, skrip lintas situs tidak dimungkinkan dan header HTTP Strict Transport Security dan header Kebijakan Keamanan Konten disetel dengan benar.

4. Apakah server dan CDN Anda mendukung HTTP/3?
   Sementara HTTP/2 telah membawa sejumlah peningkatan kinerja yang signifikan ke web, itu juga meninggalkan beberapa area untuk perbaikan — terutama pemblokiran head-of-line di TCP, yang terlihat pada jaringan yang lambat dengan kehilangan paket yang signifikan. HTTP/3 sedang memecahkan masalah ini untuk selamanya (artikel).

   Untuk mengatasi masalah HTTP/2, IETF, bersama dengan Google, Akamai, dan lainnya, telah mengerjakan protokol baru yang baru-baru ini distandarisasi sebagai HTTP/3.

   Robin Marx telah menjelaskan HTTP/3 dengan sangat baik, dan penjelasan berikut didasarkan pada penjelasannya. Pada intinya, HTTP/3 sangat mirip dengan HTTP/2 dalam hal fitur, tetapi cara kerjanya sangat berbeda. HTTP/3 menyediakan sejumlah peningkatan: jabat tangan yang lebih cepat, enkripsi yang lebih baik, aliran independen yang lebih andal, enkripsi dan kontrol aliran yang lebih baik. Perbedaan yang mencolok adalah bahwa HTTP/3 menggunakan QUIC sebagai lapisan transport, dengan paket QUIC yang dienkapsulasi di atas diagram UDP, bukan TCP.

   QUIC sepenuhnya mengintegrasikan TLS 1.3 ke dalam protokol, sementara di TCP itu berlapis di atas. Dalam tumpukan TCP yang khas, kami memiliki beberapa waktu bolak-balik overhead karena TCP dan TLS perlu melakukan jabat tangan mereka sendiri yang terpisah, tetapi dengan QUIC keduanya dapat digabungkan dan diselesaikan hanya dalam satu perjalanan pulang pergi . Karena TLS 1.3 memungkinkan kita untuk mengatur kunci enkripsi untuk koneksi konsekuen, dari koneksi kedua dan seterusnya, kita sudah dapat mengirim dan menerima data lapisan aplikasi dalam perjalanan putaran pertama, yang disebut "0-RTT".

   Juga, algoritma kompresi header HTTP/2 sepenuhnya ditulis ulang, bersama dengan sistem prioritasnya. Plus, QUIC mendukung migrasi koneksi dari Wi-Fi ke jaringan seluler melalui ID koneksi di header setiap paket QUIC. Sebagian besar implementasi dilakukan di ruang pengguna, bukan ruang kernel (seperti yang dilakukan dengan TCP), jadi kita harus mengharapkan protokol berkembang di masa depan.

   Apakah itu semua akan membuat perbedaan besar? Mungkin ya, terutama berdampak pada waktu pemuatan di seluler, tetapi juga pada cara kami menyajikan aset kepada pengguna akhir. Sementara di HTTP/2, beberapa permintaan berbagi koneksi, dalam permintaan HTTP/3 juga berbagi koneksi tetapi streaming secara independen, sehingga paket yang dijatuhkan tidak lagi memengaruhi semua permintaan, hanya satu aliran.

   Itu berarti bahwa meskipun dengan satu bundel JavaScript besar, pemrosesan aset akan diperlambat ketika satu aliran dijeda, dampaknya akan kurang signifikan ketika beberapa file mengalir secara paralel (HTTP/3). Jadi kemasan tetap penting .

   HTTP/3 masih dalam proses. Chrome, Firefox, dan Safari sudah memiliki implementasi. Beberapa CDN sudah mendukung QUIC dan HTTP/3. Pada akhir tahun 2020, Chrome mulai menerapkan HTTP/3 dan IETF QUIC, dan kenyataannya semua layanan Google (Google Analytics, YouTube, dll.) sudah berjalan melalui HTTP/3. LiteSpeed ​​Web Server mendukung HTTP/3, tetapi Apache, nginx, atau IIS belum mendukungnya, tetapi kemungkinan akan berubah dengan cepat pada tahun 2021.

   Intinya : jika Anda memiliki opsi untuk menggunakan HTTP/3 di server dan di CDN Anda, mungkin merupakan ide yang sangat bagus untuk melakukannya. Manfaat utama akan datang dari mengambil beberapa objek secara bersamaan, terutama pada koneksi latensi tinggi. Kami belum tahu pasti karena tidak banyak penelitian yang dilakukan di bidang itu, tetapi hasil pertama sangat menjanjikan.

   Jika Anda ingin lebih mendalami spesifikasi dan keunggulan protokol, berikut adalah beberapa titik awal yang baik untuk diperiksa:

   • HTTP/3 Dijelaskan, upaya kolaboratif untuk mendokumentasikan HTTP/3 dan protokol QUIC. Tersedia dalam berbagai bahasa, juga sebagai PDF.
   • Meningkatkan Kinerja Web Dengan HTTP/3 dengan Daniel Stenberg.
   • Panduan Akademik untuk QUIC dengan Robin Marx memperkenalkan konsep dasar protokol QUIC dan HTTP/3, menjelaskan bagaimana HTTP/3 menangani pemblokiran head-of-line dan migrasi koneksi, dan bagaimana HTTP/3 dirancang untuk selalu hijau (terima kasih, Simon !).
   • Anda dapat memeriksa apakah server Anda berjalan pada HTTP/3 di HTTP3Check.net.

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.