HTTP/2 dan HTTP/3

TL;DR — HTTP/2 dan HTTP/3 adalah versi lebih baru dari “bahasa” yang digunakan browser dan server situs untuk berkomunikasi. Keduanya mempercepat pemuatan halaman dengan mengambil banyak file melalui satu koneksi, bukan banyak koneksi. Keduanya tidak secara langsung meningkatkan peringkat Google Anda—tetapi situs yang lebih cepat dapat membantu secara tidak langsung. Bagi kebanyakan situs, mengaktifkannya cukup melalui pengaturan CDN, bukan proyek besar.

Ketuk untuk memperbesar

The chart compares HTTP/1.x, HTTP/2, and HTTP/3 request share worldwide over four weeks. It is a Cloudflare traffic view, not a census of all websites.

Apa itu HTTP/2 dan HTTP/3

Setiap kali Anda membuka halaman web, browser dan server situs tersebut berkomunikasi menggunakan protokol bernama HTTP. Selama bertahun-tahun, protokolnya adalah HTTP/1.1, yang memiliki hambatan nyata: file biasanya diambil satu per satu, sehingga browser harus membuka beberapa koneksi paralel hanya untuk memuat halaman biasa.

HTTP/2 (dari 2015) memperbaiki sebagian besar hambatan itu. Browser dan server dapat mengirim banyak permintaan dan respons melalui satu koneksi pada saat yang sama—teknik ini disebut multiplexing—dan HTTP/2 memampatkan informasi header berulang yang dikirim bersama setiap permintaan. Hasilnya adalah pemuatan halaman yang lebih cepat dengan overhead yang lebih kecil.

HTTP/3 (dari 2022) melangkah lebih jauh. Protokol ini mempertahankan semua yang dilakukan HTTP/2, tetapi mengubah lapisan transportasi di bawahnya. HTTP/2 berjalan di atas transportasi bernama TCP, dan TCP memiliki keunikan: jika satu paket data hilang, semua hal pada koneksi tersebut harus menunggu paket itu dikirim ulang. HTTP/3 mengganti TCP dengan transportasi yang lebih baru, yaitu QUIC. Pada QUIC, paket yang hilang hanya menahan stream file yang bersangkutan, bukan setiap stream pada koneksi—bukan berarti setiap file menjadi sepenuhnya mandiri karena semuanya tetap berbagi koneksi yang sama—tetapi paket yang terjatuh tidak lagi menyeret seluruh halaman. Manfaat ini paling terasa pada koneksi yang tidak stabil, misalnya ponsel dengan sinyal lemah.

Apakah saya perlu melakukan sesuatu untuk SEO?

Jawaban singkat: tidak banyak, dan jelas bukan demi peringkat.

• Keduanya bukan faktor peringkat langsung. Google menyatakan dengan jelas bahwa HTTP/2 tidak memberikan peningkatan peringkat. HTTP/3 juga tidak tercantum dalam cara kerja crawler Google saat ini, jadi pertanyaan tentang dampak peringkatnya pada dasarnya tidak berlaku.
• Manfaat utamanya adalah kecepatan, dan kecepatan membantu secara tidak langsung. Situs yang lebih cepat dapat memperbaiki Core Web Vitals, yang memang menjadi bagian dari sinyal pengalaman halaman Google. Jadi manfaatnya nyata, hanya melalui satu langkah perantara.
• Kemungkinan besar Anda sudah menggunakan HTTP/2. Sebagian besar web telah menggunakannya. Jika Anda memakai CDN seperti Cloudflare atau Fastly, HTTP/2—dan sering kali HTTP/3—biasanya cukup diaktifkan melalui satu pengaturan. Tetap lakukan pemeriksaan singkat setelahnya: pastikan protokol benar-benar dinegosiasikan melalui panel Network browser, bukan sekadar menganggap pengaturan tersebut berlaku untuk setiap pengunjung.

Hal yang paling sering disalahpahami

Ada fitur lama bernama HTTP/2 Server Push yang masih sering ditanyakan. Jangan membangun sistem untuk itu—dalam praktiknya fitur tersebut sudah mati. Chrome menonaktifkannya secara bawaan mulai Chrome 106, hampir tidak ada yang menggunakannya, dan fitur itu sering membuat situs lebih lambat, bukan lebih cepat. Jika Anda ingin memberi petunjuk agar browser mengambil resource lebih awal, gunakan pengganti modern seperti 103 Early Hints atau tag <link rel=preload>.

Ingin memahami gambaran lengkap—cara kerja QUIC, perilaku Googlebot saat ini, angka adopsi nyata, dan cara mengaktifkannya? Buka tab Advanced.

TL;DR — HTTP/2 = multiplexing + kompresi header HPACK + petunjuk prioritas RFC 9218 melalui satu koneksi TCP. HTTP/3 = semantik yang sama melalui QUIC/UDP, bukan TCP, sehingga paket yang hilang pada satu stream tidak menahan stream lain—meski semua stream tetap berbagi kontrol kemacetan dan state QPACK pada koneksi tersebut. Ini perbaikan nyata, bukan jaminan bahwa setiap file sepenuhnya mandiri. Keduanya bukan faktor peringkat langsung: Google menyatakan tidak ada peningkatan peringkat dari crawling melalui HTTP/2, dan dokumentasi crawler Google tidak mencantumkan HTTP/3 sebagai protokol yang didukung. Googlebot memakai HTTP/1.1 secara bawaan dan HTTP/2 ketika situs memenuhi syarat (dukungan HTTPS + h2), dengan status 421 sebagai cara memilih keluar yang didokumentasikan. Manfaat SEO-nya tidak langsung, karena kecepatan pengguna nyata memengaruhi Core Web Vitals—negosiasi protokol yang lebih baru tidak menjamin Core Web Vitals atau performa Penelusuran yang lebih baik dengan sendirinya. Sebagian besar web sudah memakai HTTP/2; HTTP/3 masih menjadi bagian kecil dari permintaan aktual, dan dukungan CDN pun tidak berarti setiap kunjungan pasti menggunakannya karena ada proses penemuan dan fallback. Dua hal yang sebaiknya dilewati: mengejar peningkatan peringkat dan Server Push (dinonaktifkan secara bawaan di Chrome/Chromium sejak v106—gunakan 103 Early Hints atau rel=preload).

Apa yang sebenarnya diubah tiap protokol

Pahami perbedaan kedua peningkatan ini, dan bagian lainnya akan lebih mudah diikuti.

HTTP/2 (2015, RFC 7540) mempertahankan semantik HTTP, tetapi mengubah cara byte bergerak:

• Multiplexing. Banyak permintaan dan respons disisipkan melalui satu koneksi, bukan model HTTP/1.1 yang menangani satu permintaan per koneksi dan memaksa browser membuka beberapa koneksi paralel.
• Kompresi header HPACK. Header berulang yang dikirim pada setiap permintaan dikompresi sehingga overhead berkurang.
• Prioritas stream—tetapi bukan skema awalnya. Pohon prioritas RFC 7540 sudah didepresiasi oleh pembaruan HTTP/2, RFC 9113. Sinyal yang berlaku sekarang adalah Extensible Priority Scheme RFC 9218—petunjuk sederhana urgency/incremental yang dapat dipakai oleh HTTP/2 dan HTTP/3, serta bersifat anjuran: server dapat mengikutinya, mengikutinya sebagian, atau mengabaikannya.
• Awalnya HTTP/2 juga memiliki Server Push—fitur itu masih didefinisikan secara teknis dalam spesifikasi HTTP/2 dan HTTP/3, tetapi browser pada praktiknya sudah menghentikan dukungannya (lihat bagian berikutnya).
• Dalam praktik, HTTP/2 memerlukan HTTPS—tidak ada browser arus utama yang menegosiasikan HTTP/2 tanpa enkripsi.

HTTP/3 (2022, RFC 9114) mempertahankan semantik HTTP/2, tetapi mengganti transportasinya:

• HTTP/3 berjalan di atas QUIC, transportasi yang dibangun di atas UDP, bukan TCP.
• Hal ini mempersempit head-of-line blocking pada tingkat transportasi HTTP/2, tetapi tidak menghapus semua bentuknya. Pada HTTP/2, semua stream multiplexed berjalan melalui satu koneksi TCP, sehingga satu paket yang hilang menahan setiap stream sampai dikirim ulang. QUIC memberi setiap permintaan HTTP stream sendiri, sehingga paket yang hilang pada satu stream tidak lagi memblokir stream lain—itulah perbaikan utamanya. Namun, setiap file tidak menjadi sepenuhnya mandiri: stream dalam koneksi QUIC yang sama tetap berbagi kontrol kemacetan dan kontrol aliran (jalur jaringan yang buruk tetap memperlambat semuanya, hanya tanpa penahanan lintas-stream), byte di dalam satu stream tetap tiba berurutan (resource yang terdiri dari beberapa paket tetap menunggu paketnya yang hilang), dan dekode header QPACK berjalan melalui control stream bersama yang dapat dibutuhkan stream lain. Anggaplah “kehilangan tidak merembes antar-stream”, bukan “setiap file berjalan dalam isolasi total”.
• QUIC menyertakan TLS 1.3 (enkripsi wajib) dan mendukung pembentukan koneksi yang lebih cepat melalui session resumption—termasuk mode 0-RTT opsional untuk kunjungan berulang. 0-RTT bersifat kondisional, bukan jalur cepat universal: “early data” yang dikirim dapat diputar ulang oleh penyerang, sehingga browser dan server membatasi permintaan yang aman dikirim dengan cara itu. Server dapat menolaknya dan kembali ke handshake normal (lihat 425 Too Early).
• QUIC juga mendukung connection migration—client dapat membawa koneksi melewati perubahan jaringan (WiFi → seluler) setelah memvalidasi jalur jaringan baru—tetapi pada QUIC v1 proses ini hanya diprakarsai client (server tidak dapat memindahkan koneksi sendiri). Validasi jalur, perubahan alamat, dan reset state kemacetan membuat kesinambungan bersifat kondisional, bukan terjamin.

Nuansa yang perlu disampaikan dengan jujur: manfaat terbesar HTTP/3 muncul pada koneksi lambat atau banyak kehilangan paket. Pengguna yang sudah berada di jaringan cepat dan stabil akan merasakan perbedaan yang lebih kecil—bagian trafik Anda yang paling lambat mendapat manfaat terbesar, seperti dijelaskan dengan baik oleh Will Nye di Search Engine Journal. Jangan menjual HTTP/3 secara berlebihan kepada situs yang seluruh audiensnya memakai fiber.

Apakah ini memengaruhi peringkat? (Tidak—berikut rumusan tepatnya)

Inilah pertanyaan yang biasanya dicari oleh praktisi SEO, jadi mulailah dari dokumentasi crawler Google sendiri. Dalam ikhtisar crawler Google, Google menyatakan bahwa crawler-nya mendukung HTTP/1.1 dan HTTP/2, memilih protokol yang memberikan performa crawling terbaik, dan bahwa:

“The default protocol version used by Google’s crawlers is HTTP/1.1; crawling over HTTP/2 may save computing resources (for example, CPU, RAM) for your site and Googlebot, but otherwise there’s no Google-product specific benefit to the site (for example, no ranking boost in Google Search).” (terjemahan) “Versi protokol bawaan yang digunakan crawler Google adalah HTTP/1.1; crawling melalui HTTP/2 dapat menghemat sumber daya komputasi, misalnya CPU dan RAM, untuk situs Anda dan Googlebot, tetapi selain itu tidak ada manfaat khusus produk Google bagi situs, misalnya tidak ada peningkatan peringkat di Google Penelusuran.”

Itu sudah sejelas pernyataan Google. HTTP/2 adalah tuas efisiensi pada lapisan transportasi untuk kedua pihak dalam koneksi—dapat menghemat sebagian pekerjaan server Anda dan Googlebot—tetapi HTTP/2 bukan sinyal peringkat.

Sudut pandang SEO yang sebenarnya bersifat tidak langsung dan perlu dinyatakan dengan jelas: pemuatan halaman yang lebih cepat bagi pengguna nyata berkontribusi pada Core Web Vitals, yang merupakan bagian dari sinyal pengalaman halaman Google. Jadi nilai HTTP/2 dan HTTP/3 bagi SEO adalah investasi pada pengalaman pengguna yang tercermin dalam metrik yang benar-benar diukur Google, bukan sakelar yang dengan sendirinya mengangkat peringkat.

Apa yang sebenarnya dilakukan Googlebot saat ini

Bagian ini sering dilewatkan oleh penjelas lain, padahal paling berguna di halaman ini. Dokumentasi crawler Google sendiri cukup spesifik:

• Bawaan adalah HTTP/1.1. Menurut ikhtisar crawler, HTTP/1.1 merupakan protokol bawaan; Googlebot dapat beralih ke HTTP/2 di antara sesi crawling berdasarkan statistik crawling sebelumnya.
• Crawling HTTP/2 berdasarkan kelayakan, bukan permintaan langsung. Googlebot mulai merayapi sebagian situs melalui HTTP/2 pada pertengahan November 2020 (diumumkan dalam tulisan Google Googlebot will soon speak HTTP/2). Situs menjadi memenuhi syarat dengan menyajikan HTTPS serta dukungan HTTP/2 dan telah cukup sering dirayapi sehingga peningkatan itu layak—Anda tidak dapat memaksakannya.
• Anda dapat memilih keluar dengan 421. Google mendokumentasikan pilihan ini di ikhtisar crawler:

“To opt out from crawling over HTTP/2, instruct the server that’s hosting your site to respond with a 421 HTTP status code when Google attempts to access your site over HTTP/2.” (terjemahan) “Untuk memilih keluar dari crawling melalui HTTP/2, instruksikan server yang menghosting situs Anda agar merespons dengan status HTTP 421 ketika Google mencoba mengakses situs Anda melalui HTTP/2.”

• HTTP/3 tidak tercantum dalam dokumentasi crawler Google. Saat ini, dokumen ikhtisar crawler mencantumkan HTTP/1.1 dan HTTP/2 sebagai versi yang didukung, tetapi tidak menyebut HTTP/3—jadi HTTP/3 bukan protokol crawling yang ditawarkan secara terdokumentasi. Ini adalah pernyataan tentang apa yang sudah dan belum dipublikasikan Google, bukan janji bahwa tidak ada permintaan apa pun yang pernah menyentuh HTTP/3. Barry Schwartz melaporkan ketidakhadiran yang sama di Search Engine Roundtable, dan panduan SEJ Will Nye mencatat bahwa Googlebot belum mendukung HTTP/3.

Ada jeda kira-kira lima tahun antara publikasi HTTP/2 (2015) dan dukungan Googlebot terhadapnya (2020). HTTP/3 difinalisasi pada 2022, sehingga mengikuti pola itu, dukungan crawler mungkin masih lama. Menurut penilaian saya, jangan menunggu HTTP/3 untuk crawling, tetapi juga jangan menunda perbaikannya demi Googlebot—alasan mengadopsi HTTP/3 adalah pengguna Anda, bukan Googlebot.

Ada dua hal yang perlu dicatat. Pertama, sekitar Google I/O 2021, John Mueller mengatakan Google sudah merayapi lebih dari separuh seluruh URL melalui HTTP/2, dan multiplexing serta kompresi header telah secara signifikan mengurangi jumlah koneksi dan bandwidth—menguntungkan infrastruktur crawling Google maupun infrastruktur penyajian Anda. Kedua, untuk Bing: saya tidak menemukan pernyataan kebijakan crawling HTTP/2 atau HTTP/3 yang sebanding dan dipublikasikan oleh Microsoft. Bing memiliki banyak materi tentang efisiensi crawling secara umum (IndexNow, Crawl Control, pemrosesan sitemap), tetapi tidak ada deklarasi dukungan protokol yang setara dengan Google—jadi saya tidak akan menyimpulkannya. Jika jawaban khusus Bing penting bagi Anda, periksa Bing Webmaster Blog secara langsung.

Apa yang ditampilkan dan tidak ditampilkan oleh alat Chrome

Lighthouse di Chrome memiliki insight Modern HTTP yang menandai ketika situs disajikan melalui versi HTTP yang lebih lama—pada dasarnya memeriksa apakah file Anda datang melalui HTTP/2 atau HTTP/3. Insight ini berguna, tetapi ada satu hal penting: insight tersebut muncul di trace performa Chrome DevTools, bukan di laporan PageSpeed Insights publik standar yang paling sering diperiksa praktisi SEO. Lighthouse juga dulu memiliki audit khusus uses-http2, tetapi audit itu dinonaktifkan karena mendeteksi h1 vs h2 vs h3 secara andal pada setiap permintaan terbukti sulit. Jadi jangan mencari hasil lulus/gagal “uses HTTP/2” yang aktif di laporan PSI biasa—hasil itu tidak tersedia secara andal. Untuk memastikan protokol yang sebenarnya, periksa kolom Protocol pada panel Network browser atau gunakan alat seperti WebPageTest.

Adopsi di dunia nyata pada 2026

Dataset publik terbaik adalah bab HTTP Web Almanac 2024 (ditulis oleh Robin Marx dari Akamai). Bentuk web saat ini:

• Beranda: HTTP/1.1 sekitar 22% · HTTP/2 sekitar 71% · HTTP/3 sekitar 7% pada desktop (seluler serupa: sekitar 21% / 70% / 9%).
• Semua permintaan digabung: kira-kira 85% menggunakan HTTP/2 atau yang lebih baru; hanya sekitar 15% yang masih memakai HTTP/1.1.
• Lebih banyak situs siap untuk HTTP/3 daripada yang benar-benar memakainya—sekitar 26–28% beranda mengumumkan dukungan HTTP/3 melalui header alt-svc, tetapi jauh lebih sedikit permintaan yang benar-benar disajikan melalui HTTP/3.
• CDN melakukan sebagian besar pekerjaan. Dalam data Almanac, sekitar 96% permintaan yang disajikan CDN menggunakan HTTP/2 atau yang lebih baru, sedangkan kira-kira 29% permintaan non-CDN masih menggunakan HTTP/1.1. Selisih itu merangkum alasan “gunakan CDN” dalam satu statistik.

Ada satu catatan tentang statistik yang sering dikutip. Angka lama bahwa “25% dari 10 juta situs teratas mendukung HTTP/3” mengukur hal yang berbeda dari angka Almanac bahwa “7–9% permintaan aktual disajikan melalui HTTP/3”. Dukungan pada tingkat situs di antara domain besar dan porsi permintaan nyata adalah dua hal berbeda—keduanya dapat benar sekaligus, jadi jangan menganggap salah satunya membantah yang lain.

Cara benar-benar mengaktifkannya

Untuk sebagian besar situs, ini bukan migrasi server—tetapi “aktifkan saja” juga bukan keseluruhan ceritanya karena HTTP/3 harus ditemukan dan dapat diam-diam kembali ke protokol lain:

• Gunakan CDN. Mengaktifkan HTTP/2 dan HTTP/3 pada CDN—Cloudflare, Fastly, Google Cloud CDN, dan lainnya—biasanya cukup dengan mencentang opsi, dan ini jalur yang paling mudah. Setelah itu lakukan verifikasi: periksa protokol yang dinegosiasikan melalui panel Network browser atau dengan curl --http3, bukan menganggap opsi tersebut bekerja dari ujung ke ujung. Konfigurasi TLS/ALPN, dukungan origin-ke-edge, dan dukungan edge-ke-client semuanya harus selaras.
• Sajikan melalui HTTPS. Ini adalah prasyarat praktis untuk kedua protokol; tidak ada browser besar yang menegosiasikan HTTP/2 atau HTTP/3 tanpa enkripsi.
• Pahami cara HTTP/3 ditemukan dan melakukan fallback. Koneksi pertama browser ke situs biasanya masih dinegosiasikan melalui TCP (HTTP/2 atau HTTP/1.1); server atau CDN mengumumkan ketersediaan HTTP/3 melalui header Alt-Svc atau record DNS HTTPS/SVCB, lalu browser menyimpannya dan mencoba QUIC pada koneksi berikutnya. Jika jaringan memblokir UDP atau handshake QUIC gagal, browser otomatis kembali ke HTTP/2 atau HTTP/1.1. Sistem ini bekerja sesuai rancangan, tetapi berarti “origin mendukung HTTP/3” tidak menjamin setiap kunjungan—terutama kunjungan pertama—benar-benar menggunakannya. Ukur pembagian aktual, bukan menganggapnya 100%.
• Perhatikan dukungan perangkat lunak server bila Anda menghosting sendiri. Dukungan web server untuk HTTP/3 secara historis tertinggal (teknologinya bergerak cepat, jadi periksa status stack Anda saat ini sebelum menganggapnya tersedia). Itulah alasan jalur CDN menjadi pilihan pragmatis.

Yang tidak perlu dilakukan: Server Push

Jika seseorang menyarankan penerapan HTTP/2 Server Push, jawabannya adalah tidak—fitur itu sudah mati di browser yang relevan, meskipun masih didefinisikan secara teknis dalam spesifikasi HTTP/2 dan HTTP/3. Tim Chrome mendokumentasikan penghapusannya dalam Removing HTTP/2 Server Push (Barry Pollard). Poin utamanya:

“support of HTTP/2 Server Push will be disabled by default in Chrome 106 and other Chromium-based browsers.” (terjemahan) “dukungan HTTP/2 Server Push akan dinonaktifkan secara bawaan di Chrome 106 dan browser berbasis Chromium lainnya.”

Adopsinya sudah merosot—Pollard mencatat penggunaan di antara situs HTTP/2 “dropped to 0.7%” (terjemahan) “turun menjadi 0,7%”—dan, yang terpenting, alasan performanya tidak pernah terbukti: tulisan tersebut menjelaskan bahwa Push menghasilkan performa “without a clear net performance gain and in many cases performance regressions.” (terjemahan) “tanpa peningkatan performa bersih yang jelas dan dalam banyak kasus justru menimbulkan regresi performa.” Ini adalah penghapusan yang didokumentasikan oleh Chrome/Chromium secara khusus; mesin browser lain bergerak ke arah yang sama dalam praktik, tetapi anggap “Push sudah hilang di mana-mana” sebagai realitas praktis untuk perancangan, bukan klaim tentang kode sumber setiap mesin.

Pengganti yang didokumentasikan:

“103 Early Hints is a much less error-prone alternative with many of the same upsides as Push, and a lot less of the downsides” (terjemahan) “103 Early Hints adalah alternatif yang jauh lebih kecil kemungkinannya menimbulkan kesalahan, dengan banyak kelebihan Push dan jauh lebih sedikit kekurangannya.”

ditambah <link rel=preload> standar untuk resource yang Anda tahu akan diperlukan. Keduanya juga dibahas dalam resource hints. Intinya: jangan merancang sistem berdasarkan Server Push pada 2026.

Catatan keamanan (satu paragraf yang jujur)

Kekuatan utama HTTP/2 juga sempat menjadi kelemahan. Pada 2023, multiplexing yang membuat HTTP/2 cepat menjadi mekanisme di balik teknik DDoS yang memecahkan rekor, HTTP/2 Rapid Reset (CVE-2023-44487). Seperti dijelaskan para insinyur Cloudflare, kemampuan membuka dan membatalkan banyak stream secara cepat adalah “an obvious vector for denial-of-service,” (terjemahan) “vektor yang jelas untuk serangan denial-of-service”, dan penyedia besar harus memitigasi serangan hingga ratusan juta permintaan per detik. Ini bukan alasan untuk menghindari HTTP/2—server dan CDN modern sudah ditambal—tetapi satu kalimat jujur ini penting agar protokol tidak dijual sebagai keuntungan tanpa sisi lain. Jika menghosting sendiri, selalu perbarui perangkat lunak server.

Posisi topik ini dalam performa web

HTTP/2 dan HTTP/3 adalah tuas pada lapisan transportasi, dan keduanya memengaruhi metrik hilir yang sama dengan bagian lain dari klaster performa web. Pengiriman yang lebih cepat meningkatkan TTFB dan LCP, sehingga pembahasan protokol ini terhubung dengan Core Web Vitals; CDN adalah cara yang biasanya dipakai untuk mengaktifkan protokol ini sekaligus pendorong adopsi terbesar di dunia nyata; caching dan resource hints (termasuk Early Hints dan preload yang menggantikan Server Push) melengkapi cara resource mencapai browser dengan cepat. Perlakukan HTTP/2/HTTP/3 sebagai salah satu bagian dari lapisan pengiriman—penting untuk pengguna, tetapi bukan tombol peringkat.

Ringkasan AI

Ringkasan singkat versi Advanced:

• HTTP/2 (2015) = multiplexing + kompresi header HPACK + petunjuk prioritas RFC 9218 (pohon prioritas RFC 7540 yang lama telah didepresiasi) melalui satu koneksi TCP. HTTP/3 (2022) = semantik yang sama melalui QUIC/UDP, bukan TCP, sehingga paket yang hilang pada satu stream tidak menahan stream lain—semua stream tetap berbagi kontrol kemacetan koneksi dan state header QPACK. Ini perbaikan nyata untuk head-of-line blocking lintas-stream, bukan kemandirian penuh setiap file.
• Bukan faktor peringkat langsung. Google menyatakan secara eksplisit bahwa crawling melalui HTTP/2 tidak memberikan peningkatan peringkat—ini tuas efisiensi lapisan transportasi, bukan sinyal. Negosiasi protokol yang lebih baru juga tidak menjamin Core Web Vitals atau performa Penelusuran yang lebih baik dengan sendirinya.
• Kebijakan Googlebot yang sebenarnya: HTTP/1.1 secara bawaan, HTTP/2 saat memenuhi syarat (HTTPS + dukungan h2 + volume crawling yang cukup), dan memilih keluar dengan 421. Dokumentasi crawler Google tidak mencantumkan HTTP/3 sebagai protokol yang didukung saat tulisan ini dibuat—ini menyatakan apa yang terdokumentasi, bukan bukti bahwa tidak ada permintaan apa pun yang pernah menyentuhnya.
• Manfaat SEO tidak langsung: pemuatan lebih cepat bagi pengguna nyata → Core Web Vitals → pengalaman halaman. HTTP/3 paling membantu koneksi lambat atau banyak kehilangan paket.
• Manfaat lain QUIC bersifat kondisional, bukan otomatis: resumption 0-RTT mengirim “early data” yang sensitif terhadap replay dan dapat ditolak (425 Too Early), sedangkan connection migration (bertahan saat berpindah WiFi → seluler) diprakarsai client dan divalidasi jalurnya pada QUIC v1, bukan kesinambungan yang terjamin.
• Adopsi (Web Almanac 2024): sekitar 85% semua permintaan memakai HTTP/2+; HTTP/3 masih minoritas (sekitar 7–9% permintaan), walaupun lebih banyak situs mengumumkan dukungan (sekitar 26–28%). Permintaan CDN sekitar 96% menggunakan HTTP/2+.
• Aktifkan melalui pengaturan CDN (Cloudflare, Fastly, Google Cloud CDN), lalu verifikasi protokol yang dinegosiasikan—HTTP/3 ditemukan melalui record Alt-Svc/DNS dan kembali ke HTTP/2 atau HTTP/1.1 jika UDP diblokir, sehingga “didukung” tidak sama dengan “digunakan pada setiap kunjungan”. HTTPS adalah prasyarat kedua protokol.
• Server Push mati dalam praktik—Chrome menonaktifkannya secara bawaan mulai v106 (fiturnya masih ada di spesifikasi, hanya tidak diimplementasikan secara bawaan), adopsi turun menjadi sekitar 0,7% situs HTTP/2, dan fitur ini sering menyebabkan regresi performa. Gunakan 103 Early Hints atau <link rel=preload>.
• Catatan keamanan: multiplexing HTTP/2 menjadi mekanisme di balik DDoS Rapid Reset pada 2023 (CVE-2023-44487)—sudah ditambal, tetapi perangkat lunak server tetap harus diperbarui.
• Tidak ditemukan kebijakan crawling HTTP/2/HTTP/3 khusus Bing—jangan membuat kesimpulan sendiri.

Dokumentasi resmi

Dokumentasi dari sumber utama mesin pencari dan vendor browser.

Google

• Overview of Google crawlers and fetchers — pernyataan otoritatif saat ini bahwa Googlebot mendukung HTTP/1.1 dan HTTP/2 (HTTP/1.1 sebagai bawaan, tidak ada peningkatan peringkat dari HTTP/2), serta pilihan keluar dengan 421. Tidak ada penyebutan HTTP/3.
• Googlebot will soon speak HTTP/2 (September 2020) — pengumuman bahwa crawling HTTP/2 akan dimulai pada pertengahan November 2020, syarat kelayakan, dan pilihan keluar.

Chrome / web.dev

• Removing HTTP/2 Server Push from Chrome (Barry Pollard) — waktu penghapusan, alasan adopsi dan performa, serta pengganti yang disarankan (103 Early Hints, rel=preload).

Bing / Microsoft

• Tidak ditemukan pernyataan kebijakan crawling HTTP/2 atau HTTP/3 yang sebanding dalam riset ini. Untuk panduan umum tentang efisiensi crawling Bing, lihat Bing Webmaster Blog dan IndexNow.

Standar dan data

• RFC 9114 — HTTP/3 dan RFC 9113 — HTTP/2 — spesifikasi protokol saat ini (RFC 9113 menggantikan RFC 7540 dan mendepresiasi skema prioritasnya).
• RFC 9000 — QUIC dan RFC 9001 — Using TLS to Secure QUIC — transportasi QUIC dan integrasi TLS 1.3, termasuk kontrol aliran stream dan connection migration.
• RFC 9218 — Extensible Prioritization Scheme for HTTP — sinyal prioritas urgency/incremental yang berlaku dan bersifat anjuran untuk HTTP/2 dan HTTP/3.
• RFC 8470 — Using Early Data in HTTP — risiko replay 0-RTT dan respons 425 Too Early.
• RFC 7838 — HTTP Alternative Services dan RFC 9460 — Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Records) — cara client menemukan ketersediaan HTTP/3 (Alt-Svc, record DNS).
• Web Almanac 2024 — HTTP chapter (Robin Marx, Akamai) — dataset adopsi dunia nyata publik terbaik.

Kutipan dari sumber

Pernyataan tercatat dari Google dan tim Chrome. Setiap tautan adalah deep link yang langsung menuju bagian yang dikutip pada halaman sumber.

Google — tidak ada peningkatan peringkat dan kebijakan crawling

• “The default protocol version used by Google’s crawlers is HTTP/1.1; crawling over HTTP/2 may save computing resources (for example, CPU, RAM) for your site and Googlebot, but otherwise there’s no Google-product specific benefit to the site (for example, no ranking boost in Google Search).” (terjemahan) “Versi protokol bawaan yang digunakan crawler Google adalah HTTP/1.1; crawling melalui HTTP/2 dapat menghemat sumber daya komputasi seperti CPU dan RAM untuk situs Anda dan Googlebot, tetapi selain itu tidak ada manfaat khusus produk Google bagi situs, misalnya tidak ada peningkatan peringkat di Google Penelusuran.” — Dokumentasi Infrastruktur Crawling Google. Lompat ke kutipan
• “To opt out from crawling over HTTP/2, instruct the server that’s hosting your site to respond with a 421 HTTP status code when Google attempts to access your site over HTTP/2.” (terjemahan) “Untuk memilih keluar dari crawling melalui HTTP/2, instruksikan server host situs agar merespons dengan status HTTP 421 ketika Google mencoba mengakses situs melalui HTTP/2.” Lompat ke kutipan

Tim Chrome (Barry Pollard)—Server Push dihentikan

• “support of HTTP/2 Server Push will be disabled by default in Chrome 106 and other Chromium-based browsers.” (terjemahan) “dukungan HTTP/2 Server Push akan dinonaktifkan secara bawaan di Chrome 106 dan browser berbasis Chromium lainnya.” — Blog Chrome for Developers. Lompat ke kutipan
• Dalam hal adopsi, penggunaan di antara situs HTTP/2 “dropped to 0.7%” (terjemahan) “turun menjadi 0,7%”, dan analisis menunjukkan Push menghasilkan performa “without a clear net performance gain and in many cases performance regressions.” (terjemahan) “tanpa peningkatan performa bersih yang jelas dan dalam banyak kasus mengalami regresi performa.” Lompat ke kutipan
• Pengganti yang disarankan: “103 Early Hints is a much less error-prone alternative with many of the same upsides as Push, and a lot less of the downsides.” (terjemahan) “103 Early Hints adalah alternatif yang jauh lebih kecil kemungkinannya menimbulkan kesalahan, dengan banyak kelebihan Push dan jauh lebih sedikit kekurangannya.” Lompat ke kutipan

Cloudflare (Lucas Pardue dan Julien Desgats)—catatan keamanan

• Kemampuan HTTP/2 untuk menjalankan banyak pekerjaan paralel membuat pembatalan stream secara cepat menjadi “an obvious vector for denial-of-service” (terjemahan) “vektor yang jelas untuk serangan denial-of-service”—dasar serangan Rapid Reset 2023 (CVE-2023-44487). Baca uraian teknis

Haruskah saya melakukan sesuatu tentang HTTP/2 atau HTTP/3?

Panduan singkat untuk pertanyaan “apakah saya perlu bertindak?”

Mulai: Apakah Anda sudah memakai CDN?

• Ya → Anda hampir pasti sudah memiliki HTTP/2, dan kemungkinan HTTP/3 sebagai opsi pengaturan. Pastikan HTTP/2 aktif; aktifkan HTTP/3 jika CDN Anda menyediakannya. Selesai—ini meningkatkan UX/Core Web Vitals, bukan tuas peringkat. Lanjutkan.
• Tidak → Lanjutkan.

Apakah Anda menghosting sendiri dan menyajikan situs melalui HTTPS?

• Belum memakai HTTPS → Perbaiki itu terlebih dahulu. HTTPS adalah prasyarat praktis bagi kedua protokol dan penting karena alasan lain. Setelah itu, evaluasi kembali.
• Memakai HTTPS dan menghosting sendiri → Jalur peningkatan termudah tetap menempatkan CDN di depan daripada mengonfigurasi ulang web server. Jika Anda ingin mengatur server secara langsung, verifikasi dukungan HTTP/2 dan HTTP/3 terbaru dari perangkat lunak server Anda secara terpisah sebelum menganggapnya tersedia.

Apakah tujuan Anda mendapatkan peningkatan peringkat?

• Ya → Sesuaikan ekspektasi. Google menyatakan tidak ada peningkatan peringkat dari HTTP/2, dan dokumentasi crawler Google sama sekali tidak mencantumkan HTTP/3. Manfaatnya adalah kecepatan tidak langsung → Core Web Vitals, dan itu pun tidak dijamin hanya dengan mengganti protokol. Adopsi untuk pengguna dan pengalaman halaman, bukan demi sinyal langsung.

Apakah sebagian besar audiens Anda memakai koneksi lambat atau tidak stabil (dominan seluler, pasar berkembang)?

• Ya → HTTP/3 layak diprioritaskan—isolasi kehilangan paket per-stream QUIC dan connection migration yang diprakarsai client serta bersifat kondisional paling membantu dalam situasi ini.
• Tidak, sebagian besar cepat/stabil → HTTP/2 sudah menangkap sebagian besar manfaat; HTTP/3 memberi peningkatan tambahan yang lebih kecil. Tetap boleh mengaktifkannya melalui CDN, tetapi jangan menjadikannya proyek besar.

Memikirkan HTTP/2 Server Push?

• Berhenti. Chrome menonaktifkannya secara bawaan sejak v106, dan mesin lain dalam praktik mengikuti arah yang sama. Gunakan 103 Early Hints atau <link rel=preload> sebagai gantinya.

Ringkasan cepat HTTP/2 dan HTTP/3

HTTP/1.1 vs HTTP/2 vs HTTP/3 secara sekilas

Apa yang dilakukan Googlebot

Fakta singkat

• Tidak ada peningkatan peringkat dari HTTP/2—Google menyatakannya secara eksplisit. Negosiasi protokol yang lebih baru juga tidak menjamin Core Web Vitals atau performa Penelusuran yang lebih baik dengan sendirinya.
• Manfaat SEO bersifat tidak langsung: kecepatan → Core Web Vitals → pengalaman halaman.
• Adopsi (Web Almanac 2024): sekitar 85% permintaan menggunakan HTTP/2+; HTTP/3 sekitar 7–9% permintaan; sekitar 96% permintaan yang dilayani CDN menggunakan HTTP/2+.
• Cara termudah mengaktifkan: pengaturan CDN—setelah itu verifikasi protokol yang dinegosiasikan; penemuan HTTP/3 (Alt-Svc/DNS) dan fallback UDP berarti “didukung” tidak sama dengan “digunakan pada setiap kunjungan”.
• Server Push: mati dalam praktik (Chrome 106+ menonaktifkannya secara bawaan, dan mesin lain mengikuti arah yang sama), meskipun masih didefinisikan dalam spesifikasi. Gunakan 103 Early Hints atau <link rel=preload>.
• Keamanan: multiplexing HTTP/2 memungkinkan DDoS Rapid Reset pada 2023 (CVE-2023-44487)—sudah ditambal; perbarui server.

Kesalahan dan mitos yang harus dihindari

Mitos: “Beralih ke HTTP/2 atau HTTP/3 akan meningkatkan peringkat saya.” Tidak secara langsung. Google menyatakan tidak ada peningkatan peringkat dari crawling melalui HTTP/2, dan dokumentasi crawler Google tidak mencantumkan HTTP/3. Nilai SEO apa pun bersifat tidak langsung—pemuatan lebih cepat bagi pengguna nyata yang membantu Core Web Vitals—dan itu pun tidak dijamin hanya karena protokol baru berhasil dinegosiasikan. Adopsi untuk pengguna, bukan demi sinyal.

Mitos: “Googlebot merayapi situs saya melalui protokol apa pun yang didukung server/CDN, termasuk HTTP/3.” Menurut dokumentasi Google yang dipublikasikan, tidak demikian. Googlebot merayapi HTTP/1.1 secara bawaan dan HTTP/2 ketika memenuhi syarat; dokumentasi crawler saat ini sama sekali tidak mencantumkan HTTP/3 sebagai protokol yang didukung. CDN Anda dapat menyajikan HTTP/3 kepada pengunjung manusia sementara Googlebot tetap mengambil halaman melalui HTTP/1.1 atau HTTP/2—keduanya dapat benar sekaligus.

Mitos: “Saya harus menerapkan HTTP/2 Server Push agar performa lebih baik.” Dalam praktiknya fitur itu sudah mati—Chrome menonaktifkannya secara bawaan sejak v106, adopsinya turun menjadi sekitar 0,7% situs HTTP/2, dan data pembuatnya sendiri menunjukkan regresi performa yang sering terjadi. Gunakan 103 Early Hints atau <link rel=preload>.

Anti-pattern: Menganggap “satu paket yang hilang hanya menahan satu file” sebagai aturan mutlak. QUIC mengisolasi kehilangan di antara stream HTTP/3—paket yang hilang pada satu stream tidak lagi menahan stream yang tidak terkait seperti pada koneksi TCP bersama HTTP/2. Namun, stream dalam koneksi QUIC yang sama tetap berbagi kontrol kemacetan dan aliran, dan dekode header QPACK berjalan melalui control stream bersama. Jalur jaringan yang buruk masih memperlambat seluruh halaman; QUIC hanya mencegah satu paket yang hilang merambat ke setiap stream lain.

Anti-pattern: Menganggap 0-RTT dan connection migration selalu berhasil. 0-RTT mengirim “early data” yang sensitif terhadap replay; server dapat menolaknya dan kembali dari sana (425 Too Early). Ini bukan awal tanpa putaran yang terjamin pada setiap kunjungan. Connection migration QUIC v1 diprakarsai client dan memerlukan validasi jalur—server tidak dapat memindahkan koneksi sendiri, dan kesinambungan setelah perubahan jaringan bersifat kondisional, bukan otomatis.

Anti-pattern: Mencoba memaksa Googlebot menggunakan HTTP/2 sesuai permintaan. Anda tidak dapat melakukannya. Kelayakan ditentukan Google berdasarkan heuristik crawling-nya sendiri. Anda hanya dapat membuat situs memenuhi syarat (dukungan HTTPS + HTTP/2); pilihan keluar melalui status 421 didokumentasikan, sedangkan pilihan masuk sesuai permintaan tidak.

Anti-pattern: Menyamakan “25% situs teratas mendukung HTTP/3” dengan “7–9% permintaan memakai HTTP/3”. Keduanya mengukur hal berbeda—dukungan tingkat situs di antara domain besar versus porsi permintaan aktual yang disajikan. Keduanya dapat benar; jangan menyajikan salah satunya seolah-olah membantah yang lain.

Anti-pattern: Berinvestasi terlalu besar pada HTTP/3 untuk audiens dengan koneksi cepat. Manfaat HTTP/3 terkonsentrasi pada koneksi lambat atau banyak kehilangan paket. Jika sebagian besar pengguna berada di jaringan cepat dan stabil, HTTP/2 sudah menangkap sebagian besar manfaat—aktifkan HTTP/3 melalui CDN, tetapi jangan memperlakukannya sebagai proyek besar.

Anti-pattern: Mencari hasil “uses HTTP/2” di PageSpeed Insights standar. Audit Lighthouse lama itu sudah dinonaktifkan, dan insight “Modern HTTP” saat ini berada di trace Chrome DevTools, bukan laporan PSI publik. Konfirmasikan protokol melalui panel Network browser atau alat seperti WebPageTest.

Checklist HTTP/2 dan HTTP/3

Pemeriksaan singkat untuk memastikan manfaat pengiriman benar-benar didapat tanpa mengejar mitos:

• Situs disajikan melalui HTTPS (prasyarat kedua protokol).
• HTTP/2 dipastikan aktif—periksa kolom Protocol di panel Network browser atau alat seperti WebPageTest (bukan laporan PSI standar).
• HTTP/3 diaktifkan jika CDN Anda mendukungnya (manfaat lebih besar bagi audiens lambat/seluler)—dan pastikan benar-benar dinegosiasikan, bukan hanya diaktifkan (periksa curl --http3 atau panel Network; jaringan yang memblokir UDP akan fallback otomatis).
• Anda mengandalkan pengaturan CDN, bukan migrasi server dari nol, kecuali ada alasan khusus untuk mengonfigurasinya sendiri.
• Jika menghosting sendiri, dukungan HTTP/2/HTTP/3 dari perangkat lunak server sudah diverifikasi dan masih aktual.
• Tidak ada implementasi HTTP/2 Server Push—ganti dengan 103 Early Hints atau <link rel=preload> bila berguna.
• Ekspektasi internal jelas: ini peningkatan UX/Core Web Vitals, bukan tuas peringkat langsung.
• Jika suatu saat perlu membuat Googlebot berhenti memakai HTTP/2, Anda mengetahui mekanismenya (kode status 421)—kebanyakan situs tidak memerlukannya.
• Server/CDN sudah ditambal terhadap HTTP/2 Rapid Reset (CVE-2023-44487).

Sumber yang layak dibaca

Tulisan terkait

• The Beginner’s Guide to Technical SEO — tempat memahami posisi kecepatan dan pengiriman situs dalam gambaran SEO teknis yang lebih besar.
• Core Web Vitals: A Complete Guide — metrik yang benar-benar mengubah pengiriman lebih cepat menjadi sinyal yang berdekatan dengan peringkat (manfaat tidak langsung HTTP/2 dan HTTP/3).

Presentasi saya

• How Search Works (SlideShare) — penjelasan saya tentang crawling, rendering, indexing, dan ranking, termasuk cara Googlebot mengambil halaman. (Penafian tetap saya berlaku: “Ini adalah pemahaman saya tentang sistem… tidak akan pernah 100% lengkap atau akurat.”)

Resmi

• Google — Overview of Google crawlers and fetchers — pernyataan “tidak ada peningkatan peringkat”, HTTP/1.1 sebagai bawaan, dan pilihan keluar 421.
• Google — Googlebot will soon speak HTTP/2 (September 2020).
• Chrome — Removing HTTP/2 Server Push (Barry Pollard).

Dari industri

• Web Almanac 2024 — HTTP chapter (Robin Marx, Akamai; ditinjau Barry Pollard dan Chris Böttger) — dataset adopsi dunia nyata: HTTP/2 dominan, HTTP/3 masih minoritas, dan pengaruh CDN sangat jelas.
• How HTTP/3 Helps Feed SEO’s Need For Speed (Search Engine Journal, Will Nye, Builtvisible) — penjelasan praktis tentang manfaat Core Web Vitals yang tidak langsung dan alasan manfaat HTTP/3 paling besar pada koneksi lambat.
• Google: Googlebot Not Crawling Over HTTP/3 Yet (Search Engine Roundtable, Barry Schwartz) — menguatkan bahwa HTTP/3 belum tercantum sebagai protokol crawling Googlebot.
• Google: We’re Crawling Half Of The URLs Over HTTP/2 (Search Engine Roundtable, Barry Schwartz) — statistik crawling HTTP/2 John Mueller dari Google I/O.
• HTTP/2 Rapid Reset: deconstructing the record-breaking attack (Cloudflare, Lucas Pardue dan Julien Desgats) — catatan keamanan dan uraian teknis CVE-2023-44487.
• High Performance Browser Networking (Ilya Grigorik, O’Reilly) — referensi gratis dan mendalam tentang HTTP/2, QUIC, dan jaringan yang mendasarinya.

Periksa versi HTTP yang dinegosiasikan

Gunakan flag curl khusus versi untuk menguji apakah endpoint dapat menegosiasikan setiap protokol. Dukungan protokol pada build curl lokal Anda dapat berbeda.

curl -sS -o /dev/null -w 'HTTP/%{http_version}\n' --http2 https://example.com/
curl -sS -o /dev/null -w 'HTTP/%{http_version}\n' --http3 https://example.com/

Periksa protokol resource di browser

Tempelkan kode ini ke Console DevTools setelah halaman dimuat untuk melihat protokol yang tercatat pada setiap permintaan.

console.table(
  performance.getEntriesByType('resource').map((entry) => ({
    resource: entry.name,
    protocol: entry.nextHopProtocol,
    duration: Math.round(entry.duration),
  }))
);

Hasil HTTP/3 membuktikan pengiriman ke browser, bukan crawling oleh Googlebot. Panduan artikel tentang Googlebot tetap terpisah.

Uji diri: HTTP/2 dan HTTP/3

Lima pertanyaan singkat tentang protokol dan artinya bagi SEO. Pilih satu jawaban untuk setiap pertanyaan, lalu periksa hasilnya.

Log perubahan