Mengapa laman anda patut menghantar lebih sedikit permintaan, bukan yang lebih kecil

Mitos yang selesa tentang “kecilkan sahaja setiap fail”

Selama bertahun-tahun, nasihat prestasi web kedengaran mudah: mampatkan semuanya, minify semuanya, kecilkan setiap aset.

Nasihat itu masih betul secara umum. Skrip 40 KB biasanya lebih baik daripada skrip 400 KB. Imej yang dioptimumkan lebih baik daripada eksport mentah. Brotli, AVIF, minifikasi CSS, tree shaking, dan subset fon semuanya penting.

Tetapi pada banyak laman produksi, masalah yang lebih besar bukan lagi satu fail yang terlalu besar. Masalahnya ialah jumlah perkara yang perlu diminta oleh pelayar sebelum halaman terasa boleh digunakan.

Sebuah halaman boleh kelihatan berdisiplin dari segi saiz fail dan masih perlahan kerana ia menghantar 120 permintaan: serpihan CSS, chunk JavaScript, tag pihak ketiga, fail fon, piksel penjejakan, sprite ikon, endpoint JSON, preload, beacon analitik, dan pengesahan semula cache. Setiap satu mungkin “kecil.” Bersama-sama, semuanya menghasilkan waterfall yang panjang dan rapuh.

Peraturan praktikalnya begini: setelah aset individu dimampatkan dengan munasabah, mengurangkan bilangan permintaan selalunya meningkatkan pengalaman pengguna lebih banyak daripada mengurangkan beberapa kilobait daripada setiap fail.

Permintaan bukan sekadar bait

Permintaan rangkaian bukan sekadar pemindahan data. Ia ialah satu urutan kerja.

Pelayar perlu menemui sumber, memutuskan bila untuk mengambilnya, menjadualkannya berbanding sumber lain, menghantar header, menunggu pelayan, menerima header, menghuraikan respons, sering menyahmampatkannya, dan kemudian melakukan sesuatu yang berguna dengannya.

“Sesuatu yang berguna” itu mungkin mahal. Fail JavaScript perlu dihuraikan, dikompil, dan dilaksanakan. Fail CSS boleh menyekat rendering. Fail fon boleh melambatkan teks yang boleh dibaca atau menyebabkan anjakan reka letak. Imej mungkin mempengaruhi elemen Largest Contentful Paint. Skrip pihak ketiga mungkin membawa rantaian dependensinya sendiri.

Inilah sebabnya bilangan permintaan masih penting walaupun fail kecil. Skrip 3 KB boleh menjadi lebih buruk daripada imej 30 KB jika ia menyekat rendering, tiba lewat, dan dilaksanakan pada main thread pada masa yang salah.

Jika anda membaca laporan Lighthouse dan berasa seperti dihukum oleh berpuluh-puluh amaran berasingan, mulakan dengan melihat waterfall permintaan dan bukannya skor individu. Kami ada panduan praktikal dalam cara membaca laporan Lighthouse tanpa panik, tetapi versi ringkasnya ialah: cari perkara yang menyekat render pertama dan perkara yang melambatkan kandungan utama.

“Tetapi HTTP/2 sudah menyelesaikan ini,” kebanyakannya tidak

HTTP/2 dan HTTP/3 mengubah ekonomi permintaan. Ia memperkenalkan multiplexing, pemampatan header, dan tingkah laku sambungan yang lebih baik. Secara mudah, pelayar menjadi jauh lebih baik dalam menghantar berbilang permintaan melalui lebih sedikit sambungan.

Itu memang satu penambahbaikan sebenar. Ia juga menamatkan beberapa tabiat lama, seperti sprite CSS yang ekstrem dan bundle gabungan gergasi yang dibina hanya untuk mengelakkan had sambungan.

Tetapi HTTP/2 tidak menjadikan permintaan percuma.

Multiplexing membantu apabila banyak sumber berkongsi satu sambungan, tetapi pelayar masih perlu mengutamakannya. Pelayan masih perlu memberi respons. Klien masih perlu memproses setiap respons. Kesesakan, kehilangan paket, rundingan TLS, carian DNS, cache miss, dan tekanan main thread masih wujud.

HTTP/3 menambah baik beberapa tingkah laku pengangkutan, terutamanya sekitar migrasi sambungan dan head-of-line blocking pada lapisan pengangkutan. Ia tidak menghapuskan kos untuk menemui, menjadualkan, memuat turun, menghuraikan, dan melaksanakan sumber.

Jadi matlamat moden bukanlah “bundle semuanya ke dalam satu fail yang sangat besar.” Matlamatnya ialah “hantar lebih sedikit permintaan kritikal, dan jadikan permintaan yang selebihnya disengajakan.”

Waterfall ialah tempat kebenaran berada

Masalah prestasi jarang mengumumkan dirinya dalam satu metrik. Ia muncul sebagai bentuk.

Buka panel rangkaian pelayar dan lihat beberapa saat pertama. Tanya:

• Berapa banyak permintaan bermula sebelum kandungan utama muncul?
• Permintaan mana yang menyekat rendering?
• Adakah sumber penting ditemui lewat?
• Adakah skrip pihak ketiga bersaing dengan CSS, fon, atau imej pihak pertama?
• Adakah banyak fail mengembalikan respons 304 dan bukannya disajikan terus daripada cache?
• Adakah ikon, fon, atau serpihan UI dipecahkan kepada lebih banyak fail daripada yang diperlukan halaman?

Halaman yang pantas biasanya mempunyai waterfall awal yang membosankan. Sebilangan kecil sumber kritikal tiba awal. Sumber tidak kritikal menunggu. Skrip pihak ketiga dilengahkan, dihadkan, atau dibuang. Pelayar tidak dipaksa mengimbangi dua puluh keutamaan sebelum ia boleh melukis halaman.

Halaman yang perlahan sering mempunyai waterfall yang gelisah: banyak fail kecil, banyak origin, dan banyak penemuan lewat.

Fail lebih kecil masih penting — cuma tidak sama rata

Ini bukan hujah menentang pemampatan atau pengoptimuman. Ini ialah hujah menentang pengoptimuman bait sambil mengabaikan penyelarasan.

Fail yang lebih kecil paling penting apabila sumber itu besar, menyekat render, atau sebahagian daripada laluan kandungan utama. Contohnya:

• Imej hero harus disaizkan dan dienkodkan dengan betul.
• CSS yang menyekat render harus ringan.
• JavaScript yang diperlukan untuk interaksi pertama harus minimum.
• Fon harus disubset, dimampatkan, dan dihadkan kepada berat yang benar-benar digunakan.

Fon ialah contoh biasa. Pasukan sering terlalu menumpukan sama ada fail fon berukuran 24 KB atau 31 KB, sedangkan mereka menghantar enam berat, dua gaya, dan berbilang keluarga. Penyelesaian yang lebih baik bukan mengurangkan 7 KB daripada satu fail. Ia adalah menghantar lebih sedikit fail fon. Jika tipografi ialah sebahagian daripada kerja prestasi anda, fon web masih antara kemenangan paling mudah pada kebanyakan laman.

Imej mengikut corak yang sama. AVIF atau WebP boleh menjimatkan bait yang bermakna, tetapi menghantar sepuluh imej hiasan di bahagian atas paparan masih rancangan yang buruk. Pilih format yang lebih baik, ya, tetapi juga persoalkan sama ada setiap imej perlu diminta sama sekali. Untuk keputusan format, panduan kami tentang bila AVIF mengatasi WebP dan bila tidak ialah teman yang berguna untuk kerja bilangan permintaan ini.

Kos tersembunyi banyak fail kecil

Banyak permintaan kecil cenderung mewujudkan masalah yang tidak kelihatan jika anda hanya melihat jumlah bait yang dipindahkan.

1. Penemuan lewat

Pelayar tidak boleh meminta sesuatu yang belum ditemui. Fail CSS boleh merujuk fon. Skrip boleh mengimport skrip lain. Komponen boleh meminta JSON selepas hydration. Setiap dependensi menghasilkan satu lagi langkah dalam rantaian.

Semakin dalam rantaian itu, semakin lewat kerja penting bermula.

2. Overhead header

Setiap permintaan dan respons menyertakan header. Pemampatan header membantu, terutamanya melalui HTTP/2 dan HTTP/3, tetapi ia tidak menghapuskan overhead. Cookie boleh menjadikan ini jauh lebih buruk. Jika laman anda menghantar cookie besar bersama setiap permintaan, aset kecil menjadi kurang kecil dalam amalan.

Inilah salah satu sebab aset statik sering patut berada pada laluan atau domain tanpa cookie, dan mengapa header cache wajar diberi perhatian. Jika header berkelakuan pelik dalam produksi, menyahpepijat redirect dan header HTTP biasanya lebih pantas daripada meneka.

3. Gangguan main thread

Banyak chunk JavaScript boleh menghasilkan kerja huraian dan pelaksanaan yang berulang. Walaupun setiap chunk kecil, pelayar mungkin terus berhenti untuk menilai kod. Ini boleh menjejaskan Interaction to Next Paint dan membuat halaman terasa tersentak-sentak.

Pengguna tidak peduli bahawa setiap fail itu kecil. Mereka peduli bahawa mengetik menu mengambil masa 600 milisaat.

4. Kerumitan cache

Memecahkan aset boleh meningkatkan caching apabila dilakukan dengan teliti. Bundle vendor yang stabil dan bundle app yang berubah boleh menjadi pemisahan yang baik.

Tetapi chunking yang berlebihan boleh memakan diri. Lebih banyak fail bermakna lebih banyak carian cache, lebih banyak peluang pengesahan semula, lebih banyak penyelarasan versi, dan lebih banyak cara untuk secara tidak sengaja membatalkan sumber yang tidak perlu berubah.

Bundling kembali, tetapi dengan pertimbangan

Era pertama prestasi web menyukai bundling kerana pelayar mempunyai had sambungan yang ketat. Kemudian HTTP/2 tiba dan banyak pasukan beralih kuat ke arah code splitting yang agresif. Sebahagiannya berguna. Sebahagiannya menjadi kepercayaan karut.

Jalan tengah yang masuk akal ialah bundling sedar-route.

Untuk laman pemasaran atau laman kandungan yang tipikal:

• Inline atau muatkan hanya CSS yang diperlukan untuk rendering awal.
• Pastikan JavaScript global kecil.
• Elakkan memecahkan modul kecil kepada permintaan rangkaian berasingan.
• Lengahkan ciri interaktif yang tidak diperlukan serta-merta.
• Buang skrip pihak ketiga yang tidak setimpal dengan kosnya.

Untuk aplikasi:

• Pecahkan mengikut route atau ciri utama, bukan mengikut setiap komponen.
• Pastikan dependensi berkongsi stabil dan boleh dicache.
• Preload hanya sumber yang pasti diperlukan tidak lama lagi.
• Elakkan memuatkan kod admin, dashboard, editor, atau eksperimen pada halaman awam.
• Ukur kos interaksi, bukan hanya saiz bundle.

Bundling tidak semestinya baik. Code splitting tidak semestinya baik. Soalan yang berguna ialah: adakah pemisahan ini membantu pelayar menyampaikan pengalaman pengguna bermakna yang seterusnya dengan lebih cepat?

Permintaan pihak ketiga wajar lebih dicurigai

Permintaan pihak pertama sekurang-kurangnya berada di bawah kawalan anda. Permintaan pihak ketiga sering lebih perlahan, kurang boleh diramal, dan lebih mahal daripada yang kelihatan.

Satu tag manager boleh mencetuskan analitik, iklan, heatmap, widget chat, ujian A/B, alat persetujuan, dan skrip pemperibadian. Setiap vendor mungkin membawa lebih banyak permintaan. Ada yang akan berjalan awal. Ada yang akan menyekat main thread. Ada yang akan berubah tanpa proses rilis anda.

Pengoptimuman pihak ketiga terbaik ialah pemadaman. Yang kedua terbaik ialah pelengahan.

Sebelum menambah skrip pihak ketiga, tanya:

• Adakah ini perlu dimuatkan sebelum pengguna melihat halaman?
• Adakah ia perlu dimuatkan pada setiap halaman?
• Bolehkah ia dimuatkan selepas persetujuan, interaksi, atau masa idle?
• Siapa pemiliknya secara dalaman?
• Metrik apa yang membuktikan ia berbaloi dengan kos prestasinya?

Di sinilah prestasi menjadi tadbir urus. Seseorang perlu dibenarkan berkata tidak.

Senarai semak praktikal untuk mengurangkan permintaan

Mulakan dengan halaman yang paling penting: homepage, halaman harga, halaman produk, checkout, pendaftaran, atau halaman pendaratan teratas. Kemudian teliti waterfall.

Buang

• Padam JavaScript dan CSS yang tidak digunakan.
• Buang eksperimen lama, piksel terbiar, dan analitik berganda.
• Gugurkan berat fon dan pustaka ikon yang tidak digunakan.
• Gantikan imej hiasan dengan CSS apabila sesuai.

Gabungkan dengan cermat

• Bundle modul JavaScript kecil yang sentiasa dimuatkan bersama.
• Gabungkan fail CSS kecil yang menyekat laluan render yang sama.
• Gunakan sprite SVG atau SVG inline untuk ikon berulang apabila ia mengurangkan permintaan tanpa menjejaskan kebolehselenggaraan.

Tangguhkan

• Lazy-load imej di bawah bahagian atas paparan.
• Lengahkan skrip tidak kritikal sehingga selepas first paint atau interaksi pengguna.
• Muatkan komen, embed, peta, chat, dan pemain video hanya apabila diperlukan.

Cache dengan betul

• Gunakan caching jangka panjang untuk aset statik berversi.
• Elakkan pengesahan semula yang tidak perlu untuk fail yang jarang berubah.
• Pastikan HTML segar, tetapi biarkan aset ber-hash kekal dicache.

Ukur semula

Selepas setiap perubahan, semak waterfall sekali lagi. Matlamatnya bukan skor sempurna. Matlamatnya ialah lebih sedikit permintaan kritikal, rendering berguna yang lebih awal, dan kurang gangguan main thread.

Rupa keadaan yang baik

Halaman yang sihat tidak semestinya mempunyai permintaan paling sedikit yang mungkin. Ia mempunyai laluan kritikal yang kecil dan disengajakan.

Pelayar mendapat HTML, CSS penting, imej kandungan utama jika ada, mungkin skrip kecil yang diperlukan untuk navigasi atau interaksi bahagian atas paparan, dan set fon minimum yang diperlukan untuk menjadikan teks boleh dibaca. Yang lain menunggu giliran.

Itulah perbezaan antara halaman yang sekadar dioptimumkan dan halaman yang terasa pantas.

Mengecilkan fail masih berbaloi dilakukan. Tetapi jika laman sudah dimampatkan dengan munasabah, kemenangan prestasi seterusnya biasanya bukan lagi 2 KB yang dijimatkan daripada sebuah bundle. Ia ialah satu permintaan penyekat yang kurang, satu fail fon yang kurang, satu skrip pihak ketiga yang kurang, satu rantaian dependensi yang kurang.

Lebih sedikit permintaan menjadikan kerja pelayar lebih mudah. Mudah itu lebih kerap pantas daripada yang kita suka akui.