Cari tahu apa itu pemindai pramuat pada browser, bagaimana software ini membantu performa, dan bagaimana Anda dapat menghindari hal yang tidak diinginkan.
Satu aspek yang diabaikan dalam pengoptimalan kecepatan halaman adalah Anda perlu mengetahui sedikit tentang internal browser. Browser melakukan pengoptimalan tertentu untuk meningkatkan performa dengan cara yang tidak dapat dilakukan oleh developer, tetapi hanya selama pengoptimalan tersebut tidak terhambat secara tidak sengaja.
Satu pengoptimalan browser internal yang perlu dipahami adalah pemindai pramuat browser. Postingan ini akan membahas cara kerja pemindai pramuat—dan yang lebih penting, bagaimana Anda dapat menghindari halangan.
Apa itu pemindai pramuat?
Setiap browser memiliki parser HTML utama yang membuat token markup mentah dan memprosesnya menjadi model objek. Semua ini berlangsung dengan senang hati hingga parser dijeda saat menemukan resource pemblokiran, 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 sisa dokumen—atau bahkan merendernya—hingga CSS didownload dan diuraikan.
Dalam kasus file CSS, penguraian dan rendering akan diblokir untuk mencegah flash konten tidak bergaya (FOUC), yaitu saat versi halaman yang tidak bergaya dapat dilihat sebentar sebelum gaya diterapkan.
Browser juga memblokir penguraian dan rendering halaman saat menemukan elemen <script> tanpa atribut defer atau async.
Alasan untuk hal ini adalah browser tidak dapat mengetahui secara pasti apakah skrip yang diberikan akan memodifikasi DOM saat parser HTML utama masih melakukan tugasnya. Ini adalah praktik umum untuk memuat JavaScript di akhir dokumen sehingga efek penguraian dan rendering yang diblokir menjadi sedikit.
Ini adalah alasan bagus mengapa browser harus memblokir penguraian dan rendering. Namun, memblokir salah satu langkah penting ini tidak diinginkan, karena dapat menunda acara dengan menunda penemuan sumber daya penting lainnya. Untungnya, browser melakukan yang terbaik untuk mengurangi masalah ini dengan parser HTML sekunder yang disebut pemindai pramuat.
<body>, tetapi pemindai pramuat dapat melihat ke depan pada markup mentah untuk menemukan resource gambar tersebut dan mulai memuatnya sebelum parser HTML utama diblokir.
Peran pemindai pramuat bersifat spekulatif, artinya fungsi ini memeriksa markup mentah untuk menemukan resource yang dapat diambil secara oportunistik sebelum parser HTML utama menemukannya.
Cara mengetahui kapan 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 mengetahui apakah halaman web mendapatkan manfaat dari pemindai pramuat bergantung pada fenomena pemblokiran ini. Untuk melakukannya, Anda bisa memasukkan penundaan buatan untuk permintaan guna menemukan di mana pemindai pramuat berfungsi.
Ambil halaman ini yang berisi teks dan gambar dasar dengan stylesheet sebagai contoh. Karena file CSS memblokir rendering dan penguraian, Anda menerapkan penundaan buatan selama dua detik untuk stylesheet melalui layanan proxy. Penundaan ini akan memudahkan kita melihat di waterfall jaringan tempat pemindai pramuat berfungsi.
Seperti yang dapat Anda lihat di waterfall, pemindai pramuat akan menemukan elemen <img> bahkan saat rendering dan penguraian dokumen diblokir. Tanpa pengoptimalan ini, browser tidak dapat mengambil objek secara oportunistik selama periode pemblokiran, dan permintaan resource akan lebih banyak berturut-turut, bukan serentak.
Dengan menyisakan contoh sederhana tersebut, mari kita lihat beberapa pola di dunia nyata di mana pemindai pramuat dapat dikalahkan—dan apa yang dapat dilakukan untuk memperbaikinya.
async skrip telah dimasukkan
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 dimasukkan adalah async secara default, sehingga saat skrip ini dimasukkan, skrip akan berperilaku seolah-olah atribut async diterapkan padanya. Artinya, proses rendering akan berjalan sesegera mungkin dan tidak memblokir rendering. Kedengarannya optimal, kan? Namun, jika Anda menganggap bahwa <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 skrip diinjeksikan di klien.
Mari kita uraikan apa yang terjadi di sini:
- Pada 0 detik, dokumen utama akan diminta.
- Pada 1,4 detik, byte pertama dari permintaan navigasi tiba.
- Pada detik 2,0, CSS dan gambar akan diminta.
- Karena parser diblokir untuk memuat stylesheet dan JavaScript inline yang memasukkan skrip
asyncmuncul setelah stylesheet tersebut berada dalam waktu 2,6 detik, fungsi yang disediakan oleh skrip tidak tersedia sesegera mungkin.
Hal ini kurang optimal karena permintaan skrip hanya terjadi setelah stylesheet selesai didownload. Tindakan ini menunda skrip untuk berjalan sesegera mungkin. 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> reguler dengan atribut async, bukan memasukkan skrip ke dalam DOM?
<script src="/yall.min.js" async></script>
Ini hasilnya:
async <script>. Pemindai pramuat menemukan skrip selama fase pemblokiran render, dan memuatnya bersamaan dengan CSS.
Mungkin ada beberapa godaan untuk menunjukkan bahwa masalah ini dapat diperbaiki menggunakan rel=preload. Cara ini pasti berhasil, tetapi mungkin memiliki 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 ditemukan lebih cepat.
Pramuat "memperbaiki" masalah di sini, tetapi hal ini memunculkan masalah baru: skrip async dalam dua demo pertama—meskipun dimuat di <head>—dimuat dengan prioritas "Rendah", sedangkan stylesheet dimuat dengan prioritas "Tertinggi". Di demo terakhir tempat skrip async dipramuat, stylesheet masih dimuat dengan prioritas "Tertinggi", tetapi prioritas skrip telah dipromosikan ke "Tinggi".
Jika prioritas resource dinaikkan, browser akan mengalokasikan lebih banyak bandwidth. 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 sangat mudah: jika skrip dibutuhkan selama startup, jangan kalahkan pemindai pramuat dengan memasukkannya ke dalam DOM. Lakukan eksperimen sesuai kebutuhan dengan penempatan elemen <script>, serta dengan atribut seperti defer dan async.
Pemuatan lambat dengan JavaScript
Pemuatan lambat adalah metode yang bagus untuk menghemat data, dan sering diterapkan pada gambar. Namun, terkadang pemuatan lambat salah diterapkan pada gambar yang berada "di paruh atas".
Hal ini berpotensi menimbulkan masalah terkait visibilitas resource yang berkaitan 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 yang umum dalam lazy loader yang didukung JavaScript. Saat gambar di-scroll ke area pandang, lazy loader menghapus awalan data-, yang berarti bahwa pada contoh sebelumnya, data-src menjadi src. Update ini akan meminta browser untuk mengambil resource.
Pola ini tidak 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 lebih awal. Selain itu, gambar tertunda dimuat hingga setelah JavaScript lazy loader didownload, dikompilasi, dan dieksekusi.
Bergantung pada ukuran gambar—yang mungkin bergantung pada ukuran area pandang—gambar tersebut mungkin merupakan elemen kandidat untuk Largest Contentful Paint (LCP). Jika pemindai pramuat tidak dapat mengambil resource gambar secara spekulatif sebelumnya—mungkin selama titik saat rendering blok stylesheet halaman akan terganggu.
Solusinya adalah dengan mengubah markup gambar:
<img src="/sand-wasp.jpg" alt="Sand Wasp" width="384" height="255">
Pola ini optimal untuk gambar yang ada di area pandang selama startup, karena pemindai pramuat akan menemukan dan mengambil resource gambar dengan lebih cepat.
Hasil dari contoh yang disederhanakan ini adalah peningkatan LCP sebesar 100 milidetik pada koneksi yang lambat. Hal ini mungkin tidak terlihat seperti peningkatan yang besar, tetapi ketika Anda menganggap bahwa solusinya adalah perbaikan markup yang cepat, dan sebagian besar halaman web lebih kompleks daripada rangkaian contoh ini. Artinya, kandidat LCP mungkin harus bersaing mendapatkan bandwidth dengan banyak resource lain, sehingga pengoptimalan seperti ini menjadi semakin penting.
Gambar latar CSS
Perlu diingat bahwa pemindai pramuat browser akan memindai markup. API ini tidak memindai jenis resource lain, seperti CSS yang mungkin melibatkan pengambilan gambar yang dirujuk oleh properti background-image.
Seperti HTML, browser memproses CSS ke dalam model objeknya sendiri, yang dikenal sebagai CSSOM. Jika sumber daya eksternal ditemukan saat WebView dibuat, sumber daya tersebut akan diminta pada saat penemuan, dan bukan oleh pemindai pramuat.
Misalnya kandidat LCP halaman Anda adalah elemen dengan properti background-image CSS. Berikut adalah hal yang terjadi saat resource dimuat:
background-image CSS (baris 3). Gambar yang diminta tidak mulai diambil hingga parser CSS menemukannya.
Dalam hal ini, pemindai pramuat tidak terlalu dikalahkan karena tidak terlibat. Meskipun demikian, jika kandidat LCP di halaman berasal dari properti CSS background-image, Anda dapat 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 kecil, tetapi membantu browser menemukan gambar lebih cepat daripada biasanya:
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 menurunkan waktu LCP. Meskipun petunjuk tersebut dapat 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 atas pemuatan gambar yang sesuai untuk area tampilan sekaligus memungkinkan pemindai pramuat untuk menemukannya.
Menyejajarkan terlalu banyak sumber daya
{i>Inline<i} adalah praktik yang menempatkan sumber daya di dalam HTML. Anda dapat membuat spreadsheet inline di elemen <style>, skrip di elemen <script>, dan hampir semua resource lainnya menggunakan encoding base64.
Penyertaan resource bisa lebih cepat daripada mendownloadnya karena permintaan terpisah tidak dikeluarkan untuk resource. File ada di dokumen dan langsung dimuat. Namun, ada beberapa kekurangan yang signifikan:
- Jika Anda tidak meng-cache HTML—dan Anda tidak bisa melakukannya jika respons HTML bersifat dinamis—sumber daya inline tidak pernah disimpan dalam cache. Hal ini memengaruhi performa karena resource inline tidak dapat digunakan kembali.
- Meskipun Anda bisa meng-cache HTML, resource inline tidak dibagikan antar dokumen. Hal ini mengurangi efisiensi penyimpanan dalam cache dibandingkan file eksternal yang dapat di-cache dan digunakan kembali di seluruh origin.
- Jika Anda terlalu sering inline, tindakan ini akan menunda pemindai pramuat agar tidak menemukan resource di lain waktu dalam dokumen, karena mendownload konten ekstra yang bersifat inline 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 pemuatan 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 empat resource fontnya di `` menunda pemindai pramuat menemukan gambar hingga resource tersebut didownload sepenuhnya.
Dampak dari penyisipan menghasilkan konsekuensi negatif bagi LCP dalam contoh ini—dan performa secara umum. Versi halaman yang tidak menyisipkan apa pun akan menggambar gambar LCP dalam waktu sekitar 3,5 detik. Halaman yang menyejajarkan semuanya tidak akan menggambar gambar LCP hingga lebih dari 7 detik.
Ada lebih banyak hal yang berperan di sini selain pemindai pramuat. Menyejajarkan font bukan strategi yang bagus karena base64 adalah format yang tidak efisien untuk resource biner. Faktor lain yang berperan adalah resource font eksternal tidak didownload kecuali jika resource tersebut ditentukan diperlukan oleh WebView. Jika font tersebut disejajarkan sebagai base64, font tersebut akan didownload, baik diperlukan untuk halaman saat ini maupun tidak.
Dapatkah pramuat meningkatkan kualitasnya di sini? Oke. Anda dapat melakukan pramuat gambar LCP dan mengurangi waktu LCP, tetapi membengkakkan HTML yang berpotensi tidak dapat disimpan dalam cache dengan resource inline dapat menimbulkan konsekuensi performa negatif lainnya. First Contentful Paint (FCP) juga terpengaruh oleh pola ini. Di versi halaman yang tidak berisi inline, FCP sekitar 2,7 detik. Dalam versi di mana semuanya inline, FCP sekitar 5,8 detik.
Hati-hati dengan menyisipkan barang ke dalam HTML, terutama sumber daya berenkode base64. Secara umum, tindakan ini tidak direkomendasikan, kecuali untuk resource yang sangat kecil. Sejajarkan seminimal mungkin, karena membuat terlalu banyak menyisipkan akan bermain dengan api.
Merender markup dengan JavaScript sisi klien
Tidak diragukan lagi: JavaScript sangat memengaruhi kecepatan halaman. Developer tidak hanya mengandalkan platform ini untuk menyediakan interaktivitas, tetapi juga ada kecenderungan untuk mengandalkannya dalam menayangkan konten itu sendiri. Hal ini memberikan pengalaman developer yang lebih baik dalam beberapa hal; tetapi manfaat bagi developer tidak selalu berarti manfaat bagi pengguna.
Salah satu pola yang dapat mengalahkan pemindai pramuat adalah merender markup dengan JavaScript sisi klien:
Ketika payload markup ditampung dan di-render sepenuhnya oleh JavaScript di browser, resource apa pun di 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 gambar LCP sangat tertunda jika dibandingkan dengan pengalaman setara yang dirender 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. Salah satunya, memperkenalkan JavaScript untuk mendukung pengalaman tanpa mengharuskan Anda menghabiskan waktu pemrosesan yang tidak perlu yang dapat memengaruhi Interaction to Next Paint (INP).
Selain itu, merender markup dalam jumlah yang sangat besar pada klien lebih cenderung menghasilkan tugas yang lama dibandingkan dengan jumlah markup yang sama yang dikirim oleh server. Alasannya—selain pemrosesan ekstra yang melibatkan JavaScript—adalah karena browser mengalirkan markup dari server dan membagi rendering sedemikian rupa sehingga menghindari tugas yang berjalan lama. Di sisi lain, markup yang dirender klien ditangani sebagai tugas monolitik tunggal, yang dapat memengaruhi metrik responsivitas halaman seperti Total Blocking Time (TBT) atau Penundaan Input Pertama (FID) selain INP.
Upaya hukum untuk skenario ini bergantung pada jawaban atas pertanyaan ini: Apakah ada alasan mengapa markup halaman Anda tidak dapat diberikan oleh server sehingga tidak dirender di klien? Jika jawabannya adalah "tidak", rendering sisi server (SSR) atau markup yang dihasilkan secara statis harus dipertimbangkan jika memungkinkan, karena ini akan membantu pemindai pramuat untuk menemukan dan mengambil resource penting terlebih dahulu.
Jika halaman Anda memerlukan JavaScript untuk melampirkan fungsi ke beberapa bagian markup halaman, Anda masih dapat melakukannya dengan SSR, baik dengan JavaScript biasa, maupun hidrasi untuk mengoptimalkan penggunaan keduanya.
Bantu pemindai pramuat membantu Anda
Pemindai pramuat adalah pengoptimalan browser yang sangat efektif untuk membantu halaman dimuat lebih cepat selama startup. Dengan menghindari pola yang mengurangi kemampuannya untuk menemukan resource penting lebih awal, Anda tidak hanya menyederhanakan proses pengembangan, melainkan juga menciptakan pengalaman pengguna yang lebih baik dan memberikan hasil yang lebih baik dalam banyak metrik, termasuk beberapa data web.
Sebagai rangkuman, berikut adalah hal-hal yang perlu Anda ingat dari postingan ini:
- Pemindai pramuat browser adalah parser HTML sekunder yang memindai sebelum parser utama jika diblokir untuk menemukan sumber daya secara oportunistik yang dapat diambil lebih cepat.
- Resource yang tidak ada di 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):
- Memasukkan sumber daya ke dalam DOM dengan JavaScript, baik itu skrip, gambar, stylesheet, atau apa pun yang akan lebih baik di dalam payload markup awal dari server.
- Pemuatan lambat untuk gambar paruh atas atau iframe menggunakan solusi JavaScript.
- Merender markup 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 mencakup referensi ke aset penting, termasuk kandidat LCP.
Jika karena alasan apa pun, Anda tidak dapat menghindari pola yang berpengaruh negatif terhadap kemampuan pemindai pramuat untuk mempercepat performa pemuatan, pertimbangkan petunjuk resource rel=preload. Jika Anda menggunakan rel=preload, lakukan pengujian di alat lab untuk memastikan bahwa rel=preload memberi Anda efek yang diinginkan. Terakhir, jangan melakukan pramuat terlalu banyak sumber daya, karena ketika Anda memprioritaskan semuanya, tidak akan ada yang terjadi.
Referensi
- "Skrip asinkron" yang berisi skrip dianggap berbahaya
- Cara Pra-pemuat Browser Membuat Pemuatan Halaman Lebih Cepat
- Pramuat aset penting untuk meningkatkan kecepatan pemuatan
- Buat koneksi jaringan lebih awal untuk meningkatkan kecepatan halaman yang dirasakan
- Mengoptimalkan Largest Contentful Paint (LCP)
Banner besar dari Unsplash, oleh Mohammad Rahmani .