Preload, prefetch dan preconnect: bila setiap satu benar-benar membantu
Petunjuk sumber berguna apabila ia sepadan dengan kesesakan sebenar dalam pelayar. Digunakan secara membuta tuli, ia menambah hingar keutamaan dan kadangkala menjadikan halaman lebih perlahan.
Jadual kandungan
- Petunjuk sumber bukan sihir
- Apa yang sudah dilakukan dengan baik oleh pelayar
- Preload: untuk sumber halaman semasa yang ditemui terlalu lewat
- Preload dan imej LCP
- Prefetch: untuk halaman seterusnya, bukan halaman ini
- Preconnect: untuk sambungan mahal kepada origin penting
- DNS-prefetch: sepupu yang lebih ringan
- Cara membuat keputusan: aliran kerja praktikal
- 1. Kenal pasti kesesakan
- 2. Tambah satu petunjuk pada satu masa
- 3. Semak kesan sampingan keutamaan
- 4. Sahkan pengepala dan caching
- Kesilapan lazim
- Terlalu banyak preload
- Menggunakan prefetch untuk sumber yang diperlukan
- Preconnect kepada setiap pihak ketiga
- Melupakan keadaan mudah alih
- Jadual keputusan ringkas
- Peraturan tenang
Petunjuk sumber bukan sihir
preload, prefetch, dan preconnect sering dianggap sebagai senarai semak prestasi. Tambah beberapa tag pada <head>, jalankan semula Lighthouse, rasa lebih lega. Bukan begitu cara ia berfungsi.
Petunjuk ini ialah arahan kepada saluran pemuatan pelayar. Ia boleh membantu apabila anda tahu sesuatu yang tidak dapat ditemui oleh pelayar cukup awal. Ia boleh memudaratkan apabila anda meneka, memberi keutamaan berlebihan kepada kerja yang tidak kritikal, atau memanaskan sambungan yang tidak pernah diperlukan pengguna.
Ringkasnya:
- Gunakan
preloaduntuk sumber yang diperlukan oleh halaman semasa, tetapi ditemui terlalu lewat. - Gunakan
prefetchuntuk sumber navigasi masa depan yang berkemungkinan, bukan keperluan halaman semasa. - Gunakan
preconnectuntuk origin pihak ketiga yang penting apabila penyediaan sambungan benar-benar menyebabkan kelewatan.
Soalan praktikalnya bukan “petunjuk mana yang paling pantas?” Sebaliknya, “apa yang sedang ditunggu oleh pelayar, dan bolehkah petunjuk ini menghapuskan penantian itu?”
Apa yang sudah dilakukan dengan baik oleh pelayar
Pelayar moden bukan pemuat turun fail yang pasif. Ia menghuraikan HTML, mengimbas ke hadapan untuk sumber, menetapkan keutamaan, menggunakan semula sambungan, melengahkan kerja yang tidak kelihatan, dan menyesuaikan diri dengan keadaan rangkaian.
Ini bermakna petunjuk sumber harus digunakan secara terpilih. Jika helaian gaya, skrip, imej, atau fon sudah ditemui awal dan diberi keutamaan yang betul, menambah petunjuk mungkin tidak memberi apa-apa kesan. Lebih buruk, ia mungkin bersaing dengan sumber yang lebih penting.
Sebelum menambah petunjuk, lihat jejak waterfall dalam DevTools atau laporan makmal. Jika anda menggunakan Lighthouse, mulakan dengan diagnostik dan bukannya skor; kami mempunyai panduan berasingan tentang membaca laporan Lighthouse tanpa panik — tetapi ambil perhatian bahawa URL yang betul adalah peka huruf besar/kecil, jadi gunakan artikel terpaut daripada navigasi laman anda jika perlu.
Bukti sebenar biasanya kelihatan di tiga tempat:
- Sumber kritikal bermula lewat kerana pelayar menemuinya lewat.
- Sambungan kepada origin penting mengambil masa yang ketara sebelum permintaan pertama.
- Sumber halaman seterusnya sangat boleh diramal dan murah untuk diambil pada masa melahu.
Jika tiada satu pun benar, petunjuk itu mungkin sekadar hiasan.
Preload: untuk sumber halaman semasa yang ditemui terlalu lewat
preload memberitahu pelayar: “Ambil sumber ini sekarang kerana halaman semasa akan memerlukannya.”
Contoh lazim ialah fon web yang dirujuk di dalam CSS. Pelayar mesti memuat turun HTML, menemui CSS, memuat turun CSS, menghuraikannya, menemui fon, kemudian meminta fon tersebut. Jika fon itu penting untuk teks di bahagian atas lipatan, penemuan mungkin cukup lewat sehingga menyebabkan anjakan susun atur atau pemaparan teks tertunda.
Preload boleh menggerakkan permintaan itu lebih awal:
<link rel='preload' href='/fonts/inter-var.woff2' as='font' type='font/woff2' crossorigin>Atribut as penting. Ia memberitahu pelayar jenis sumber ini, yang mempengaruhi keutamaan, caching, dasar keselamatan kandungan, dan pengepala permintaan. Fon juga biasanya memerlukan crossorigin, walaupun disajikan daripada laman yang sama, kerana pengambilan fon menggunakan mod CORS.
Calon preload yang baik termasuk:
- Fon web utama yang digunakan untuk teks yang kelihatan.
- Imej hero yang merupakan elemen Largest Contentful Paint dan tidak boleh ditemui awal.
- Fail CSS kritikal yang dimuat secara tidak langsung.
- Modul atau skrip yang diperlukan sangat awal, tetapi tersembunyi di sebalik skrip lain.
Calon preload yang buruk termasuk:
- Setiap berat fon dalam sistem reka bentuk.
- Imej di bawah lipatan.
- Skrip yang tidak diperlukan untuk pemaparan awal.
- Sumber yang sudah ditemui oleh pelayar dalam cebisan HTML pertama.
Preload berkuasa kerana ia mempengaruhi keutamaan halaman semasa. Itulah juga sebab ia mudah disalahgunakan. Jika anda melakukan preload lima aset besar, anda bukan lagi membantu pelayar. Anda sedang bertelagah dengannya.
Fon ialah kes klasik. Melakukan preload satu fail fon utama boleh membantu. Melakukan preload enam berat dan italic biasanya memburukkan keadaan. Jika fon ialah kesesakan anda, betulkan set fon dahulu; panduan kami tentang mengapa fon web masih kemenangan prestasi paling mudah pada kebanyakan laman menerangkan pembersihan itu dengan lebih terperinci.
Preload dan imej LCP
Melakukan preload imej LCP boleh berguna apabila imej itu tidak kelihatan dalam HTML awal. Punca biasa termasuk imej latar CSS, komponen yang dirender klien, atau logik imej responsif yang muncul lewat.
Tetapi jika imej hero anda sudah berada dalam HTML sebagai <img> dengan srcset, sizes, dimensi yang munasabah, dan tanpa lazy loading, pelayar mungkin boleh menemuinya dengan cepat. Dalam kes itu, menambah fetchpriority='high' mungkin lebih sesuai berbanding preload, bergantung pada halaman.
Ujian yang baik: jika permintaan imej bermula lewat dalam waterfall dan menjadi elemen LCP, pertimbangkan preload. Jika ia bermula awal tetapi dimuat turun dengan perlahan, masalahnya ialah saiz, format, tingkah laku CDN, atau latensi pelayan — bukan penemuan. Untuk keputusan format imej, lihat bila AVIF mengatasi WebP dan bila tidak.
Prefetch: untuk halaman seterusnya, bukan halaman ini
prefetch memberitahu pelayar: “Sumber ini mungkin diperlukan tidak lama lagi, tetapi tidak diperlukan sekarang.”
Perbezaan itu penting. Prefetch sengaja berkeutamaan rendah. Pelayar mungkin mengambilnya semasa masa melahu dan menyimpannya untuk digunakan kemudian. Ia juga mungkin melangkaunya pada sambungan lemah, mod penjimatan data, atau ketika tekanan memori.
Gunakan prefetch apabila niat pengguna cukup kuat untuk menjadikan sumber seterusnya berkemungkinan.
Calon prefetch yang baik termasuk:
- Langkah seterusnya dalam checkout berbilang halaman.
- Hasil carian selepas pengguna mula menaip pertanyaan, jika laluan seterusnya boleh diramal.
- Halaman dokumentasi yang dipautkan daripada jadual kandungan apabila pengguna sedang aktif membaca kandungan berdekatan.
- Cebisan laluan dalam aplikasi satu halaman selepas pengguna menuding atau memfokuskan item navigasi.
Calon prefetch yang buruk termasuk:
- Seluruh pokok navigasi anda.
- Video besar atau galeri imej.
- Skrip pihak ketiga “sekadar berjaga-jaga.”
- Halaman yang jarang dilawati pengguna seterusnya.
Prefetch ialah tempat di mana kekangan diri membuahkan hasil. Sumber yang diambil dan tidak pernah digunakan bukan percuma. Ia menggunakan lebar jalur, kapasiti pelayan, tenaga, dan mungkin data pengguna. Pada rangkaian mudah alih, pengambilan spekulatif boleh menjadi benar-benar tidak mesra.
Untuk banyak laman, strategi prefetch terbaik adalah berasaskan niat. Jangan prefetch halaman harga sebaik sahaja halaman utama dimuatkan. Prefetch apabila pengguna membuka menu harga, menuding pautan harga, atau menatal hampir ke seruan tindakan yang kuat meramalkan navigasi.
Ingat juga bahawa tingkah laku pelayar berbeza-beza. Sesetengah pelayar konservatif dengan prefetch; sesetengah tetapan privasi mengurangkan atau melumpuhkan pemuatan spekulatif. Anggap prefetch sebagai penambahbaikan oportunistik, bukan mekanisme ketepatan.
Preconnect: untuk sambungan mahal kepada origin penting
preconnect memberitahu pelayar: “Mula menyediakan sambungan kepada origin ini sekarang.”
Ini mungkin termasuk carian DNS, sambungan TCP, dan rundingan TLS. Untuk origin pihak ketiga, penyediaan ini boleh mengambil ratusan milisaat, terutamanya pada rangkaian berlatensi tinggi. Jika halaman akan memerlukan permintaan kritikal daripada origin itu tidak lama lagi, preconnect boleh menjadikan permintaan kemudian lebih pantas.
Contoh:
<link rel='preconnect' href='https://fonts.gstatic.com' crossorigin>Calon preconnect yang baik termasuk:
- Origin fon yang digunakan untuk teks yang menyekat render.
- Origin API kritikal yang diperlukan semasa interaksi awal.
- Origin CDN yang menyajikan aset di bahagian atas lipatan.
- Penyedia pembayaran atau identiti yang diperlukan serta-merta selepas tindakan pengguna.
Calon preconnect yang buruk termasuk:
- Endpoint analitik dan pengiklanan yang tidak kritikal kepada pengguna.
- Origin yang digunakan hanya dalam sesetengah sesi.
- Senarai panjang pihak ketiga.
- Sumber same-origin, apabila pelayar sudah mempunyai atau akan segera membuka sambungan.
Preconnect mempunyai kos pegangan. Soket terbuka menggunakan memori dan sumber rangkaian. Pelayar akan menutup sambungan yang tidak digunakan, tetapi itu tidak menjadikan preconnect yang tidak perlu tidak berbahaya.
Peraturan berguna: preconnect kepada paling banyak satu atau dua origin pihak ketiga berkeyakinan tinggi pada satu halaman. Jika anda tergoda untuk menambah lebih banyak, seni bina pihak ketiga anda mungkin lebih memerlukan semakan berbanding petunjuk anda memerlukan pengembangan.
DNS-prefetch: sepupu yang lebih ringan
Anda juga mungkin melihat dns-prefetch:
<link rel='dns-prefetch' href='https://example-cdn.com'>Ini hanya menyelesaikan nama domain. Ia tidak membuka sambungan TCP atau TLS. Ia lebih murah berbanding preconnect, tetapi juga kurang membantu.
DNS-prefetch boleh munasabah untuk origin pihak ketiga yang berkeyakinan lebih rendah apabila preconnect penuh terasa terlalu agresif. Dalam amalan, jika origin kritikal dan pasti digunakan tidak lama lagi, pilih preconnect. Jika ia sekadar mungkin, sama ada gunakan DNS-prefetch atau tidak buat apa-apa.
Cara membuat keputusan: aliran kerja praktikal
Mulakan dengan pengukuran, bukan tag.
1. Kenal pasti kesesakan
Buka jejak prestasi dan cari penemuan lewat. Adakah permintaan fon, imej hero, atau skrip bermula hanya selepas fail lain dimuat turun dan dihuraikan? Itu calon preload.
Jika permintaan bermula hanya selepas penyediaan DNS/TCP/TLS yang panjang kepada origin pihak ketiga, itu calon preconnect.
Jika halaman semasa baik-baik saja tetapi navigasi seterusnya boleh diramal perlahan, prefetch mungkin membantu.
2. Tambah satu petunjuk pada satu masa
Petunjuk sumber saling berinteraksi. Tambah satu, uji, dan kekalkan hanya jika waterfall bertambah baik dan metrik yang dihadapi pengguna tidak merosot.
Untuk preload, perhatikan sama ada sumber yang diberi petunjuk benar-benar digunakan tidak lama kemudian. Chrome mungkin memberi amaran apabila sumber yang dipreload tidak digunakan sejurus selepas pemuatan. Ambil amaran itu dengan serius.
3. Semak kesan sampingan keutamaan
Preload boleh menarik lebar jalur daripada CSS, JavaScript, atau imej yang lebih penting. Preconnect boleh memenuhi slot sambungan. Prefetch boleh menambah trafik latar belakang.
Hasil yang betul bukan “fail yang diberi petunjuk bermula lebih awal.” Hasil yang betul ialah “halaman menjadi lebih baik secara bermakna untuk pengguna.” Lihat LCP, INP, CLS, dan pemantauan pengguna sebenar jika boleh.
4. Sahkan pengepala dan caching
Petunjuk boleh dihantar dalam HTML atau pengepala HTTP Link. Pengepala berguna apabila pelayan tahu awal apa yang akan diperlukan oleh halaman, tetapi ia lebih sukar diperiksa secara kasual. Jika anda menyahpepijat sama ada petunjuk benar-benar wujud dalam production, pengepala mentah penting; inilah tepat jenis situasi yang dibincangkan dalam panduan kami untuk menyahpepijat redirects dan pengepala HTTP.
Caching juga penting. Melakukan preload sumber dengan kelayakan yang tidak sepadan, as yang salah, atau parameter URL yang berbeza boleh menyebabkan muat turun berganda. Itu salah satu cara paling lazim preload yang berniat baik menjadi pepijat prestasi.
Kesilapan lazim
Terlalu banyak preload
Jika semuanya kritikal, tiada apa-apa yang kritikal. Hadkan preload kepada sumber yang diperlukan untuk pemaparan awal atau interaktiviti serta-merta. Halaman biasa patut mempunyai sifar hingga tiga preload, bukan dua puluh.
Menggunakan prefetch untuk sumber yang diperlukan
Prefetch berkeutamaan rendah dan pilihan. Jangan gunakannya untuk aset yang diperlukan oleh halaman semasa. Jika halaman memerlukannya sekarang, pertimbangkan preload atau penemuan HTML biasa.
Preconnect kepada setiap pihak ketiga
Halaman yang berat dengan pihak ketiga sering mempunyai sepuluh atau lebih origin luaran. Preconnect kepada semuanya mencipta hingar. Pilih satu atau dua yang kedua-duanya kritikal dan boleh diramal digunakan.
Melupakan keadaan mudah alih
Petunjuk sumber paling bernilai pada sambungan lebih perlahan, tetapi juga paling berbahaya di situ. Prefetch yang sia-sia pada sambungan desktop pantas hanyalah ralat pembundaran. Pada pelan mudah alih terhad, ia pertukaran yang buruk.
Jadual keputusan ringkas
| Situasi | Petunjuk terbaik | Mengapa | |---|---:|---| | Fon kritikal ditemui melalui CSS | preload | Halaman semasa memerlukannya, penemuan lewat | | Imej hero tersembunyi di sebalik CSS atau rendering klien | preload | Boleh menambah baik LCP jika imej bermula lewat | | Laluan seterusnya yang berkemungkinan selepas niat pengguna | prefetch | Membantu navigasi masa depan tanpa menyekat halaman semasa | | Origin fon/API pihak ketiga yang kritikal | preconnect | Mengeluarkan penyediaan sambungan daripada laluan kritikal | | Origin pihak ketiga yang mungkin tetapi tidak pasti | dns-prefetch atau tiada | Kos lebih rendah, keyakinan lebih rendah | | Imej di bawah lipatan | tiada | Biarkan lazy loading dan keutamaan pelayar bekerja |
Peraturan tenang
Petunjuk sumber berfungsi paling baik apabila ia membosankan dan khusus. Satu fon. Satu imej LCP. Satu origin pihak ketiga yang penting. Satu laluan seterusnya yang berkemungkinan selepas niat.
Ia berfungsi dengan buruk apabila digunakan sebagai optimisme: mungkin pengguna akan memerlukan ini, mungkin pelayar patut mengambil itu, mungkin lebih banyak petunjuk bermakna lebih laju.
Pelayar sudah mengoptimumkan secara agresif. Tugas anda bukan mengurus mikro setiap permintaan. Tugas anda ialah membetulkan beberapa kes apabila pelayar kekurangan maklumat pada saat yang tepat.
Soalan yang sering ditanya
Patutkah saya preload semua fon saya?
Adakah prefetch selamat digunakan untuk setiap pautan dalaman?
Apakah perbezaan antara preconnect dan dns-prefetch?
Bolehkah petunjuk sumber menambah baik Core Web Vitals?
Patutkah petunjuk sumber ditambah dalam HTML atau pengepala HTTP?
Sumber & bacaan lanjut
