Web Performance

Preload, prefetch, dan preconnect: kapan masing-masing benar-benar membantu

Resource hints berguna ketika sesuai dengan bottleneck browser yang nyata. Jika digunakan secara asal, mereka menambah kebisingan prioritas dan terkadang membuat halaman lebih lambat.

The Wux Webtools Team The Wux Webtools Team 9 menit baca Dibantu AI, ditinjau manusia
A simplified browser loading waterfall showing early resource hints for a web page.
Daftar isi
  1. Resource hints bukan sihir
  2. Hal yang sudah dilakukan browser dengan baik
  3. Preload: untuk resource halaman saat ini yang ditemukan terlalu terlambat
  4. Preload dan gambar LCP
  5. Prefetch: untuk halaman berikutnya, bukan halaman ini
  6. Preconnect: untuk koneksi mahal ke origin penting
  7. DNS-prefetch: saudara yang lebih ringan
  8. Cara memutuskan: alur kerja praktis
  9. 1. Identifikasi bottleneck
  10. 2. Tambahkan satu hint pada satu waktu
  11. 3. Periksa efek samping prioritas
  12. 4. Verifikasi header dan caching
  13. Kesalahan umum
  14. Melakukan preload terlalu banyak
  15. Menggunakan prefetch untuk resource yang wajib
  16. Melakukan preconnect ke setiap pihak ketiga
  17. Melupakan kondisi seluler
  18. Tabel keputusan sederhana
  19. Aturan yang tenang

Resource hints bukan sihir

preload, prefetch, dan preconnect sering diperlakukan seperti checklist performa. Tambahkan beberapa tag ke <head>, jalankan ulang Lighthouse, lalu merasa lebih tenang. Bukan begitu cara kerjanya.

Hint ini adalah instruksi untuk pipeline pemuatan browser. Mereka dapat membantu ketika Anda mengetahui sesuatu yang tidak dapat ditemukan browser cukup awal. Mereka dapat merugikan ketika Anda menebak, memberi prioritas berlebihan pada pekerjaan yang tidak kritis, atau memanaskan koneksi yang tidak pernah dibutuhkan pengguna.

Versi singkatnya:

  • Gunakan preload untuk resource yang diperlukan halaman saat ini, tetapi ditemukan terlalu terlambat.
  • Gunakan prefetch untuk resource navigasi mendatang yang kemungkinan dibutuhkan, bukan kebutuhan penting halaman saat ini.
  • Gunakan preconnect untuk origin pihak ketiga yang penting ketika penyiapan koneksi benar-benar menjadi penundaan.

Pertanyaan praktisnya bukan “hint mana yang paling cepat?” Melainkan “apa yang sedang ditunggu browser, dan dapatkah hint ini menghilangkan waktu tunggu itu?”

Hal yang sudah dilakukan browser dengan baik

Browser modern bukan pengunduh file yang pasif. Mereka mem-parsing HTML, memindai lebih awal untuk mencari resource, menetapkan prioritas, menggunakan ulang koneksi, menunda pekerjaan yang belum terlihat, dan beradaptasi dengan kondisi jaringan.

Artinya, resource hints harus selektif. Jika stylesheet, script, gambar, atau font sudah ditemukan sejak awal dan diberi prioritas yang tepat, menambahkan hint mungkin tidak berpengaruh. Lebih buruk lagi, hint itu dapat bersaing dengan resource yang lebih penting.

Sebelum menambahkan hint, lihat trace waterfall di DevTools atau laporan lab. Jika Anda menggunakan Lighthouse, mulai dari diagnostik, bukan skornya; kami memiliki panduan terpisah tentang membaca laporan Lighthouse tanpa panik — tetapi perhatikan bahwa URL yang benar peka huruf besar-kecil, jadi gunakan artikel tertaut dari navigasi situs Anda jika perlu.

Bukti nyata biasanya terlihat di tiga tempat:

  1. Resource kritis mulai terlambat karena browser menemukannya terlambat.
  2. Koneksi ke origin penting memakan waktu yang terasa sebelum request pertama.
  3. Resource halaman berikutnya sangat dapat diprediksi dan murah untuk diambil saat idle.

Jika tidak ada yang benar, hint mungkin hanya dekorasi.

Preload: untuk resource halaman saat ini yang ditemukan terlalu terlambat

preload memberi tahu browser: “Ambil resource ini sekarang karena halaman saat ini akan membutuhkannya.”

Contoh umum adalah web font yang dirujuk di dalam CSS. Browser harus mengunduh HTML, menemukan CSS, mengunduh CSS, mem-parsing-nya, menemukan font, lalu meminta font tersebut. Jika font itu penting untuk teks di area awal layar, penemuannya bisa cukup terlambat hingga menyebabkan layout shift atau rendering teks tertunda.

Preload dapat memajukan request itu:

<link rel='preload' href='/fonts/inter-var.woff2' as='font' type='font/woff2' crossorigin>

Atribut as penting. Atribut ini memberi tahu browser jenis resource tersebut, yang memengaruhi prioritas, caching, content security policy, dan header request. Font juga biasanya membutuhkan crossorigin, bahkan ketika disajikan dari situs yang sama, karena pengambilan font menggunakan mode CORS.

Kandidat preload yang baik meliputi:

  • Web font utama yang digunakan untuk teks yang terlihat.
  • Hero image yang menjadi elemen Largest Contentful Paint dan tidak dapat ditemukan sejak awal.
  • File CSS kritis yang dimuat secara tidak langsung.
  • Module atau script yang dibutuhkan sangat awal, tetapi tersembunyi di balik script lain.

Kandidat preload yang buruk meliputi:

  • Setiap bobot font dalam design system.
  • Gambar di bawah fold.
  • Script yang tidak dibutuhkan untuk rendering awal.
  • Resource yang sudah ditemukan browser dalam potongan HTML pertama.

Preload kuat karena memengaruhi prioritas halaman saat ini. Itu juga alasan mengapa mudah disalahgunakan. Jika Anda melakukan preload pada lima aset besar, Anda tidak lagi membantu browser. Anda sedang berdebat dengannya.

Font adalah kasus klasik. Melakukan preload pada satu file font utama dapat membantu. Melakukan preload pada enam bobot dan italic biasanya memperburuk keadaan. Jika font adalah bottleneck Anda, perbaiki set font terlebih dahulu; panduan kami tentang mengapa web font masih merupakan kemenangan performa termudah di sebagian besar situs membahas pembersihan itu dengan lebih detail.

Preload dan gambar LCP

Melakukan preload pada gambar LCP dapat berguna ketika gambar tidak terlihat di HTML awal. Penyebab umum mencakup gambar latar CSS, komponen yang dirender di sisi klien, atau logika gambar responsif yang muncul terlambat.

Namun jika hero image Anda sudah ada di HTML sebagai <img> dengan srcset, sizes, dimensi yang masuk akal, dan tanpa lazy loading, browser mungkin dapat menemukannya dengan cepat. Dalam kasus itu, menambahkan fetchpriority='high' mungkin lebih tepat daripada preload, bergantung pada halamannya.

Tes yang baik: jika request gambar mulai terlambat di waterfall dan menjadi elemen LCP, pertimbangkan preload. Jika mulai lebih awal tetapi diunduh dengan lambat, masalahnya adalah ukuran, format, perilaku CDN, atau latensi server — bukan penemuan. Untuk keputusan format gambar, lihat kapan AVIF mengalahkan WebP dan kapan tidak.

Prefetch: untuk halaman berikutnya, bukan halaman ini

prefetch memberi tahu browser: “Resource ini mungkin akan dibutuhkan segera, tetapi tidak diperlukan sekarang.”

Pembedaan itu penting. Prefetch sengaja berprioritas rendah. Browser dapat mengambilnya saat idle dan menyimpannya untuk digunakan nanti. Browser juga dapat melewatinya pada koneksi buruk, mode hemat data, atau saat tekanan memori.

Gunakan prefetch ketika niat pengguna cukup kuat sehingga resource berikutnya kemungkinan dibutuhkan.

Kandidat prefetch yang baik meliputi:

  • Langkah berikutnya dalam checkout multi-halaman.
  • Hasil pencarian setelah pengguna mulai mengetik kueri, jika route berikutnya dapat diprediksi.
  • Halaman dokumentasi yang ditautkan dari daftar isi ketika pengguna aktif membaca konten di sekitarnya.
  • Potongan route dalam single-page app setelah pengguna meng-hover atau memfokuskan item navigasi.

Kandidat prefetch yang buruk meliputi:

  • Seluruh pohon navigasi Anda.
  • Video besar atau galeri gambar.
  • Script pihak ketiga “untuk berjaga-jaga.”
  • Halaman yang jarang dikunjungi pengguna berikutnya.

Prefetch adalah tempat di mana menahan diri membuahkan hasil. Resource yang diambil dan tidak pernah digunakan bukanlah gratis. Ia mengonsumsi bandwidth, kapasitas server, energi, dan mungkin data pengguna. Pada jaringan seluler, pengambilan spekulatif dapat benar-benar tidak ramah.

Untuk banyak situs, strategi prefetch terbaik berbasis niat. Jangan melakukan prefetch halaman harga segera setelah halaman beranda dimuat. Prefetch ketika pengguna membuka menu harga, meng-hover tautan harga, atau menggulir mendekati call-to-action yang sangat memprediksi navigasi.

Ingat juga bahwa perilaku browser bervariasi. Sebagian browser konservatif dengan prefetch; beberapa pengaturan privasi mengurangi atau menonaktifkan pemuatan spekulatif. Perlakukan prefetch sebagai peningkatan oportunistis, bukan mekanisme kebenaran.

Preconnect: untuk koneksi mahal ke origin penting

preconnect memberi tahu browser: “Mulai siapkan koneksi ke origin ini sekarang.”

Itu dapat mencakup DNS lookup, koneksi TCP, dan negosiasi TLS. Untuk origin pihak ketiga, penyiapan ini dapat memakan ratusan milidetik, terutama pada jaringan berlatensi tinggi. Jika halaman segera membutuhkan request kritis dari origin itu, preconnect dapat membuat request berikutnya lebih cepat.

Contoh:

<link rel='preconnect' href='https://fonts.gstatic.com' crossorigin>

Kandidat preconnect yang baik meliputi:

  • Origin font yang digunakan untuk teks yang memblokir rendering.
  • Origin API kritis yang dibutuhkan selama interaksi awal.
  • Origin CDN yang menyajikan aset di area awal layar.
  • Penyedia pembayaran atau identitas yang dibutuhkan segera setelah tindakan pengguna.

Kandidat preconnect yang buruk meliputi:

  • Endpoint analitik dan iklan yang tidak kritis bagi pengguna.
  • Origin yang hanya digunakan pada sebagian sesi.
  • Daftar panjang pihak ketiga.
  • Resource same-origin, ketika browser sudah memiliki atau akan segera membuka koneksi.

Preconnect memiliki biaya penahanan. Socket terbuka mengonsumsi memori dan resource jaringan. Browser akan menutup koneksi yang tidak digunakan, tetapi itu tidak membuat preconnect yang tidak perlu menjadi tanpa risiko.

Aturan yang berguna: lakukan preconnect paling banyak ke satu atau dua origin pihak ketiga dengan keyakinan tinggi pada satu halaman. Jika Anda tergoda menambahkan lebih banyak, arsitektur pihak ketiga Anda mungkin lebih perlu ditinjau daripada hint Anda perlu diperluas.

DNS-prefetch: saudara yang lebih ringan

Anda mungkin juga melihat dns-prefetch:

<link rel='dns-prefetch' href='https://example-cdn.com'>

Ini hanya menyelesaikan nama domain. Ia tidak membuka koneksi TCP atau TLS. Biayanya lebih rendah daripada preconnect, tetapi juga kurang membantu.

DNS-prefetch dapat masuk akal untuk origin pihak ketiga dengan keyakinan lebih rendah ketika preconnect penuh terasa terlalu agresif. Dalam praktiknya, jika origin kritis dan pasti akan digunakan segera, pilih preconnect. Jika hanya mungkin, gunakan DNS-prefetch atau jangan lakukan apa pun.

Cara memutuskan: alur kerja praktis

Mulailah dengan pengukuran, bukan tag.

1. Identifikasi bottleneck

Buka trace performa dan cari penemuan yang terlambat. Apakah request font, hero image, atau script baru mulai setelah file lain diunduh dan di-parse? Itu adalah kandidat preload.

Jika request baru mulai setelah penyiapan DNS/TCP/TLS yang panjang ke origin pihak ketiga, itu adalah kandidat preconnect.

Jika halaman saat ini baik-baik saja tetapi navigasi berikutnya dapat diprediksi lambat, prefetch mungkin membantu.

2. Tambahkan satu hint pada satu waktu

Resource hints saling berinteraksi. Tambahkan satu, uji, dan pertahankan hanya jika waterfall membaik dan metrik yang dirasakan pengguna tidak menurun.

Untuk preload, perhatikan apakah resource yang diberi hint benar-benar segera digunakan. Chrome dapat memberi peringatan ketika resource yang di-preload tidak digunakan tak lama setelah pemuatan. Tanggapi peringatan itu dengan serius.

3. Periksa efek samping prioritas

Preload dapat menarik bandwidth dari CSS, JavaScript, atau gambar yang lebih penting. Preconnect dapat menempati slot koneksi. Prefetch dapat menambah trafik latar belakang.

Hasil yang benar bukan “file yang diberi hint mulai lebih awal.” Hasil yang benar adalah “halaman menjadi lebih baik secara bermakna bagi pengguna.” Lihat LCP, INP, CLS, dan real-user monitoring jika memungkinkan.

4. Verifikasi header dan caching

Hint dapat dikirim dalam HTML atau header HTTP Link. Header berguna ketika server mengetahui lebih awal apa yang akan dibutuhkan halaman, tetapi lebih sulit diperiksa secara kasual. Jika Anda sedang men-debug apakah suatu hint benar-benar ada di production, header mentah itu penting; ini persis jenis situasi yang dibahas dalam panduan kami untuk men-debug redirect dan header HTTP.

Caching juga penting. Melakukan preload pada resource dengan kredensial yang tidak cocok, as yang salah, atau parameter URL yang berbeda dapat menyebabkan unduhan ganda. Itu adalah salah satu cara paling umum preload yang bermaksud baik berubah menjadi bug performa.

Kesalahan umum

Melakukan preload terlalu banyak

Jika semuanya kritis, tidak ada yang kritis. Batasi preload pada resource yang dibutuhkan untuk rendering awal atau interaktivitas segera. Halaman tipikal sebaiknya memiliki nol hingga tiga preload, bukan dua puluh.

Menggunakan prefetch untuk resource yang wajib

Prefetch berprioritas rendah dan opsional. Jangan gunakan untuk aset yang dibutuhkan oleh halaman saat ini. Jika halaman membutuhkannya sekarang, pertimbangkan preload atau penemuan HTML normal.

Melakukan preconnect ke setiap pihak ketiga

Halaman yang berat dengan pihak ketiga sering memiliki sepuluh atau lebih origin eksternal. Melakukan preconnect ke semuanya menciptakan kebisingan. Pilih satu atau dua yang sekaligus kritis dan dapat diprediksi akan digunakan.

Melupakan kondisi seluler

Resource hints paling bernilai pada koneksi yang lebih lambat, tetapi juga paling berbahaya di sana. Prefetch yang terbuang pada koneksi desktop cepat hanyalah selisih kecil. Pada paket seluler terbatas, itu adalah pertukaran yang buruk.

Tabel keputusan sederhana

| Situasi | Hint terbaik | Mengapa | |---|---:|---| | Font kritis ditemukan melalui CSS | preload | Halaman saat ini membutuhkannya, penemuan terlambat | | Hero image tersembunyi di balik CSS atau rendering klien | preload | Dapat meningkatkan LCP jika gambar mulai terlambat | | Route berikutnya yang mungkin setelah niat pengguna | prefetch | Membantu navigasi mendatang tanpa memblokir halaman saat ini | | Origin font/API pihak ketiga yang kritis | preconnect | Menghilangkan penyiapan koneksi dari critical path | | Origin pihak ketiga yang mungkin tetapi tidak pasti | dns-prefetch atau tidak ada | Biaya lebih rendah, keyakinan lebih rendah | | Gambar di bawah fold | tidak ada | Biarkan lazy loading dan prioritas browser bekerja |

Aturan yang tenang

Resource hints bekerja paling baik ketika membosankan dan spesifik. Satu font. Satu gambar LCP. Satu origin pihak ketiga yang penting. Satu route berikutnya yang mungkin setelah ada niat.

Mereka bekerja buruk ketika digunakan sebagai optimisme: mungkin pengguna akan membutuhkan ini, mungkin browser sebaiknya mengambil itu, mungkin lebih banyak hint berarti lebih cepat.

Browser sudah mengoptimalkan secara agresif. Tugas Anda bukan mengatur mikro setiap request. Tugas Anda adalah memperbaiki beberapa kasus ketika browser kekurangan informasi pada momen yang tepat.

Pertanyaan yang sering diajukan

Haruskah saya melakukan preload pada semua font saya?
Tidak. Preload hanya file font yang dibutuhkan untuk teks yang terlihat sejak awal halaman. Melakukan preload pada setiap bobot dan gaya biasanya memboroskan bandwidth dan dapat menunda resource yang lebih penting.
Apakah prefetch aman digunakan untuk setiap tautan internal?
Biasanya tidak. Itu dapat menciptakan trafik latar belakang yang tidak perlu dan membuang data pengguna. Pilih prefetch berbasis niat, seperti setelah hover, fokus, menu terbuka, atau langkah berikutnya yang dapat diprediksi.
Apa perbedaan antara preconnect dan dns-prefetch?
Preconnect melakukan penyiapan DNS, TCP, dan TLS untuk sebuah origin. DNS-prefetch hanya menyelesaikan nama domain. Preconnect lebih kuat tetapi lebih mahal, jadi sebaiknya digunakan dengan keyakinan yang lebih tinggi.
Dapatkah resource hints meningkatkan Core Web Vitals?
Ya, terutama LCP, ketika mereka memperbaiki penemuan terlambat atau penyiapan koneksi untuk resource kritis. Mereka tidak akan membantu jika masalah sebenarnya adalah aset yang terlalu besar, respons server lambat, kode yang memblokir rendering, atau caching yang buruk.
Haruskah resource hints ditambahkan di HTML atau header HTTP?
Keduanya bisa bekerja. HTML lebih mudah dipahami untuk hint spesifik halaman. Header HTTP Link dapat berguna ketika server mengetahui resource kritis sebelum HTML di-parse, tetapi memerlukan pengujian cermat untuk menghindari duplikat atau hint yang kedaluwarsa.

Sumber & bacaan lebih lanjut

  1. MDN: rel=preload
  2. MDN: Resource hints
  3. web.dev: Preconnect and DNS-prefetch
  4. W3C: Resource Hints
#performance #resource-hints #html #browser #optimization
Tentang penulis
The Wux Webtools Team

Terakhir diperbarui:

Terus membaca