Cari tahu apa itu pemindai pramuat browser, bagaimana hal ini membantu performa, dan cara agar tidak terganggu.
Salah satu aspek yang terabaikan dalam mengoptimalkan kecepatan halaman adalah mengetahui sedikit tentang bagian dalam browser. Browser melakukan pengoptimalan tertentu untuk meningkatkan performa dengan cara yang tidak dapat dilakukan oleh kami, tetapi hanya selama pengoptimalan tersebut tidak digagalkan secara tidak sengaja.
Satu pengoptimalan browser internal yang harus dipahami adalah pemindai pramuat browser. Postingan ini akan membahas cara kerja pemindai pramuat—dan yang lebih penting, bagaimana agar Anda tidak terganggu.
Apa itu pemindai pramuat?
Setiap browser memiliki parser HTML utama yang membuat token markup mentah dan memprosesnya menjadi model objek. Semua ini berjalan lancar sampai parser berhenti ketika menemukan resource pemblokir, seperti stylesheet yang dimuat dengan elemen <link>, atau skrip yang dimuat dengan elemen <script> tanpa atribut async atau defer.
<link> untuk file CSS eksternal, yang memblokir browser agar tidak mengurai bagian lain dokumen—atau bahkan merendernya—sampai CSS didownload dan diuraikan.
Pada kasus file CSS, penguraian dan rendering diblokir untuk mencegah flash konten tanpa gaya (FOUC), yaitu saat versi halaman tanpa gaya dapat dilihat sebentar sebelum gaya diterapkan pada file tersebut.
Browser juga memblokir penguraian dan rendering halaman saat menemukan elemen <script> tanpa atribut defer atau async.
Alasannya adalah karena browser tidak dapat mengetahui dengan pasti apakah skrip tertentu akan memodifikasi DOM saat parser HTML utama masih melakukan tugasnya. Inilah praktik umum untuk memuat JavaScript Anda di akhir dokumen sehingga efek dari penguraian dan rendering yang diblokir menjadi marginal.
Berikut adalah alasan bagus mengapa browser harus memblokir penguraian dan rendering. Namun, memblokir salah satu langkah penting ini tidak diinginkan, karena mereka dapat menunda pertunjukan dengan menunda penemuan sumber daya penting lainnya. Untungnya, browser melakukan yang terbaik untuk mengurangi masalah ini melalui parser HTML sekunder yang disebut pemindai pramuat.
<body>, tetapi pemindai pramuat dapat melihat ke depan di markup mentah untuk menemukan resource gambar tersebut dan mulai memuatnya sebelum parser HTML utama dibatalkan pemblokirannya.
Peran pemindai pramuat bersifat spekulatif, artinya pemindai tersebut memeriksa markup mentah untuk menemukan resource yang dapat diambil secara oportunistik sebelum parser HTML utama menemukannya.
Cara mengetahui saat pemindai pramuat berfungsi
Pemindai pramuat ada karena rendering dan penguraian yang diblokir. Jika kedua masalah kinerja ini tidak pernah ada, pemindai pramuat tidak akan terlalu berguna. Kunci untuk mencari tahu apakah halaman web mendapat manfaat dari pemindai pramuat bergantung pada fenomena pemblokiran ini. Untuk melakukannya, Anda dapat menerapkan penundaan buatan untuk permintaan guna mengetahui di mana pemindai pramuat berfungsi.
Gunakan halaman ini yang berisi teks dan gambar dasar dengan stylesheet sebagai contoh. Karena file CSS memblokir rendering dan penguraian, Anda memperkenalkan penundaan buatan selama dua detik untuk stylesheet melalui layanan proxy. Keterlambatan ini memudahkan Anda melihat di waterfall jaringan tempat pemindai pramuat berfungsi.
Seperti yang dapat Anda lihat di waterfall, pemindai pramuat menemukan elemen <img> meskipun rendering dan penguraian dokumen diblokir. Tanpa pengoptimalan ini, browser tidak dapat mengambil sesuatu secara oportunistik selama periode pemblokiran, dan permintaan resource lainnya akan terjadi secara berturut-turut, bukan serentak.
Setelah melihat contoh mainan tersebut, mari kita lihat beberapa pola di dunia nyata yang menyebabkan pemindai pramuat tidak berfungsi, dan apa yang dapat dilakukan untuk memperbaikinya.
Memasukkan async skrip
Misalnya Anda memiliki HTML di <head> yang menyertakan beberapa JavaScript inline seperti ini:
<script>
const scriptEl = document.createElement('script');
scriptEl.src = '/yall.min.js';
document.head.appendChild(scriptEl);
</script>
Skrip yang diinjeksikan adalah async secara default sehingga saat skrip ini dimasukkan, skrip akan berperilaku seolah-olah atribut async diterapkan ke skrip tersebut. Artinya, shader tersebut akan berjalan sesegera mungkin dan tidak memblokir rendering. Kedengarannya optimal, bukan? Namun, jika Anda menganggap <script> inline ini muncul setelah elemen <link> yang memuat file CSS eksternal, Anda akan mendapatkan hasil yang kurang optimal:
async yang dimasukkan. Pemindai pramuat tidak dapat menemukan skrip selama fase pemblokiran render karena diinjeksi pada klien.
Mari kita uraikan apa yang terjadi di sini:
- Pada detik ke-0, dokumen utama akan diminta.
- Pada 1,4 detik, byte pertama permintaan navigasi tiba.
- Pada detik 2,0, CSS dan gambar akan diminta.
- Karena parser diblokir saat memuat stylesheet dan JavaScript inline yang memasukkan skrip
asyncmuncul setelah stylesheet tersebut pada detik ke-2,6, fungsi yang disediakan oleh skrip tidak tersedia sesegera mungkin.
Hal ini kurang optimal karena permintaan untuk skrip hanya terjadi setelah stylesheet selesai didownload. Tindakan ini akan menunda pengoperasian skrip. Sebaliknya, karena elemen <img> dapat ditemukan di markup yang disediakan server, elemen tersebut akan ditemukan oleh pemindai pramuat.
Jadi, apa yang terjadi jika Anda menggunakan tag <script> biasa dengan atribut async, bukan memasukkan skrip ke dalam DOM?
<script src="/yall.min.js" async></script>
Ini adalah hasilnya:
async <script>. Pemindai pramuat menemukan skrip selama fase pemblokiran render, dan memuatnya bersamaan dengan CSS.
Mungkin ada kecenderungan untuk menyarankan bahwa masalah ini dapat diatasi dengan menggunakan rel=preload. Cara ini pasti bekerja, tetapi mungkin ada beberapa efek samping. Lagi pula, mengapa menggunakan rel=preload untuk memperbaiki masalah yang dapat dihindari dengan tidak memasukkan elemen <script> ke dalam DOM?
async yang dimasukkan, tetapi skrip async dipramuat untuk memastikannya lebih cepat ditemukan.
Melakukan pramuat "memperbaiki" masalah di sini, tetapi ini menimbulkan masalah baru: skrip async di dua demo pertama—meskipun dimuat dalam <head>—dimuat pada prioritas "Rendah", sedangkan stylesheet dimuat pada prioritas "Tertinggi". Dalam demo terakhir, tempat skrip async dipramuat, stylesheet tetap dimuat pada prioritas "Tertinggi", tetapi prioritas skrip telah dipromosikan menjadi "Tinggi".
Jika prioritas resource dinaikkan, browser akan mengalokasikan lebih banyak bandwidth ke resource tersebut. Artinya, meskipun stylesheet memiliki prioritas tertinggi—prioritas skrip yang dinaikkan dapat menyebabkan pertentangan bandwidth. Hal tersebut dapat menjadi faktor pada koneksi yang lambat, atau jika resource-nya cukup besar.
Jawabannya di sini mudah: jika skrip diperlukan selama startup, jangan kalahkan pemindai pramuat dengan memasukkannya ke DOM. Lakukan eksperimen sesuai kebutuhan dengan penempatan elemen <script>, dan juga dengan atribut seperti defer dan async.
Pemuatan lambat dengan JavaScript
Pemuatan lambat adalah metode yang bagus untuk menghemat data, dan sering kali diterapkan pada gambar. Namun, terkadang pemuatan lambat salah diterapkan pada gambar yang berada "paruh atas", boleh dikatakan demikian.
Hal ini menimbulkan potensi masalah terkait visibilitas resource yang terkait dengan pemindai pramuat, dan dapat menunda waktu yang diperlukan untuk menemukan referensi ke suatu gambar, mendownloadnya, mendekodenya, dan menyajikannya. Mari kita ambil markup gambar ini sebagai contoh:
<img data-src="/sand-wasp.jpg" alt="Sand Wasp" width="384" height="255">
Penggunaan awalan data- adalah pola umum dalam loader lambat yang didukung JavaScript. Saat gambar di-scroll ke area pandang, loader lambat akan menghapus awalan data-, yang berarti dalam contoh sebelumnya, data-src menjadi src. Update ini meminta browser untuk mengambil resource.
Pola ini tidak akan bermasalah hingga diterapkan ke gambar yang berada di area pandang selama startup. Karena pemindai pramuat tidak membaca atribut data-src dengan cara yang sama seperti atribut src (atau srcset), referensi gambar tidak ditemukan sebelumnya. Selain itu, pemuatan gambar tertunda hingga setelah JavaScript loader lambat mendownload, mengompilasi, dan dieksekusi.
Bergantung pada ukuran gambar—yang mungkin bergantung pada ukuran area pandang—ini mungkin merupakan elemen kandidat untuk Largest Contentful Paint (LCP). Jika pemindai pramuat tidak dapat mengambil resource gambar secara spekulatif di awal—mungkin pada saat rendering blok stylesheet halaman mengalami LCP.
Solusinya adalah mengubah markup gambar:
<img src="/sand-wasp.jpg" alt="Sand Wasp" width="384" height="255">
Ini adalah pola optimal untuk gambar yang berada di area pandang selama startup, karena pemindai pramuat akan menemukan dan mengambil resource gambar dengan lebih cepat.
Hasil dalam contoh yang disederhanakan ini adalah peningkatan 100 milidetik dalam LCP pada koneksi yang lambat. Hal ini mungkin tidak terlihat seperti peningkatan yang signifikan, tetapi ketika Anda menganggap bahwa solusinya adalah perbaikan markup yang cepat, dan sebagian besar halaman web lebih kompleks daripada kumpulan contoh ini. Artinya, kandidat LCP mungkin harus bersaing untuk mendapatkan bandwidth dengan banyak sumber daya lain, sehingga pengoptimalan seperti ini menjadi semakin penting.
Gambar latar CSS
Perlu diingat bahwa pemindai pramuat browser akan memindai markup. Metode ini tidak memindai jenis resource lain, seperti CSS yang mungkin melibatkan pengambilan gambar yang direferensikan oleh properti background-image.
Seperti HTML, browser memproses CSS ke dalam model objeknya sendiri, yang dikenal sebagai CSSOM. Jika ditemukan sumber daya eksternal saat dibangun, sumber daya itu akan diminta pada saat penemuan, dan bukan oleh pemindai pramuat.
Misalkan Kandidat LCP halaman Anda adalah elemen dengan properti background-image CSS. Berikut yang akan terjadi saat resource dimuat:
background-image CSS (baris 3). Gambar yang diminta tidak akan mulai diambil hingga parser CSS menemukannya.
Dalam hal ini, pemindai pramuat tidak terpengaruh jika tidak terlibat. Meski begitu, jika kandidat LCP di halaman berasal dari properti CSS background-image, Anda sebaiknya melakukan pramuat gambar tersebut:
<!-- Make sure this is in the <head> below any
stylesheets, so as not to block them from loading -->
<link rel="preload" as="image" href="lcp-image.jpg">
Petunjuk rel=preload tersebut memang kecil, tetapi membantu browser menemukan gambar lebih cepat daripada yang seharusnya:
background-image CSS (baris 3). Petunjuk rel=preload membantu browser menemukan gambar sekitar 250 milidetik lebih cepat daripada tanpa petunjuk.
Dengan petunjuk rel=preload, kandidat LCP ditemukan lebih cepat, sehingga mengurangi waktu LCP. Meskipun petunjuk tersebut membantu memperbaiki masalah ini, opsi yang lebih baik mungkin adalah menilai apakah kandidat LCP gambar Anda harus dimuat dari CSS atau tidak. Dengan tag <img>, Anda akan memiliki kontrol lebih besar untuk memuat gambar yang sesuai dengan area tampilan sekaligus memungkinkan pemindai pramuat menemukannya.
Membuat terlalu banyak resource menjadi inline
Menyejajarkan adalah praktik yang menempatkan sumber daya di dalam HTML. Anda dapat membuat stylesheet inline dalam elemen <style>, skrip di elemen <script>, dan hampir semua resource lain menggunakan encoding base64.
Menyisipkan resource dapat lebih cepat daripada mendownloadnya karena permintaan terpisah tidak dikeluarkan untuk resource tersebut. Foto tersebut langsung ada di dokumen dan langsung dimuat. Namun, ada kelemahan yang signifikan:
- Jika Anda tidak meng-cache HTML—dan Anda tidak bisa melakukannya jika respons HTML dinamis—resource inline tidak akan pernah di-cache. Hal ini memengaruhi performa karena resource inline tidak dapat digunakan kembali.
- Meskipun Anda dapat meng-cache HTML, resource inline tidak dibagikan antardokumen. Tindakan ini akan mengurangi efisiensi caching dibandingkan dengan file eksternal yang dapat di-cache dan digunakan kembali di seluruh origin.
- Jika terlalu banyak inline, pemindai pramuat tidak akan dapat menemukan resource dalam dokumen karena mendownload konten tambahan dan inline tersebut akan memerlukan waktu lebih lama.
Lihat halaman ini sebagai contoh. Dalam kondisi tertentu, kandidat LCP adalah gambar di bagian atas halaman, dan CSS berada dalam file terpisah yang dimuat oleh elemen <link>. Halaman ini juga menggunakan empat font web yang diminta sebagai file terpisah dari resource CSS.
<img>, tetapi ditemukan oleh pemindai pramuat karena CSS dan font yang diperlukan untuk memuat halaman di resource terpisah, yang tidak menunda pemindai pramuat melakukan tugasnya.
Sekarang, apa yang terjadi jika CSS dan semua font disisipkan sebagai resource base64?
<img>, tetapi inline CSS dan keempat resource font-nya di `` akan menunda pemindai pramuat menemukan gambar hingga resource tersebut didownload sepenuhnya.
Dampak inline menghasilkan konsekuensi negatif bagi LCP dalam contoh ini—dan untuk performa secara umum. Versi halaman yang tidak menyisipkan apa pun akan menampilkan gambar LCP dalam waktu sekitar 3,5 detik. Halaman yang menyisipkan semuanya tidak menampilkan gambar LCP hingga lebih dari 7 detik.
Ada banyak hal lain yang berperan di sini daripada pemindai pramuat. Menyisipkan font bukanlah strategi yang bagus karena base64 adalah format yang tidak efisien untuk resource biner. Faktor lain yang berperan adalah bahwa sumber daya font eksternal tidak diunduh kecuali dianggap diperlukan oleh GCLID. Jika font tersebut disisipkan sebagai base64, font tersebut akan didownload baik saat diperlukan untuk halaman saat ini maupun tidak.
Apakah pramuat dapat meningkatkan berbagai hal di sini? Oke. Anda dapat melakukan pramuat gambar LCP dan mengurangi waktu LCP, tetapi membengkak HTML Anda yang mungkin tidak dapat disimpan dalam cache dengan resource inline akan memiliki konsekuensi performa negatif lainnya. First Contentful Paint (FCP) juga terpengaruh oleh pola ini. Pada versi halaman di mana tidak ada yang disisipkan, FCP sekitar 2,7 detik. Dalam versi di mana semuanya disisipkan, FCP sekitar 5,8 detik.
Hati-hati saat menyisipkan item ke dalam HTML, terutama resource berenkode base64. Secara umum, tindakan ini tidak direkomendasikan, kecuali untuk resource yang sangat kecil. Sesedikit mungkin inline, karena terlalu banyak menyisipkan inline akan membuat Anda bersemangat.
Markup rendering dengan JavaScript sisi klien
Tidak diragukan lagi: JavaScript sangat memengaruhi kecepatan halaman. Developer tidak hanya mengandalkannya untuk menyediakan interaktivitas, tetapi juga terdapat kecenderungan untuk mengandalkannya untuk menayangkan konten itu sendiri. Hal ini akan memberikan pengalaman developer yang lebih baik dalam beberapa hal, tetapi manfaat bagi developer tidak selalu memberikan manfaat bagi pengguna.
Salah satu pola yang dapat mengalahkan pemindai pramuat adalah merender markup dengan JavaScript sisi klien:
Saat payload markup dimuat dan dirender sepenuhnya oleh JavaScript di browser, resource apa pun dalam markup tersebut secara efektif tidak terlihat oleh pemindai pramuat. Hal ini menunda penemuan resource penting, yang tentu saja memengaruhi LCP. Dalam kasus contoh ini, permintaan untuk gambar LCP sangat tertunda jika dibandingkan dengan pengalaman setara yang dirender oleh server yang tidak memerlukan JavaScript untuk muncul.
Hal ini sedikit menyimpang dari fokus artikel ini, tetapi efek rendering markup pada klien jauh lebih dari sekadar mengalahkan pemindai pramuat. Pertama, memperkenalkan JavaScript untuk mendukung pengalaman yang tidak memerlukan waktu pemrosesan yang tidak perlu, yang dapat memengaruhi Interaction to Next Paint (INP). Merender markup dalam jumlah yang sangat besar pada klien lebih cenderung menghasilkan tugas yang panjang dibandingkan dengan jumlah markup yang dikirim oleh server dalam jumlah yang sama. Alasan untuk hal ini—selain pemrosesan tambahan yang melibatkan JavaScript—adalah bahwa browser melakukan streaming markup dari server dan memotong proses rendering sedemikian rupa sehingga cenderung membatasi tugas yang berjalan lama. Di sisi lain, markup yang dirender klien ditangani sebagai tugas monolitik tunggal, yang dapat memengaruhi INP halaman.
Solusi untuk skenario ini bergantung pada jawaban atas pertanyaan ini: Apakah ada alasan mengapa markup halaman Anda tidak dapat disediakan oleh server dibandingkan dengan dirender di klien? Jika jawabannya adalah "tidak", rendering sisi server (SSR) atau markup yang dihasilkan secara statis harus dipertimbangkan jika memungkinkan, karena akan membantu pemindai pramuat untuk menemukan dan mengambil resource penting secara oportunistik jauh-jauh hari.
Jika halaman Anda membutuhkan JavaScript untuk melampirkan fungsi ke beberapa bagian markup halaman, Anda masih dapat melakukannya dengan SSR, baik dengan vanilla JavaScript, maupun hidrasi untuk mendapatkan manfaat terbaik dari keduanya.
Bantu pemindai pramuat membantu Anda
Pemindai pramuat adalah pengoptimalan browser yang sangat efektif yang membantu halaman dimuat lebih cepat selama startup. Dengan menghindari pola yang mengalahkan kemampuannya untuk menemukan sumber daya penting sebelumnya, Anda tidak hanya menyederhanakan pengembangan untuk diri sendiri, Anda juga menciptakan pengalaman pengguna yang lebih baik yang akan memberikan hasil yang lebih baik dalam banyak metrik, termasuk beberapa data web.
Sebagai ringkasan, berikut hal-hal yang perlu Anda perhatikan dari postingan ini:
- Pemindai pramuat browser adalah parser HTML sekunder yang memindai terlebih dahulu parser utama jika diblokir untuk menemukan resource secara oportunistik yang dapat diambil lebih cepat.
- Resource yang tidak ada dalam markup yang disediakan oleh server pada permintaan navigasi awal tidak dapat ditemukan oleh pemindai pramuat. Cara mengatasi pemindai pramuat dapat mencakup (tetapi tidak terbatas pada):
- Menginjeksikan resource ke dalam DOM dengan JavaScript, baik berupa skrip, gambar, stylesheet, maupun apa pun yang akan lebih baik dalam payload markup awal dari server.
- Pemuatan lambat gambar paruh atas atau iframe menggunakan solusi JavaScript.
- Markup rendering pada klien yang mungkin berisi referensi ke subresource dokumen menggunakan JavaScript.
- Pemindai pramuat hanya memindai HTML. Laporan ini tidak memeriksa konten resource lain—terutama CSS—yang mungkin menyertakan referensi ke aset penting, termasuk kandidat LCP.
Jika, karena alasan apa pun, Anda tidak dapat menghindari pola yang berdampak negatif terhadap kemampuan pemindai pramuat untuk mempercepat performa pemuatan, pertimbangkan petunjuk resource rel=preload. Jika Anda menggunakan menggunakan rel=preload, lakukan pengujian di alat lab untuk memastikan bahwa alat tersebut memberi Anda efek yang diinginkan. Terakhir, jangan melakukan pramuat terlalu banyak resource, karena jika Anda memprioritaskan semuanya, tidak akan ada yang diprioritaskan.
Referensi
- "Skrip asinkron" yang dimasukkan skrip dianggap berbahaya
- Cara Pra-pemuat Browser Membuat Halaman Pemuatan Lebih Cepat
- Pramuat aset penting untuk meningkatkan kecepatan pemuatan
- Membuat koneksi jaringan lebih awal untuk meningkatkan kecepatan halaman yang dirasakan
- Mengoptimalkan Largest Contentful Paint (LCP)
Banner besar dari Unsplash, oleh Mohammad Rahmani .