Halaman 14kB Bisa Dimuat Jauh Lebih Cepat daripada Halaman 15kB (2022)

• Menjaga ukuran situs web di bawah 14kB dapat mempercepat waktu muat secara signifikan dibandingkan 15kB
• Fenomena ini terjadi karena algoritme TCP slow start, yang membatasi jumlah data awal yang dikirim sehingga menimbulkan perbedaan kecepatan yang terasa
• 14kB kira-kira setara dengan kapasitas 10 paket TCP yang biasanya dikirim server pada awal koneksi
• Di lingkungan berlatensi tinggi seperti internet satelit, satu tambahan round trip (RTT) dapat menyebabkan penundaan lebih dari 612ms
• Dalam praktiknya, menaruh konten utama di bawah 14kB, atau menempatkan resource penting dalam 14kB pertama, efektif untuk optimasi performa web

---

Gambaran umum dan prinsip utama

• Bahwa ukuran situs web yang lebih kecil akan dimuat lebih cepat adalah fakta yang sudah dikenal luas
• Namun, saat melewati batas dari 14kB ke 15kB, bisa muncul perbedaan besar pada kecepatan respons awal, sesuatu yang tidak selalu diduga
• Perbedaan kecepatan antara halaman 15kB dan 16kB kecil, tetapi antara 14kB dan 15kB bisa mencapai 612ms

Apa itu TCP

• Transmission Control Protocol (TCP) berjalan di atas IP (Internet Protocol) dan bertugas menjamin keandalan paket
• Browser web mengirim beberapa paket TCP saat melakukan permintaan HTTP
• Jika hanya memakai IP, tidak ada cara untuk memastikan apakah paket sudah sampai, sehingga TCP menyediakan fungsi acknowledgement paket (ACK)
• Server mula-mula mengirim sejumlah kecil paket, lalu setelah menerima ACK dari browser, server mengirim paket tambahan
• Jika tidak ada ACK, prosedur pengiriman ulang paket akan dijalankan

Apa itu TCP slow start

• TCP slow start adalah algoritme di mana server secara bertahap menaikkan jumlah paket yang dikirim untuk mengetahui kualitas koneksi jaringan (bandwidth)
• Pada awal koneksi, server hanya mengirim sedikit paket, umumnya 10 paket
• Jika komputer pengunjung mengirim ACK dengan normal, jumlah paket yang dikirim akan ditingkatkan menjadi dua kali lipat
• Jika terjadi ACK yang hilang, setelah itu paket akan dikirim dengan kecepatan lebih lambat
• Implementasi nyata bisa berbeda dalam detail, tetapi konsepnya tetap sama

Dasar batas 14kB

• Kebanyakan server dalam slow start mengirim 10 paket TCP sekaligus
• Ukuran maksimum paket TCP adalah 1500 byte, tetapi setelah dikurangi header (40 byte), data efektifnya menjadi 1460 byte
• Karena itu, 10 x 1460 = 14600 byte (sekitar 14kB) adalah batas maksimum pengiriman pertama
• Jika situs web atau resource penting dijaga di bawah 14kB (atau puluhan kB data asli bila memakai kompresi), konten bisa tampil tanpa penundaan round trip tambahan di awal

Seberapa besar penundaan yang disebabkan satu round trip

Contoh internet satelit

• Contoh khas lingkungan berlatensi tinggi adalah pengguna internet satelit (kapal pengeboran minyak, kapal pesiar, dan sebagainya)
• Saat ponsel meminta halaman depan, perjalanan router → antena satelit → satelit di luar angkasa → stasiun bumi → server membutuhkan puluhan hingga ratusan ms di tiap segmen
• Satu round trip transmisi penuh mencakup dua kali perjalanan ke luar angkasa, perpindahan antar-segmen jaringan, hingga pemrosesan server, sehingga menambah latensi sekitar 612ms
• Jika memakai HTTPS, hal ini bisa meningkat hingga 1836ms karena handshake tambahan

Latensi di jaringan darat

• Di jaringan seluler seperti 2G dan 3G, latensi 100~1000ms juga bisa terjadi
• Dalam kondisi padat, server kelebihan beban, atau ada packet loss, penundaan tambahan dapat muncul

Strategi optimasi situs web dengan aturan 14kB

• Intinya adalah membuat situs web atau halaman sekecil mungkin
• Idealnya, setiap halaman dirancang agar ukuran transfer terkompresinya tidak melebihi 14kB
  • Dengan kompresi, konten sebenarnya bisa mencapai ~50kB
• Dengan mengurangi sebagian besar elemen yang tidak perlu seperti video autoplay, pop-up, tracker, serta JS/CSS yang tidak diperlukan, target ini cukup realistis
• Jika sulit membuat keseluruhan halaman muat dalam 14kB, hal terpenting adalah menaruh resource inti dan konten utama dalam 14kB pertama (CSS, JS, teks utama, dan sebagainya)
• Header HTTP (tidak bisa dikompresi) dan gambar juga termasuk dalam batas 14kB itu (jadi sebaiknya hanya memuat yang benar-benar perlu, bagian yang tampak, atau memakai placeholder)

Pengecualian aturan 14kB dan isu protokol modern

• Aturan 14kB bukan penyederhanaan yang berlebihan, tetapi ada beberapa pengecualian
  • Beberapa server memperluas initial window menjadi 30 paket
  • TLS handshake dapat memungkinkan jendela yang lebih besar
  • Jumlah paket yang bisa dikirim per rute dapat di-cache sehingga pada koneksi berikutnya server bisa mengirim lebih banyak
• Bahkan di HTTP/2, praktik server memulai dari 10 paket karena TCP slow start secara umum tidak banyak berubah
• Di HTTP/3 dan QUIC pun, aturan 14kB tetap direkomendasikan secara resmi

Ringkasan dan materi rujukan

• Dasar teknis dan materi penjelasan tambahan dapat dilihat melalui tautan-tautan terkait
• Pertama diterbitkan: 2022-08-25, terakhir diperbarui: 2022-08-26, penulis: Nathaniel, tag terkait: performa web, HTTP, TCP

Tautan referensi

• Struktur frame Ethernet dan header TCP, materi tambahan tentang latensi dan bandwidth, spesifikasi TCP/QUIC, dan lain-lain

[GN⁺]

Komentar Hacker News

• Pengembang perangkat lunak perlu memberi perhatian lebih pada lapisan media, terutama poin penulis tentang keandalan dan latensi 3G/5G yang sangat berkesan. Radio hampir selalu mengalami retransmisi, dan pada sebagian besar komunikasi HTTP paket harus tiba berurutan agar UI bisa diperbarui. Bahkan satu permintaan REST pun sebenarnya hanya menjadi satu paket jika permintaan dan responsnya masing-masing di bawah 1400 byte. Jika lebih besar dari itu, permintaan 'tunggal' tersebut sebenarnya terpecah menjadi beberapa paket. Jika salah satu di antaranya bermasalah, semua paket tetap harus tiba berurutan agar layar bisa diperbarui dengan benar. Jika ingin bereksperimen, aktifkan mode 3G dan packet loss di Chrome DevTools lalu uji; Anda akan melihat bahwa hanya dengan satu optimasi kecil saja responsivitas UI bisa meningkat drastis. Karena itu, ada alasan yang kuat untuk membuat API dan UI sekecil mungkin

• Ukuran transfer homepage saya 7.0kB dalam keadaan terkompresi

  • /
  • main.css
  • favicon.png
  • total 7.0kB Daftar blog dan seluruh situs dibuat dengan static site generator kustom saya sendiri (terbuka: site.lisp, memakai Common Lisp). Untuk posting terkait matematika saya memakai KaTeX dengan client-side rendering, dan dalam kasus ini ada tambahan sebesar 347.5kB
  • katex.min.css 23.6kB
  • katex.min.js 277.0kB
  • auto-render.min.js 3.7kB
  • KaTeX_Main-Regular.woff2 26.5kB
  • KaTeX_Main-Italic.woff2 16.7kB
  • total tambahan 347.5kB Saya sedang mempertimbangkan apakah suatu hari harus mengubah KaTeX ke server-side rendering. Blog ini adalah proyek gairah pribadi yang saya kerjakan sejak masa tinggal di asrama kampus. Semua HTML, template, sampai CSS saya tulis sendiri, dan saya selalu menyusunnya dengan hati-hati agar hanya elemen yang benar-benar perlu saja yang ada di tiap halaman, sehingga ukurannya tetap kecil
  • Homepage saya
  • Kumpulan posting matematika
    • Bukan berarti harus memaksakan cara yang lebih baik, tetapi latensi yang muncul dari client-side rendering saat komponen dinamis seperti ekspresi LaTeX dimuat hampir tidak pernah (atau benar-benar tidak) terasa bagi pengguna biasa. Over-optimization juga masalah. Seluruh pengejaran performa berbasis SEO ini tidak banyak memberi hasil sebanding dengan waktu yang dikeluarkan kecuali layanannya punya trafik jutaan view. Ini seperti mengkhawatirkan aerodinamika saat mengarahkan kapal tanpa awak di laut dengan bantuan pasang surut. Jika sumber daya terbatas, dengan mempertimbangkan total biaya dan manfaat, optimasi tidak selalu menjadi pilihan terbaik
    • Jika konten matematikanya sedikit tetapi tetap ingin memakai KaTeX, bisa juga mempertimbangkan MathML(mathml-core) sebagai alternatif
    • Saya tidak paham kenapa rumus matematika atau ekspresi LaTeX harus dirender dengan js di klien. Kenapa tidak dikonversi dulu ke HTML/CSS lalu dimasukkan dalam keadaan sudah dirender sebelumnya?
    • Pustaka berat juga bisa dimuat setelah render halaman awal, atau memuat grafik rumus sebagai SVG hanya saat muncul di viewport. Sekadar pendapat saya

• Target 14kB memang cukup menantang, tetapi gagasan membatasinya dalam 10 paket awal juga menarik. Ada proyek seperti 512kb.club yang fokus pada ukuran situs seperti saya. Itu tempat membandingkan ukuran situs seperti skor golf. Situs saya(anderegg.ca) sebelum didaftarkan total semua resource-nya 71kB. Berkat proyek ini saya juga jadi tahu Cloudflare Radar, yang punya alat bagus untuk analisis situs dan pengukuran ukuran halaman. Tujuan utamanya memang dashboard internet secara keseluruhan, tapi di dalamnya juga ada alat analisis ukuran halaman

  • Dari sudut pandang pengguna saya ingin bertanya, 500kB sisanya dipakai untuk apa? Saya hanya butuh 90% teks, dan sisanya pun cukup kalau berupa grafik vektor. Dengan 14 kB saja teks dan grafik sudah bisa cukup banyak, jadi 500 sisanya dipakai buat apa?
  • 512kb adalah standar yang realistis. Saya juga menerapkan standar ini ke situs saya. Situs web level 14kb sudah melampaui standar web itu sendiri
  • Kalau situs pribadi, 512kb sangat mungkin dicapai. Target saya berikutnya 99kb (di bawah 100kb). Cukup realistis kalau meluangkan beberapa akhir pekan. Situs saya berada di peringkat Orange pada 512kb

• Jika ingin bereksperimen dengan cara yang lebih seru, ukuran initial window (IW) bisa diatur dari sisi server. Misalnya bisa disesuaikan seperti di bawah ini

  • ip route change default via <gw> dev <if> initcwnd 20 initrwnd 20 Kalau dicari, sekarang ada juga kasus CDN memberi initial window sampai 30 paket (45kb)
  • Tiga belas tahun lalu, 10 paket saja dianggap sebagai 'cheating'. Lihat di sini dan blog Ben Strong (arsip)
  • Saya penasaran apakah ada referensi yang mendukung klaim bahwa initial window CDN adalah 30 paket
  • Atau cukup atur saja jadi 1000 paket seperti 'warga yang buruk'... cuma kekurangannya, seseorang di koneksi dial-up atau koneksi dengan bufferbloat bisa mengalami bottleneck

• Hal yang dijelaskan dalam tulisan berikut juga berlaku: Blog Cloudflare - ISP Rusia hanya mengizinkan sampai 16KB sehingga sebagian besar penelusuran web menjadi mustahil. Menurut analisis Cloudflare, ISP Rusia membatasi internet pengguna domestik mereka lewat throttling sehingga hanya 16KB pertama per aset web yang bisa dimuat

• Irisan antara orang yang tidak tahu apa itu TCP Slow Start dan orang yang cukup peduli untuk memikirkan penundaan pemuatan situs sampai tingkat sangat detail itu sangat kecil. Startup seharusnya fokus menjadi startup dulu, dan hanya perusahaan besar yang punya keleluasaan untuk terobsesi dengan optimasi semacam ini

  • Kalau pendekatannya seperti, "kami fokus pada hal yang penting dulu jadi tak ada waktu memikirkan optimasi performa", maka pada akhirnya Anda tidak akan pernah memikirkannya. Itulah sebabnya kebanyakan aplikasi dan situs sekarang lambat dan buruk
  • Kalau itu benar, maka perangkat lunak dari tempat seperti Microsoft seharusnya selalu berjalan dengan efisiensi terbaik dan sempurna
  • Secara konsep itu terdengar benar. Tapi kalau Evan Wallace dari Figma tidak terobsesi pada performa, Figma tidak akan menjadi seperti sekarang. Kadang 'performa' itu sendiri justru merupakan fitur utama produk
  • Ini bukan soal pilihan, bisa juga dibuat agar ikut terbawa sebagai default. Saya memakai datastar untuk demo 1 miliar sel dan [1] checkbox, dan semuanya hanya sedikit di atas 10kb. Di jaringan mobile dan 3G bedanya besar. Dari eksperimen saya, jika melewati 14kb maka di koneksi berkualitas rendah butuh 3 detik lebih lama. Berkat maintainer datastar yang bahkan memikirkan TCP slow start, saya malah ikut mendapat manfaat tanpa perlu banyak usaha
    • checkboxes.andersmurphy.com
  • Saya rasa ukuran perusahaan tidak banyak berkaitan dengan optimasi performa. Justru perusahaan besar sering kali lebih lambat

• Homepage saya 17.2KB! (di luar dependensi) Ini halaman pribadi, dan saya benar-benar serius mengoptimalkannya sampai berhasil mendapat nilai penuh 100 di Lighthouse. Dulu saya kira mustahil, tapi ternyata berhasil. Sebagai catatan, ini dibuat dengan Rails. Optimasi seperti ini benar-benar layak dilakukan. Pengalaman halaman yang muncul secepat kilat tanpa terasa tidak responsif itu sendiri sangat memuaskan

  • Mengalami news.ycombinator.com dimuat seketika terasa sangat nyaman secara psikologis, sampai-sampai saya otomatis membukanya setiap kali ada waktu luang
  • Saya sangat mengoptimalkan kode template untuk ribuan situs sampai mendapat skor Lighthouse 100/100/100/100. Mobile juga 100 sempurna. Initial load saya jauh lebih besar dari 17.2kB, sekitar 120kB, tetapi rahasianya adalah menghilangkan semua permintaan HTTP yang tidak perlu, hanya menjalankan JS untuk area "above-the-fold", sisanya memakai lazy eval, defer, dan penundaan muat semaksimal mungkin. JS/CSS di-inline, widget pihak ketiga juga memakai pendekatan 'facade' seperti ikon popup sehingga permintaan sebenarnya ditunda. Backend SSR juga sangat membantu. Bahkan dengan video latar Vimeo nilainya tetap 100, tetapi dengan Youtube tidak mungkin. Cara mendapatkan skor sempurna adalah dengan menafsirkan hasil Lighthouse lalu menulis ulang codebase itu sendiri sepenuhnya. Hasilnya, keluhan klien terkait kecepatan benar-benar hilang, sehingga menjadi keunggulan besar baik dari sisi SEO maupun skor aktual itu sendiri
  • Rails tidak berhubungan langsung dengan optimasi rendering. Selamat atas skor Lighthouse yang sempurna

• Saya rasa tulisan ini punya dua kelemahan logis

  1. Ada rumus yang mengatakan pada komunikasi satelit butuh sekitar 1600ms untuk mengirim satu paket, tetapi itu lemah sebagai dasar aturan 14kb. Karena tidak ada perbandingan dengan situs web besar, itu tidak berhasil menunjukkan bahwa 10 paket ≠ 16 detik
  2. Disebutkan bahwa gambar halaman web juga masuk dalam aturan 14kb, tetapi seberapa sering gambar di-inline pada pemuatan awal? Dalam praktiknya itu kasus pengecualian yang sangat jarang, jadi perlu ditegaskan lebih jelas bahwa ini tidak berlaku untuk 99.9% kasus - Soal "<i>kasus gambar di-inline?</i>", contohnya ada teknik untuk thumbnail resolusi rendah yang hanya muncul di layar awal, ditambah CSS blur, lalu gambar asli di-fade in secara asinkron belakangan. Jika dilakukan dengan benar, tambahan konsumsi hanya sekitar 1~200 byte. Saya menerapkannya di blog saya, dan ini juga banyak dipakai di platform seperti Wordpress dan Medium. Ini terutama trik untuk hyper-optimization frontend komersial - Saya juga tidak setuju dengan asumsi bahwa kebanyakan pengguna memakai koneksi satelit berlatensi rendah, dan juga dengan premis bahwa di dunia di mana semua situs web berukuran beberapa MB, hanya halaman saya yang tidak akan tahan

• Generasi sekarang cenderung membuat bahkan situs web statis sederhana dengan framework seperti Next.js. Rasanya agak disayangkan bahwa era HTML+CSS+js kini memudar

  • Setuju. Saya juga pernah melakukan semuanya: sumber daya minimal, optimasi JavaScript manual, situs dengan aturan 14kb. Namun pendekatan ini berujung pada batasan desain dan arsitektur. Saat fitur bertambah, semua keputusan 'meminimalkan' pada masa itu berubah menjadi utang teknis. Kebanyakan orang terpesona oleh fantasi 'web murni tanpa framework', lalu pada titik tertentu sadar bahwa itu justru lebih menyiksa. Tapi jika memakai framework JS isomorfik, Anda bisa mulai dari halaman statis, melakukan optimasi secukupnya, lalu beralih ke thick client JS jika memang perlu
  • Sebenarnya tren sudah bergerak kembali. Kebanyakan framework sekarang juga mendukung situs statis dengan baik. Yang seperti Astro bahkan lahir memang untuk situs statis
  • Rasanya seperti baru sadar sekarang, padahal sebenarnya sudah begitu sejak sebelum popularitas jQuery meledak pada 2010
  • Next.js mengoptimalkan kode bundle dengan sangat agresif sehingga cocok untuk peluncuran lambda atau server kecil. Situs statis yang dibuat dengan Next juga bisa menghasilkan bundle yang sangat kecil

• Selain latensi, meminimalkan konsumsi sumber daya adalah syarat penting untuk masa depan yang berkelanjutan. Dampak jaringan terhadap lingkungan juga sama sekali tidak kecil. Sayang rasanya nuansa komentar di sini terdengar agak menyindir. Memang optimasi ini bukan solusi pamungkas, tetapi saya berharap pengurangan konsumsi energi lebih ditekankan

  • Sebagian besar trafik internet adalah video streaming. Mengoptimalkan beberapa megabyte pada halaman web hampir tidak terasa dampaknya. Efisiensi sendiri memang layak dibahas, tetapi upaya mengoptimalkan segala bidang bisa justru menghabiskan sumber daya pada area yang sebenarnya lebih membutuhkan optimasi
  • Ini bahkan bukan low-hanging fruit. Selama Anda mengoptimalkan demi menghemat 1~2mWh pada halaman web, satu kueri mesin pencari menghabiskan 100 kali lebih banyak, dan satu interaksi chatbot 10 ribu kali lebih banyak. Caching atau lazy loading sudah banyak meredamnya
  • Terlalu memikirkan pengurangan ukuran halaman hampir sia-sia. Bahkan jika konsumsi listrik tahunan untuk browsing web dinaikkan 10 kali demi berjaga-jaga, itu masih jauh lebih kecil daripada energi untuk membuat satu hamburger. Justru dampak lingkungannya lebih besar jika seorang pengembang selama seminggu makan satu porsi salad alih-alih melakukan optimasi
  • Sangat setuju. Saya pernah pergi ke BBC dan kaget melihat satu artikel teks kecil saja menyimpan 120MB ke cache. Itu mendorong budaya pemborosan energi dan limbah yang tidak perlu. Situs web saya juga saya buat seminimal mungkin, dan saat mengunggah ke YouTube saya hanya memakai 1080P, bukan 4K. 4K dan 8K sebenarnya tidak perlu ada. Orang sering bicara tentang menambah beberapa MW tenaga surya, padahal seharusnya kita membayangkan betapa baiknya kalau kita bisa 'memproduksi lebih sedikit'. Saya rindu skala web kecil era modem 56K; pasti pernah ada titik tengah yang tepat di suatu masa, dan sekarang kita sudah jauh melewatinya
  • Orang biasanya baru peduli ketika dampaknya mulai terasa langsung pada diri mereka. Saya sendiri juga memperhatikan lingkungan. Ada yang membantah bahwa AI lebih buruk, tetapi sebenarnya AI juga merayapi halaman-halaman berat seperti ini. Dan standar 14kb itu bahkan belum sampai 1% dari payload halaman mobile rata-rata saat ini