Resource tercepat dan paling optimal adalah resource yang tidak dikirim. Anda harus menghapus resource yang tidak diperlukan dari aplikasi. Sebaiknya pertanyakan, dan tinjau kembali secara berkala, asumsi implisit dan eksplisit bersama tim Anda. Berikut adalah beberapa contohnya:
- Anda selalu menyertakan resource X di halaman, tetapi apakah biaya untuk mendownload dan menampilkannya sebanding dengan nilai yang diberikan kepada pengguna? Dapatkah Anda mengukur dan membuktikan nilainya?
- Apakah resource (terutama jika merupakan resource pihak ketiga) memberikan performa yang konsisten? Apakah resource ini berada di jalur kritis, atau perlu berada di jalur kritis? Jika resource berada di jalur penting, mungkinkah resource tersebut menjadi titik tunggal kegagalan untuk situs? Artinya, jika resource tidak tersedia, apakah hal itu memengaruhi performa dan pengalaman pengguna halaman Anda?
- Apakah resource ini memerlukan atau memiliki SLA? Apakah resource ini mengikuti praktik terbaik performa: kompresi, penyimpanan dalam cache, dan sebagainya?
Sering kali, halaman berisi resource yang tidak diperlukan, atau lebih buruk lagi, yang menghambat performa halaman tanpa memberikan banyak nilai kepada pengunjung atau situs tempat halaman tersebut dihosting. Hal ini berlaku sama untuk resource dan widget pihak pertama dan pihak ketiga:
- Situs A memutuskan untuk menampilkan carousel foto di halaman berandanya agar pengunjung dapat melihat pratinjau beberapa foto dengan sekali klik. Semua foto dimuat saat halaman dimuat, dan pengguna melihat foto satu per satu.
- Pertanyaan: Apakah Anda sudah mengukur berapa banyak pengguna yang melihat beberapa foto di carousel? Anda mungkin menimbulkan overhead yang tinggi dengan mendownload resource yang tidak pernah dilihat oleh sebagian besar pengunjung.
- Situs B telah memutuskan untuk menginstal widget pihak ketiga guna menampilkan konten terkait, meningkatkan interaksi sosial, atau menyediakan layanan lainnya.
- Pertanyaan: Sudahkah Anda melacak jumlah pengunjung yang menggunakan widget atau mengklik konten yang disediakan widget? Apakah engagement yang dihasilkan widget ini cukup untuk mengimbangi overhead-nya? Selain itu, apakah Anda dapat menggunakan strategi pemuatan untuk memastikan skrip tidak dimuat hingga diperlukan?
Menentukan apakah akan menghilangkan download yang tidak perlu sering kali memerlukan banyak pemikiran dan pengukuran yang cermat. Untuk mendapatkan hasil terbaik, inventarisasi dan tinjau kembali pertanyaan ini secara berkala untuk setiap aset di halaman Anda.
Efek pada Core Web Vitals
Inisiatif Core Web Vitals diperkenalkan oleh Google untuk memberikan sekumpulan metrik yang mencerminkan pengalaman pengguna saat menggunakan web. Meskipun ada banyak strategi pengoptimalan untuk Core Web Vitals, mempertanyakan apakah akan memuat resource tertentu di halaman dapat membantu Anda meningkatkan metrik ini di situs Anda. Berikut beberapa contoh—yang dikelompokkan berdasarkan setiap Core Web Vital—yang perlu Anda pertimbangkan. Meskipun ini bukan daftar contoh yang lengkap (dan ada banyak contoh lainnya), membacanya dapat memberi Anda bahan pertimbangan.
Largest Contentful Paint (LCP)
Largest Contentful Paint (LCP) mengukur kapan konten terbesar (misalnya, banner besar atau judul) dimuat. Metrik ini dianggap sebagai metrik persepsi penting yang memberi pengguna kesan bahwa situs dimuat dengan cepat.
Secara umum, mendownload lebih sedikit resource berarti bandwidth yang dimiliki pengguna akan dialokasikan ke lebih sedikit resource, dan dapat menghasilkan peningkatan LCP. Contoh klasiknya adalah pemuatan lambat, yaitu gambar di luar area pandang selama pemuatan halaman tidak akan didownload hingga browser menentukan bahwa pengguna cenderung akan melihatnya. Jika Anda memiliki galeri thumbnail yang besar, misalnya, 50 gambar, pemuatan lambat untuk semua gambar kecuali sepuluh gambar teratas berarti browser dapat menggunakan bandwidth yang tersedia secara lebih efisien, dan gambar pertama yang akan dilihat pengguna akan dimuat lebih cepat.
Namun, ini bukan hanya tentang memuat lebih sedikit gambar. Browser memiliki skema prioritas internal yang menentukan jumlah bandwidth yang harus diterima setiap resource. Namun, meskipun demikian, semua resource—terutama yang didownload dengan prioritas tinggi—berpotensi menghabiskan resource dependen elemen LCP potensial. Hal ini terutama berlaku pada koneksi jaringan yang lambat. Resource dependen tersebut mungkin berupa file gambar yang mewakili elemen LCP halaman, tetapi bisa juga berupa resource font web yang diperlukan browser untuk merender node teks yang dapat ditentukan sebagai elemen LCP halaman.
Jika situs Anda banyak berisi teks, elemen LCP halaman mungkin berupa node teks. Meskipun ada banyak strategi pemuatan dan pengoptimalan font yang baik, sebaiknya pertimbangkan apakah font sistem sudah cukup untuk kebutuhan situs Anda, sehingga elemen LCP yang merupakan node teks dapat dimuat tanpa dependensi pada resource font web dan dirender hampir seketika saat CSS dan HTML tiba dari server.
Pergeseran Tata Letak Kumulatif (CLS)
Setiap resource yang Anda muat berpotensi berkontribusi pada Cumulative Layout Shift (CLS) halaman, terutama jika belum selesai didownload pada saat render awal. Untuk gambar, menghindari CLS melibatkan praktik seperti menetapkan dimensi eksplisit. Untuk font, mengelola pemuatan font dan kemungkinan pencocokan font pengganti dapat meminimalkan pergeseran selama periode pertukaran font web. Untuk JavaScript, hal ini dapat berupa mengelola cara skrip tersebut memanipulasi DOM sehingga pergeseran tata letak dikurangi hingga jumlah yang dapat diterima.
Setiap resource yang berkontribusi pada CLS halaman memerlukan sejumlah upaya untuk memastikan tata letak halaman cukup stabil. Dengan mempertanyakan apakah Anda memerlukan resource tertentu atau tidak, Anda tidak hanya mempercepat pemuatan halaman, tetapi juga mengurangi upaya kognitif yang diperlukan untuk mempertahankan stabilitas tata letak. Hal ini tidak hanya menghasilkan pengalaman pengguna yang jauh lebih menyenangkan, tetapi juga pengalaman developer yang lebih menyenangkan, karena Anda akan memiliki lebih banyak waktu untuk mengejar sasaran lain dalam project Anda.
Interaction to Next Paint (INP)
Interaction to Next Paint (INP) mengukur responsivitas terhadap input pengguna selama masa aktif halaman. INP halaman dapat sangat dipengaruhi oleh JavaScript yang dimuatnya, karena JavaScript adalah yang mendorong sebagian besar interaktivitas yang dialami pengguna di seluruh web. Secara khusus, jumlah resource skrip yang didownload selama pemuatan halaman dapat memulai pekerjaan yang berpotensi mahal yang terlibat dalam evaluasi dan kompilasi skrip. Semakin sedikit JavaScript yang Anda muat selama startup, semakin sedikit pekerjaan yang harus dilakukan browser pada titik penting dalam pengalaman halaman, saat pengguna mungkin mencoba berinteraksi dengannya.
Meskipun ada strategi untuk mengurangi ukuran resource JavaScript yang didownload selama startup—seperti pemisahan kode dan tree shaking—sebaiknya audit paket yang Anda gunakan dalam project untuk melihat apakah paket tersebut benar-benar diperlukan. Misalnya, lodash memiliki banyak metode yang masih berguna saat ini, tetapi dikirimkan dengan metode yang disediakan browser secara langsung, seperti fungsi khusus Array untuk pemetaan, pengurangan, dan pemfilteran, serta banyak lainnya.
Progressive enhancement juga merupakan pendekatan yang berguna untuk JavaScript, karena memungkinkan Anda menyajikan pengalaman dasar (tetapi masih fungsional) bagi pengguna yang dapat Anda tambahkan untuk pengguna dengan perangkat yang lebih canggih dan koneksi jaringan yang lebih cepat. Terlepas dari apakah Anda mematuhi prinsip progressive enhancement atau tidak, intinya tetap sama: Setiap resource JavaScript yang dapat Anda hindari untuk didownload dapat menghasilkan pengalaman yang merespons interaksi pengguna lebih cepat, yang merupakan aspek penting dari performa web.
Kesimpulan
Mengaudit situs Anda untuk download yang tidak perlu mungkin hanya salah satu aspek dalam memberikan pengalaman pengguna yang cepat, tetapi aspek ini berpotensi memberikan dampak yang besar. Ringkasnya:
- Inventarisasi aset Anda sendiri dan aset pihak ketiga di halaman Anda.
- Ukur performa setiap aset: nilai dan performa teknisnya.
- Tentukan apakah resource memberikan nilai yang memadai.
- Memahami efek download yang tidak perlu pada Core Web Vitals dan metrik pendukung.
Dengan mengoptimalkan efisiensi konten dengan cara ini, Anda tidak hanya meningkatkan performa secara keseluruhan, tetapi juga berhati-hati agar tidak menyia-nyiakan bandwidth pengguna, serta berpotensi meningkatkan metrik yang berfokus pada pengguna dan memberikan pengalaman pengguna yang lebih baik.