Firefox Berniat Menghentikan Dukungan HTTP/2 Push

 (groups.google.com)
1 poin oleh GN⁺ 2024-09-08 | 1 komentar | Bagikan ke WhatsApp
  • Firefox akan menonaktifkan HTTP/2 Push di semua platform dalam beberapa hari ke depan karena penggunaannya rendah dan beban kompatibilitas yang makin besar, sementara kode implementasinya akan tetap berada di tree untuk sementara waktu
  • Di ekosistem browser, dukungannya sudah berkurang; Chrome 106 menonaktifkannya pada September 2022, dan versi terbaru Safari juga menolak push stream dalam pengujian lokal
  • Chrome menyebut rendahnya penggunaan HTTP/2 Push sebagai alasan, dan merekomendasikan rel="preload" serta 103 Early Hints sebagai alternatif
  • Firefox selama ini tetap mendukungnya karena biaya pemeliharaannya tidak besar, tetapi dalam beberapa bulan terakhir muncul bug kompatibilitas web yang hanya terjadi di Firefox akibat HTTP/2 Push
  • Jika server dan situs web memakai push tetapi melewatkan pengujian di Firefox, situs tertentu bisa tidak berfungsi hanya di Firefox

Rencana Firefox untuk Menonaktifkan HTTP/2 Push

  • Firefox berencana menonaktifkan HTTP/2 Push di semua platform
  • Pekerjaan penghapusannya dilacak di Bugzilla melalui 1915848 - Pref off HTTP/2 push
  • Untuk saat ini akan dimatikan melalui preference, dan kode implementasinya akan tetap berada di tree untuk sementara waktu
  • Penghapusan penuh kemungkinan besar akan dilakukan sebelum branch ESR 140 pada musim semi tahun depan

Status Dukungan per Browser dan Alasan Penonaktifan

  • Chrome

    • Chrome 106 menonaktifkan HTTP/2 Push pada September 2022
    • Status terkait dapat dilihat di Chrome Platform Status
    • Chrome menyebut rendahnya penggunaan sebagai alasan, dan merekomendasikan rel="preload" serta 103 Early Hints sebagai alternatif

  • Safari

    • Materi deprecation resmi tidak ditemukan, tetapi versi saat ini menolak push stream dalam pengujian lokal menggunakan server Node.js

  • Firefox

    • Firefox selama ini terus mendukung HTTP/2 Push karena beban pemeliharaannya tidak terlalu besar
    • Dalam beberapa bulan terakhir, HTTP/2 Push menyebabkan masalah kompatibilitas web yang hanya berdampak pada Firefox
      • Contoh terkait adalah bug 1915830
      • Jika server dan situs web menggunakan push tetapi tidak mengujinya di Firefox, situs bisa berhenti hanya di Firefox; contohnya adalah bug 1913100

Bacaan terkait

1 komentar

 
GN⁺ 2024-09-08
Komentar Hacker News

  • Menjengkelkan karena bahkan setelah muncul “penemuan mendadak” bahwa HTTP/2 Push memang pada akhirnya tidak berhasil, tetap tidak ada permintaan maaf sama sekali kepada orang-orang yang sejak dulu menjelaskan kenapa ini tidak akan berhasil lalu diabaikan begitu saja
    Selama bertahun-tahun ada suasana bahwa karena orang-orang Google yang lebih pintar menginginkannya, maka fitur itu harus didorong masuk ke spesifikasi, padahal spesifikasi seharusnya didekati dengan jauh lebih konservatif. Sudah saatnya berhenti terus memasukkan target perluasan spekulatif hanya karena sebagian pihak di Google menganggapnya bagus

    • Meningkatkan HTTP dan performa web sendiri tampak tidak terlalu berarti. Kita sudah punya bandwidth yang cukup untuk streaming video 1080p, latensi yang cukup rendah untuk bermain game real-time, dan CPU 1000 kali lebih kuat dibanding saat pertama kali terhubung ke internet
      Yang membuat browser lambat sebagian besar hanyalah iklan, pelacak, dan berbagai sampah yang membebani situs, dan alat yang dipakai untuk memperbaikinya bukan ciptaan Google melainkan uBlock Origin. Hal-hal yang akhir-akhir ini didorong Google ke standar web terlihat bukan untuk pengembang biasa, melainkan untuk memasukkan lebih banyak iklan atau menghemat 0,1% biaya pusat data
    • Dulu kalau mengatakan bahwa untuk penggunaan web non-grafis, misalnya pencarian informasi yang cepat dan non-interaktif, HTTP/1.1 pipelining terasa lebih memuaskan daripada HTTP/2, saya sering mendapat downvote dan balasan menyindir di HN
      HTTP/2 terlihat seperti contoh satu perusahaan yang terus berupaya mengendalikan akses ke sumber daya publik yaitu www agar sesuai dengan kepentingannya sendiri. Jika memakai Chrome, Anda akan mencoba HTTP/2, dan perusahaan yang sama mengendalikan mesin pencari, perangkat keras, browser, dan sekarang bahkan protokol jaringan. HTTP/2 pada dasarnya bisa dianggap HTTP/Chrome
    • Cobalah pahami bahwa mereka benar-benar membutuhkan materi promosi tahunan itu
    • Terlalu cepat benar sama saja dengan salah

  • Penjelasan yang diajukan tentang mengapa HTTP/2 Push gagal tidak pernah terasa meyakinkan. Google biasanya menunjuk ke tulisan Jake Archibald, tetapi tulisan itu tampaknya lebih dekat ke daftar betapa buruknya implementasi browser, alih-alih alasan bahwa protokolnya sendiri memang tidak bisa berjalan
    Browser sudah mendukung preload link, dan itu pada dasarnya seharusnya menjalankan peran yang hampir sama dengan Push header. Soal caching atau header autentikasi, saya juga bertanya-tanya apakah kesulitan implementasi tahun 2017 itu memang tidak bisa memanfaatkan ulang kode penanganan preload yang sudah ada
    https://jakearchibald.com/2017/h2-push-tougher-than-i-though...

    • Sulit mengatakan bahwa header Preload “pada dasarnya sama” dengan HTTP/2 Push. Hasil akhirnya mungkin mirip, tetapi cara kerjanya berbeda, dan selain bagian yang sangat dangkal yaitu sama-sama memakai kata “Preload”, keduanya cukup berbeda
      HTTP/2 Push adalah pendekatan ketika server secara proaktif mendorong resource yang menurutnya dibutuhkan klien untuk menghemat satu kali bolak-balik, dengan tujuan mengurangi latensi dengan mengirim resource terpisah dari pipeline DOM→render. Header Preload adalah cara server memberi tahu resource apa yang harus dimuat secara paralel bersama body agar bisa diambil sebelum parsing atau evaluasi JS. 103 Early Hints mengirim hint Preload sebelum pembuatan respons selesai, bahkan sebelum byte pertama body, sehingga tahap pengambilan bisa dimajukan lebih awal lagi
      Perbedaan kuncinya ada pada apakah itu dipimpin server atau dipimpin klien, dan apakah dikirim bersama body atau sebelum byte pertama. Alasan paling sederhana mengapa HTTP/2 Push lemah dalam mencapai tujuannya adalah cache. Browser tidak meminta resource yang sudah dimilikinya, tetapi server tidak tahu apa yang ada di cache klien. Push berisiko besar mengirim resource yang tidak diperlukan, sementara 103/Preload, kalau pun salah, paling hanya membuang beberapa byte header yang tidak berguna, jadi implementasinya juga lebih mudah dan biayanya lebih rendah
    • Pemahaman saya terhadap spesifikasi Push sudah berkarat seperti spesifikasinya sendiri. Saya lupa bahwa server benar-benar mendorong seluruh konten yang diperkirakan dibutuhkan klien, dan saya keliru mengira bahwa seperti preload link, yang dimasukkan ke permintaan hanyalah header yang mengisyaratkan dependensi
    • Dari sisi keamanan, resource yang didorong harus diperlakukan sebagai kasus khusus sampai halaman benar-benar mengambilnya, dan salah satu konsekuensinya adalah perlunya cache terpisah
    • Alasan penghapusan Push terasa sangat lucu terutama karena pengembang sejak awal nyaris tidak pernah mendapat kesempatan untuk benar-benar memanfaatkannya. Mereka bahkan tidak bisa melihat Push yang masuk, apalagi bereaksi terhadapnya
      https://github.com/whatwg/fetch/issues/51
      Bahkan pada use case pengiriman konten yang paling banyak diperhatikan pun, rasanya masih ada banyak peluang. Upaya yang terlihat secara publik juga tidak banyak, dan hampir tidak ada orang yang punya akses ke library atau titik awal untuk bereksperimen menentukan apa yang seharusnya di-Push

  • Dengan start 0-RTT HTTP/3, sebagian kecepatan bisa dipulihkan, dan dengan 103 Early Hints browser dapat dibuat melakukan preload aset lebih awal. Kombinasi ini juga punya keuntungan karena kompatibel ke belakang secara semantik dengan HTTP/1. Ini juga lebih mudah ditangani pada reverse proxy atau load balancer

  • Agak disayangkan melihat HTTP/2 Push pada akhirnya menghilang. Idenya rapi, tetapi adopsi framework lemah, dan ini adalah fitur yang seandainya mendapat lebih banyak perhatian mungkin akan lebih berhasil
    Pihak .NET pada akhirnya tidak pernah merilisnya, dan nginx punya implementasi dasar. Tidak adanya cache digest juga terus menjadi hambatan. Chrome menghapusnya sebagian dengan alasan semacam “toh tidak ada yang akan sadar”, dan tampaknya mendesain ulang semuanya ke UDP yang selalu bekerja hebat di NAT dianggap lebih penting

    • Saya sendiri belum pernah mengalami masalah dengan UDP dan NAT, tetapi kalau itu membuat orang kesal lalu mendorong migrasi ke IPv6, saya akan diam-diam tertawa

  • Bahkan sebelum HTTP/2 distandardisasi, saat berbicara dengan Mike Belshe, sudah ada kesan bahwa fitur ini sulit merealisasikan manfaatnya dan penuh masalah serta jebakan, sehingga ada dorongan untuk mengeluarkannya dari H2
    Salah satu masalah terbesar adalah Push berlebihan: mengirim hal-hal yang sebenarnya sudah ada di cache browser lokal, atau terlalu banyak konten yang tidak penting. Saya benar-benar pernah melihat kasus sangat buruk di mana Push justru membuat pemuatan halaman lebih lambat. Ada juga usulan agar browser memberi tahu server apa yang ada di cache lokal, tetapi itu terbentur berbagai masalah. HTTP Early Hints dan Resource Hints pada dasarnya sudah menghilangkan kebutuhan akan H2 Push, dan implementasinya jauh lebih mudah, menghindari fetch yang tidak perlu, serta lebih mudah dipahami

  • Ada juga tafsiran seperti, “jika server web dan situs web memakai Push tetapi tidak mengujinya di Firefox, situs bisa macet hanya di Firefox,” tetapi tafsiran lain juga mungkin
    Browser lain menolak HTTP/2 Push dan diam-diam mengabaikannya, sedangkan Firefox mengalami kegagalan besar pada beberapa kondisi batas. Misalnya, ada pernyataan seperti “Firefox tampaknya mereset koneksi saat menemukan huruf besar pada nama header”

    • Tafsiran itu kurang cocok. Browser lain tidak mengimplementasikan spesifikasi, dan Firefox mengimplementasikan spesifikasi. Spesifikasi sangat jelas tentang cara menangani pelanggaran ini, jadi implementasi server web dan situs web seperti itulah yang rusak. Jika mereka menguji dengan klien yang patuh spesifikasi, mereka akan tahu bahwa itu rusak
    • Hal itu dinyatakan dengan jelas dalam tulisan tersebut. Firefox terus mendukung HTTP/2 Push karena biaya dukungannya hingga baru-baru ini tidak besar, tetapi dalam beberapa bulan terakhir muncul bug kompatibilitas web yang hanya memengaruhi Firefox melalui HTTP/2 Push
      Tulisan ini tampaknya menjelaskan langkah untuk menolak H2 Push dan diam-diam mengabaikannya seperti browser lain, jadi tidak terlihat seperti sedang menyembunyikan sesuatu
    • Hal sebaliknya juga bisa saja terjadi. Spesifikasi baru diimplementasikan hanya di satu browser, dan biasanya Chrome yang lebih dulu merilis implementasi yang belum lengkap, lalu server salah mengimplementasikannya sehingga masalah yang sama muncul

  • Saya penasaran mengapa Push tidak diadopsi lebih luas. Terlepas dari cacat besarnya, ini adalah salah satu alasan utama HTTP/2 dianggap sebagai fitur yang bisa mengubah permainan
    Saya tidak tahu apakah penyebabnya kurangnya dukungan browser, atau karena tidak cocok dengan CDN

    • Alasan server Push tidak diterapkan secara luas adalah karena bisa merugikan. Server mendorong aset yang mungkin dibutuhkan klien, tetapi aset itu bisa jadi sudah ada di cache klien
      Dalam kasus kedua, itu menjadi beban yang merugikan, terutama di perangkat seluler. Server tidak pernah bisa tahu dengan tepat apakah aset itu benar-benar dibutuhkan klien. Early Hints mungkin lebih baik; jika server memberi tahu aset yang diperlukan lebih cepat, klien bisa memutuskan apakah perlu mengambilnya atau sudah memilikinya
    • Saya sempat mempertimbangkan untuk memakainya lalu berubah pikiran. Saat permintaan Index.html masuk, biasanya kita ingin mendorong script.js dan style.css, dan itu berarti kita mengirim ratusan kbit
      Jika pengguna meminta index.html lagi, apakah semuanya harus dikirim lagi? Ada kemungkinan besar resource itu sudah ada di cache pengguna. Jika tidak dikirim, bagaimana cara mengetahui apa yang seharusnya dikirim? Hanya browser yang tahu apa yang ada dan tidak ada di cache. Pada akhirnya pilihannya menjadi: kunjungan pertama lebih cepat tetapi kunjungan ulang memboroskan bandwidth, atau kunjungan pertama lebih lambat tetapi kunjungan ulang lebih cepat
    • Mungkin memang ini fitur yang bisa mengubah permainan, tetapi itu berlaku untuk perusahaan seukuran Google/Amazon/Meta atau sedikit lebih kecil
      Bagi kebanyakan yang lain, ini adalah peningkatan kompleksitas yang sangat besar, dan pada praktiknya diabaikan
    • Analisis yang lebih rinci yang dirilis Chrome saat memutuskan menghentikan dukungan Push mungkin bisa membantu
      https://developer.chrome.com/blog/removing-push/
    • Sepertinya waktu yang diberikan tidak cukup. Baru pada 2015, saat RFC HTTP/2 diselesaikan, rilis Apache pertama dengan dukungan HTTP/2 muncul, dan pada 2017 masih ada ketidakkonsistenan antarbrowser dalam cara menangani server Push
      Dukungan Push di nginx tampaknya masuk sekitar 2018 menurut Wikipedia. Perubahan seperti ini butuh waktu untuk turun ke versi distribusi stabil dan konfigurasi bawaan. Saya sendiri baru pertama kali mengaktifkan HTTP/2 di server Apache saya pada 2020, dan bahkan pada 2024 mungkin masih ada server aplikasi yang belum mendukungnya secara langsung

  • … maksudnya di Firefox

    • Sepertinya di tempat lain semuanya sudah lebih dulu dihapus

  • Tampaknya ini tulisan terkait. Ada lagi?
    Removing HTTP/2 Server Push from Chrome - https://news.ycombinator.com/item?id=32522926 - Agustus 2022, 201 komentar
    A Study of HTTP/2’s Server Push Performance Potential - https://news.ycombinator.com/item?id=32097013 - Juli 2022, 2 komentar
    HTTP/2 Push is dead - https://news.ycombinator.com/item?id=25283971 - Desember 2020, 168 komentar
    Blink: Intent to Remove: HTTP/2 and gQUIC server push - https://news.ycombinator.com/item?id=25064855 - November 2020, 133 komentar
    We're considering removing HTTP/2 Server Push support - https://news.ycombinator.com/item?id=24591815 - September 2020, 2 komentar
    Performance Testing HTTP/1.1 vs. HTTP/2 vs. HTTP/2 and Server Push for REST APIs - https://news.ycombinator.com/item?id=21937799 - Januari 2020, 71 komentar
    How HTTP/2 Pushes the Web - https://news.ycombinator.com/item?id=18216495 - Oktober 2018, 16 komentar
    Nginx HTTP/2 server push support - https://news.ycombinator.com/item?id=16365413 - Februari 2018, 63 komentar
    HTTP/2 Server Push on Netlify - https://news.ycombinator.com/item?id=14798271 - Juli 2017, 23 komentar
    The browser bugs and edge cases of HTTP/2 push - https://news.ycombinator.com/item?id=14445728 - Mei 2017, 20 komentar
    A Guide to HTTP/2 Server Push - https://news.ycombinator.com/item?id=14077955 - April 2017, 59 komentar
    HTTP/2 Server Push - https://news.ycombinator.com/item?id=13990074 - Maret 2017, 2 komentar
    HTTP/2 Server Push and ASP.NET MVC – Cache Digest - https://news.ycombinator.com/item?id=13659962 - Februari 2017, 9 komentar
    Accelerating Node.js Applications with HTTP/2 Server Push - https://news.ycombinator.com/item?id=12296922 - Agustus 2016, 6 komentar
    Rules of Thumb for HTTP/2 Push - https://news.ycombinator.com/item?id=12224258 - Agustus 2016, 25 komentar
    Google's Rules of Thumb for HTTP/2 Push - https://news.ycombinator.com/item?id=12223352 - Agustus 2016, 2 komentar
    HTTP/2 Protocol for iOS Push Notifications - https://news.ycombinator.com/item?id=11175980 - Februari 2016, 13 komentar

  • Tidak mengejutkan. Jika Anda menambahkan fitur yang nyaris tidak berkaitan dengan tujuan desain awal di atas protokol yang sudah ada dan dibuat untuk tujuan tertentu, biasanya hasilnya memang seperti ini
    Dalam banyak kasus, lebih baik mulai dari protokol level rendah lalu langsung menyesuaikannya dengan use case, dan dalam hal itu WebSockets sudah menyelesaikan masalah komunikasi dua arah dengan elegan. Untuk mengurangi latensi saat memuat hierarki file/skrip yang dalam, tag rel="preload" atau rel="modulepreload" adalah struktur yang bagus dan sederhana

    • HTTP/2 Push sebenarnya cocok untuk use case yang persis sama dengan preload link guna mengurangi latensi
      Intinya, server mengirimkan konten yang perlu diprefetch lebih dulu lewat header, sehingga bisa dimuat lebih awal bahkan sebelum tag link dikirim atau diparse. Ini mungkin kurang berguna untuk halaman yang mendukung streaming, tetapi saat permintaan tertahan sampai seluruh halaman HTML selesai dirender di sisi server, ini bisa memberi keuntungan yang nyata
    • HTTP/2 adalah protokol level rendah yang baru, dan HTTP Push sejak awal bukan fitur untuk komunikasi dua arah
    • Bukankah HTTP juga komunikasi dua arah?