Menghapus Download yang Tidak Diperlukan

Resource tercepat dan paling dioptimalkan adalah resource yang tidak dikirim. Anda harus menghilangkan resource yang tidak perlu dari aplikasi. Praktik yang baik adalah untuk mempertanyakan, dan secara berkala meninjau kembali, asumsi implisit dan eksplisit dengan tim Anda. Berikut beberapa contohnya:

  • Anda selalu menyertakan sumber daya X di halaman, namun apakah biaya mengunduh dan menampilkannya sepadan dengan nilai yang diberikannya kepada pengguna? Bisakah Anda mengukur dan membuktikan nilainya?
  • Apakah sumber daya tersebut (terutama jika itu adalah sumber daya pihak ketiga) memberikan performa yang konsisten? Apakah sumber daya ini berada di jalur kritis, atau harus ada? Jika sumber daya ada di jalur kritis, mungkinkah itu merupakan titik tunggal kegagalan untuk situs? Artinya, jika sumber daya tidak tersedia, apakah akan memengaruhi performa dan pengalaman pengguna halaman Anda?
  • Apakah sumber daya ini memerlukan atau memiliki SLA? Apakah referensi ini mengikuti praktik terbaik performa: kompresi, penyimpanan cache, dan sebagainya?

Sering kali, halaman berisi aset yang tidak diperlukan, atau lebih buruk lagi, yang menghambat performa halaman tanpa memberikan banyak nilai kepada pengunjung atau situs tempat halaman dihosting. Hal ini berlaku juga 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 cepat. Semua foto dimuat saat halaman dimuat, dan pengguna dapat melihat-lihat foto-foto yang ada.
    • Pertanyaan: Pernahkah Anda mengukur jumlah pengguna yang melihat beberapa foto dalam 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 untuk menampilkan konten terkait, meningkatkan interaksi sosial, atau menyediakan beberapa layanan lain.
    • Pertanyaan: Apakah Anda telah melacak jumlah pengunjung yang menggunakan widget atau mengklik konten yang disediakan widget? Apakah interaksi yang dihasilkan widget ini cukup untuk membenarkan 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 membutuhkan banyak pemikiran dan pengukuran yang cermat. Untuk 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 menyediakan kumpulan metrik yang mencerminkan apa yang dialami pengguna saat mereka menggunakan web. Meskipun ada banyak strategi pengoptimalan untuk Core Web Vitals, mempertanyakan apakah perlu memuat resource tertentu di halaman dapat memudahkan Anda dalam meningkatkan metrik ini di situs Anda. Berikut adalah beberapa contoh—yang dikelompokkan berdasarkan setiap Core Web Vitals—yang layak Anda pertimbangkan. Meskipun contoh-contoh ini tidaklah lengkap (dan ada banyak sekali!), contoh-contoh tersebut dapat membantu Anda berpikir.

Largest Contentful Paint (LCP)

Largest Contentful Paint (LCP) mengukur saat konten terbesar (misalnya, banner besar, atau judul) dimuat. Hal ini dianggap sebagai metrik persepsi penting yang memberikan kesan kepada pengguna bahwa situs dimuat dengan cepat.

Secara umum, mendownload lebih sedikit resource berarti bandwidth yang dimiliki pengguna akan dialokasikan ke lebih sedikit resource, dan dapat berarti peningkatan LCP. Contoh klasiknya adalah pemuatan lambat, saat gambar di luar area pandang selama pemuatan halaman tidak akan didownload hingga browser menentukan bahwa pengguna lebih cenderung melihatnya. Jika Anda memiliki galeri thumbnail besar, katakanlah, 50 gambar, pemuatan lambat semuanya, tetapi sepuluh gambar teratas berarti browser dapat menggunakan bandwidth yang tersedia untuknya 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 seberapa banyak bandwidth yang harus diterima setiap resource. Namun, meski dengan semua resource ini—terutama yang didownload pada prioritas tinggi—tetap berpotensi mengurangi resource dependen elemen LCP yang potensial. Hal ini terutama berlaku pada koneksi jaringan yang lambat. Resource dependen tersebut mungkin berupa file gambar yang mewakili elemen LCP halaman, tetapi juga bisa berupa resource font web yang diperlukan browser untuk merender node teks yang dapat ditentukan sebagai elemen LCP halaman.

Jika banyak teks yang muncul di situs Anda, mungkin elemen LCP halaman berupa node teks. Meskipun ada banyak strategi pemuatan dan pengoptimalan font yang baik, sebaiknya pertimbangkan apakah font sistem sudah memadai untuk kebutuhan situs Anda, sehingga elemen LCP yang merupakan node teks dapat dimuat tanpa dependensi pada resource font web dan akan langsung menggambar saat CSS dan HTML tiba dari server.

Pergeseran Tata Letak Kumulatif (CLS)

Setiap resource yang Anda muat memiliki potensi untuk berkontribusi pada Pergeseran Tata Letak Kumulatif (CLS) halaman, terutama jika belum selesai didownload pada saat penggambaran awal. Untuk gambar, hindari CLS melibatkan praktik seperti menyetel 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 bagaimana skrip itu memanipulasi DOM sehingga pergeseran tata letak dikurangi ke jumlah yang dapat diterima.

Setiap resource yang berkontribusi pada CLS halaman memerlukan sejumlah upaya untuk memastikan tata letak halaman cukup stabil. Dengan mempertanyakan apakah memerlukan sumber daya tertentu atau tidak, Anda tidak hanya mempercepat pemuatan halaman, tetapi juga mengurangi upaya kognitif yang diperlukan untuk menjaga stabilitas tata letak. Hal ini tidak hanya mengurangi pengalaman pengguna yang membuat frustrasi, tetapi juga pengalaman developer yang tidak terlalu frustrasi, karena Anda akan memiliki lebih banyak waktu untuk mengejar tujuan lain dalam proyek Anda.

Interaksi dengan Next Paint (INP)

Interaction to Next Paint (INP) mengukur responsivitas terhadap input pengguna sepanjang masa aktif halaman. INP halaman dapat sangat dipengaruhi oleh JavaScript yang dimuatnya, karena JavaScript yang mendorong sebagian besar interaktivitas yang dialami suatu pengalaman di web. Khususnya, jumlah resource skrip yang didownload selama pemuatan halaman dapat memulai pekerjaan yang berpotensi mahal dalam evaluasi dan kompilasi skrip. Makin sedikit JavaScript yang Anda muat selama startup, makin sedikit pekerjaan yang harus dilakukan browser pada titik penting tersebut dalam pengalaman halaman, tempat 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 diperlukan atau tidak. Misalnya, lodash memiliki banyak metode yang masih berguna hingga saat ini, tetapi disertakan dengan metode yang langsung disediakan browser, seperti fungsi khusus Array untuk pemetaan, pengurangan, dan pemfilteran, dan banyak lainnya.

Peningkatan progresif juga merupakan pendekatan yang berguna untuk JavaScript, karena memungkinkan Anda menyajikan pengalaman dasar (tetapi masih berfungsi) 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 peningkatan progresif atau tidak, intinya tetap: Setiap sumber daya JavaScript yang dapat Anda hindari mengunduh dapat menghasilkan pengalaman yang merespons interaksi pengguna lebih cepat, yang merupakan aspek penting dari kinerja web.

Kesimpulan

Mengaudit situs web untuk hasil download yang tidak perlu mungkin hanya salah satu aspek dalam memberikan pengalaman pengguna yang cepat, namun tetap memiliki potensi dampak yang tinggi. Ringkasnya:

  • Inventarisasi aset Anda sendiri dan aset pihak ketiga di halaman Anda.
  • Ukur performa setiap aset: nilai dan performa teknisnya.
  • Tentukan apakah sumber daya menyediakan nilai yang memadai.
  • Memahami dampak download yang tidak diperlukan terhadap Core Web Vitals dan metrik pendukung.

Dengan mengoptimalkan efisiensi konten melalui cara ini, Anda tidak hanya meningkatkan performa secara keseluruhan, Anda juga berhati-hati agar tidak membuang-buang bandwidth pengguna, serta berpotensi meningkatkan metrik yang berpusat pada pengguna dan memberikan pengalaman pengguna yang lebih baik.