Mengapa situs Anda sebaiknya mengirim lebih sedikit request, bukan request yang lebih kecil

Mitos nyaman tentang “cukup buat setiap file lebih kecil”

Selama bertahun-tahun, saran performa web terdengar sederhana: kompres semuanya, minify semuanya, buat setiap aset lebih kecil.

Saran itu secara umum masih benar. Skrip 40 KB biasanya lebih baik daripada skrip 400 KB. Gambar yang dioptimalkan lebih baik daripada ekspor mentah. Brotli, AVIF, minifikasi CSS, tree shaking, dan subsetting font semuanya penting.

Namun di banyak situs produksi, masalah yang lebih besar bukan lagi satu file yang terlalu besar. Masalahnya adalah jumlah hal yang harus diminta browser sebelum halaman terasa dapat digunakan.

Sebuah halaman bisa terlihat disiplin dalam ukuran file dan tetap lambat karena mengirim 120 request: fragmen CSS, chunk JavaScript, tag pihak ketiga, file font, tracking pixel, sprite ikon, endpoint JSON, preload, beacon analitik, dan revalidasi cache. Masing-masing mungkin “kecil.” Bersama-sama, semuanya menciptakan waterfall yang panjang dan rapuh.

Aturan praktisnya adalah ini: setelah aset individual sudah dikompresi dengan wajar, mengurangi jumlah request sering kali meningkatkan pengalaman pengguna lebih besar daripada memangkas beberapa kilobyte dari setiap file.

Request bukan hanya byte

Sebuah request jaringan bukan hanya transfer data. Ia adalah rangkaian pekerjaan.

Browser harus menemukan resource, memutuskan kapan mengambilnya, menjadwalkannya terhadap resource lain, mengirim header, menunggu server, menerima header, mengurai respons, sering kali mendekompresinya, lalu melakukan sesuatu yang berguna dengannya.

“Sesuatu yang berguna” itu bisa mahal. File JavaScript harus diurai, dikompilasi, dan dieksekusi. File CSS dapat memblokir rendering. File font dapat menunda teks yang dapat dibaca atau menyebabkan pergeseran layout. Gambar dapat memengaruhi elemen Largest Contentful Paint. Skrip pihak ketiga dapat membawa rantai dependensinya sendiri.

Inilah mengapa jumlah request tetap penting bahkan ketika file berukuran kecil. Skrip 3 KB bisa lebih buruk daripada gambar 30 KB jika ia memblokir rendering, datang terlambat, dan berjalan di main thread pada momen yang salah.

Jika Anda membaca laporan Lighthouse dan merasa dihukum oleh puluhan peringatan terpisah, mulailah dengan melihat waterfall request, bukan skor individual. Kami memiliki panduan praktis di how to read a Lighthouse report without panicking, tetapi versi singkatnya adalah: temukan apa yang memblokir render pertama dan apa yang menunda konten utama.

“Tapi HTTP/2 sudah memperbaiki ini,” sebagian besar tidak

HTTP/2 dan HTTP/3 mengubah ekonomi request. Keduanya memperkenalkan multiplexing, kompresi header, dan perilaku koneksi yang lebih baik. Sederhananya, browser menjadi jauh lebih baik dalam mengirim banyak request melalui lebih sedikit koneksi.

Itu adalah peningkatan nyata. Itu juga mematikan beberapa kebiasaan lama, seperti CSS sprite ekstrem dan bundle gabungan raksasa yang dibuat hanya untuk menghindari batas koneksi.

Namun HTTP/2 tidak membuat request menjadi gratis.

Multiplexing membantu ketika banyak resource berbagi satu koneksi, tetapi browser tetap harus memprioritaskannya. Server tetap harus merespons. Klien tetap harus memproses setiap respons. Kemacetan, packet loss, negosiasi TLS, lookup DNS, cache miss, dan tekanan main-thread tetap ada.

HTTP/3 meningkatkan beberapa perilaku transport, terutama terkait migrasi koneksi dan head-of-line blocking pada lapisan transport. Ia tidak menghapus biaya untuk menemukan, menjadwalkan, mengunduh, mengurai, dan mengeksekusi resource.

Jadi tujuan modernnya bukan “gabungkan semuanya ke dalam satu file sangat besar.” Tujuannya adalah “kirim lebih sedikit request kritis, dan buat request yang tersisa menjadi disengaja.”

Waterfall adalah tempat kebenaran berada

Masalah performa jarang mengumumkan dirinya dalam satu metrik. Masalah itu muncul sebagai bentuk.

Buka panel jaringan browser dan lihat beberapa detik pertama. Tanyakan:

• Berapa banyak request yang dimulai sebelum konten utama muncul?
• Request mana yang memblokir rendering?
• Apakah resource penting ditemukan terlambat?
• Apakah skrip pihak ketiga bersaing dengan CSS, font, atau gambar pihak pertama?
• Apakah banyak file mengembalikan respons 304 alih-alih disajikan langsung dari cache?
• Apakah ikon, font, atau fragmen UI dipecah menjadi lebih banyak file daripada yang dibutuhkan halaman?

Halaman yang cepat biasanya memiliki waterfall awal yang membosankan. Sejumlah kecil resource kritis datang lebih awal. Resource non-kritis menunggu. Skrip pihak ketiga ditunda, dibatasi, atau dihapus. Browser tidak dipaksa mengatur dua puluh prioritas sebelum bisa mengecat halaman.

Halaman yang lambat sering memiliki waterfall yang gelisah: banyak file kecil, banyak origin, dan banyak penemuan yang terlambat.

File yang lebih kecil tetap penting — hanya saja tidak sama pentingnya

Ini bukan argumen melawan kompresi atau optimisasi. Ini adalah argumen melawan optimisasi byte sambil mengabaikan koordinasi.

File yang lebih kecil paling penting ketika resource tersebut besar, memblokir render, atau merupakan bagian dari jalur konten utama. Misalnya:

• Gambar hero harus berukuran dan dienkode dengan benar.
• CSS yang memblokir render harus ramping.
• JavaScript yang dibutuhkan untuk interaksi pertama harus minimal.
• Font harus di-subset, dikompresi, dan dibatasi pada weight yang benar-benar digunakan.

Font adalah contoh umum. Tim sering terobsesi apakah file font berukuran 24 KB atau 31 KB, sementara mengirim enam weight, dua style, dan beberapa family. Perbaikan yang lebih baik bukan memangkas 7 KB dari satu file. Perbaikannya adalah mengirim lebih sedikit file font. Jika tipografi adalah bagian dari pekerjaan performa Anda, web fonts are still one of the easiest wins on most sites.

Gambar mengikuti pola yang sama. AVIF atau WebP dapat menghemat byte yang berarti, tetapi mengirim sepuluh gambar dekoratif di atas fold tetap merupakan rencana yang buruk. Pilih format yang lebih baik, ya, tetapi pertanyakan juga apakah setiap gambar perlu diminta sama sekali. Untuk keputusan format, panduan kami tentang when AVIF beats WebP and when it does not adalah pendamping yang berguna untuk pekerjaan pengurangan jumlah request ini.

Biaya tersembunyi dari banyak file kecil

Banyak request kecil cenderung menciptakan masalah yang tidak terlihat jika Anda hanya melihat total byte yang ditransfer.

1. Penemuan terlambat

Browser tidak dapat meminta apa yang belum ditemukannya. File CSS dapat mereferensikan font. Skrip dapat mengimpor skrip lain. Komponen dapat meminta JSON setelah hydration. Setiap dependensi menciptakan langkah lain dalam rantai.

Semakin dalam rantainya, semakin terlambat pekerjaan penting dimulai.

2. Overhead header

Setiap request dan respons menyertakan header. Kompresi header membantu, terutama melalui HTTP/2 dan HTTP/3, tetapi tidak menghilangkan overhead. Cookie dapat membuat ini jauh lebih buruk. Jika situs Anda mengirim cookie besar dengan setiap request, aset kecil menjadi tidak terlalu kecil dalam praktiknya.

Ini salah satu alasan aset statis sering sebaiknya berada di path atau domain bebas cookie, dan mengapa header cache layak diperhatikan. Jika header berperilaku aneh di produksi, debugging redirects and HTTP headers biasanya lebih cepat daripada menebak.

3. Interupsi main-thread

Banyak chunk JavaScript dapat menciptakan pekerjaan parsing dan eksekusi berulang. Bahkan jika setiap chunk kecil, browser mungkin terus berhenti untuk mengevaluasi kode. Ini dapat merusak Interaction to Next Paint dan membuat halaman terasa tersendat.

Pengguna tidak peduli bahwa setiap file berukuran kecil. Mereka peduli bahwa mengetuk menu memakan waktu 600 milidetik.

4. Kompleksitas cache

Memecah aset dapat meningkatkan caching jika dilakukan dengan hati-hati. Bundle vendor yang stabil dan bundle aplikasi yang berubah dapat menjadi pemisahan yang baik.

Namun chunking berlebihan dapat berbalik merugikan. Lebih banyak file berarti lebih banyak lookup cache, lebih banyak peluang revalidasi, lebih banyak koordinasi versi, dan lebih banyak cara untuk secara tidak sengaja membatalkan resource yang sebenarnya tidak perlu berubah.

Bundling kembali, tetapi dengan pertimbangan

Era pertama performa web menyukai bundling karena browser memiliki batas koneksi yang ketat. Lalu HTTP/2 hadir dan banyak tim bergeser keras ke code splitting agresif. Sebagiannya berguna. Sebagiannya menjadi takhayul.

Titik tengah yang masuk akal adalah bundling yang sadar route.

Untuk situs marketing atau situs konten pada umumnya:

• Inline atau muat hanya CSS yang dibutuhkan untuk rendering awal.
• Jaga JavaScript global tetap kecil.
• Hindari memecah modul kecil menjadi request jaringan terpisah.
• Tunda fitur interaktif yang tidak langsung dibutuhkan.
• Hapus skrip pihak ketiga yang tidak membenarkan biayanya.

Untuk aplikasi:

• Pecah berdasarkan route atau fitur besar, bukan berdasarkan setiap komponen.
• Jaga dependensi bersama tetap stabil dan dapat di-cache.
• Preload hanya resource yang pasti dibutuhkan segera.
• Hindari memuat kode admin, dashboard, editor, atau eksperimen di halaman publik.
• Ukur biaya interaksi, bukan hanya ukuran bundle.

Bundling tidak otomatis baik. Code splitting tidak otomatis baik. Pertanyaan yang berguna adalah: apakah pemisahan ini membantu browser menghadirkan pengalaman pengguna bermakna berikutnya lebih cepat?

Request pihak ketiga layak dicurigai ekstra

Request pihak pertama setidaknya berada di bawah kendali Anda. Request pihak ketiga sering kali lebih lambat, kurang dapat diprediksi, dan lebih mahal daripada kelihatannya.

Satu tag manager dapat memicu analitik, iklan, heatmap, widget chat, A/B testing, alat consent, dan skrip personalisasi. Setiap vendor dapat membawa lebih banyak request. Sebagian akan berjalan lebih awal. Sebagian akan memblokir main thread. Sebagian akan berubah tanpa proses rilis Anda.

Optimisasi pihak ketiga terbaik adalah penghapusan. Yang terbaik kedua adalah penundaan.

Sebelum menambahkan skrip pihak ketiga, tanyakan:

• Apakah ini perlu dimuat sebelum pengguna melihat halaman?
• Apakah ini perlu dimuat di setiap halaman?
• Bisakah ini dimuat setelah consent, interaksi, atau waktu idle?
• Siapa pemiliknya secara internal?
• Metrik apa yang membuktikan bahwa ini sepadan dengan biaya performanya?

Di sinilah performa menjadi tata kelola. Seseorang harus diizinkan untuk berkata tidak.

Checklist praktis untuk mengurangi request

Mulailah dari halaman yang paling penting: homepage, halaman harga, halaman produk, checkout, signup, atau landing page teratas. Lalu telusuri waterfall.

Hapus

• Hapus JavaScript dan CSS yang tidak digunakan.
• Hapus eksperimen lama, pixel yang ditinggalkan, dan analitik duplikat.
• Buang weight font dan library ikon yang tidak digunakan.
• Ganti gambar dekoratif dengan CSS jika sesuai.

Gabungkan dengan bijak

• Bundle modul JavaScript kecil yang selalu dimuat bersama.
• Gabungkan file CSS kecil yang memblokir jalur render yang sama.
• Gunakan SVG sprite atau inline SVG untuk ikon berulang ketika itu mengurangi request tanpa merusak maintainability.

Tunda

• Lazy-load gambar di bawah fold.
• Tunda skrip non-kritis hingga setelah first paint atau interaksi pengguna.
• Muat komentar, embed, peta, chat, dan pemutar video hanya saat dibutuhkan.

Cache dengan benar

• Gunakan caching berumur panjang untuk aset statis berversi.
• Hindari revalidasi yang tidak perlu untuk file yang jarang berubah.
• Jaga HTML tetap segar, tetapi biarkan aset hashed tetap tersimpan di cache.

Ukur ulang

Setelah setiap perubahan, periksa lagi waterfall. Tujuannya bukan skor sempurna. Tujuannya adalah lebih sedikit request kritis, rendering berguna yang lebih awal, dan lebih sedikit gangguan main-thread.

Seperti apa yang baik itu

Halaman yang sehat tidak harus memiliki jumlah request sesedikit mungkin. Ia memiliki jalur kritis yang kecil dan disengaja.

Browser mendapatkan HTML, CSS esensial, gambar konten utama jika ada, mungkin skrip kecil yang dibutuhkan untuk navigasi atau interaksi di atas fold, dan set font minimum yang dibutuhkan agar teks dapat dibaca. Yang lainnya menunggu gilirannya.

Itulah perbedaan antara halaman yang sekadar dioptimalkan dan halaman yang terasa cepat.

Mengecilkan file tetap layak dilakukan. Namun jika situs sudah dikompresi dengan wajar, kemenangan performa berikutnya biasanya bukan menghemat 2 KB lagi dari sebuah bundle. Melainkan satu request pemblokir yang lebih sedikit, satu file font yang lebih sedikit, satu skrip pihak ketiga yang lebih sedikit, satu rantai dependensi yang lebih sedikit.

Lebih sedikit request membuat pekerjaan browser lebih sederhana. Sederhana lebih sering berarti cepat daripada yang ingin kita akui.