Menghapus Download yang Tidak Diperlukan

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

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

Sering kali, halaman berisi resource yang tidak perlu, atau lebih buruk lagi, menghambat performa halaman tanpa memberikan banyak nilai tambah bagi pengunjung atau situs yang menghosting halaman tersebut. Hal ini juga berlaku untuk resource dan widget pihak pertama dan pihak ketiga:

  • Situs A memutuskan untuk menampilkan korsel foto di berandanya agar pengunjung dapat melihat pratinjau beberapa foto dengan sekali klik cepat. Semua foto dimuat saat halaman dimuat, dan pengguna dapat melihat-lihat foto.
    • Pertanyaan: Pernahkah Anda mengukur jumlah pengguna yang melihat beberapa foto dalam carousel? Anda mungkin menimbulkan overhead yang tinggi dengan mendownload sumber daya 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 lainnya.
    • Pertanyaan: Apakah Anda telah melacak jumlah pengunjung yang menggunakan widget atau mengklik konten yang disediakan widget tersebut? 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 memerlukan banyak pemikiran dan pengukuran yang cermat. Untuk mendapatkan hasil terbaik, inventarisasikan dan ajukan kembali pertanyaan ini secara berkala untuk setiap aset di halaman Anda.

Efek pada Data Web Inti

Inisiatif Data Web Inti diperkenalkan oleh Google untuk memberikan kumpulan metrik yang mencerminkan apa yang dialami pengguna saat mereka menggunakan web. Meskipun ada banyak strategi pengoptimalan untuk Data Web Inti, pertanyaan apakah sumber daya tertentu perlu dimuat di halaman tertentu dapat membantu Anda meningkatkan metrik ini di situs. Berikut beberapa contoh—yang dikelompokkan menurut setiap Core Web Vitals—yang layak untuk Anda pertimbangkan. Meskipun ini bukan daftar contoh yang lengkap (dan ada banyak contoh!), membacanya dengan cermat dapat memberi Anda masukan.

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 meningkatkan LCP. Contoh klasiknya adalah pemuatan lambat, ketika 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, misalnya, 50 gambar, pemuatan lambat semuanya tetapi sepuluh gambar teratas berarti bahwa browser dapat menggunakan bandwidth yang tersedia secara lebih efisien, dan gambar pertama yang akan dilihat pengguna akan dimuat lebih cepat.

Namun, ini bukan sekadar memuat lebih sedikit gambar. Browser memiliki skema prioritas internal yang menentukan jumlah bandwidth yang harus diterima setiap resource. Namun, meskipun semua resource ini—terutama yang didownload dengan prioritas tinggi—memiliki potensi untuk mengurangi resource dependen elemen LCP. 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 mungkin ditentukan sebagai elemen LCP halaman.

Jika situs Anda memiliki banyak teks, mungkin elemen LCP halaman adalah 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 menggambar segera setelah CSS dan HTML tiba dari server.

Pergeseran Tata Letak Kumulatif (CLS)

Setiap resource yang Anda muat berpotensi berkontribusi pada Pergeseran Tata Letak Kumulatif (CLS) halaman, terutama jika belum selesai mendownload pada saat penggambaran awal. Untuk gambar, hindari CLS yang melibatkan praktik seperti menyetel dimensi eksplisit. Untuk font, mengelola pemuatan font dan kemungkinan penggantian pencocokan font dapat meminimalkan pergeseran selama periode penukaran font web. Untuk JavaScript, tugas ini bisa berupa mengelola cara skrip tersebut memanipulasi DOM sehingga pergeseran tata letak dikurangi ke jumlah yang dapat diterima.

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

Interaksi ke Next Paint (INP) dan Penundaan Input Pertama (FID)

Interaksi ke Next Paint (INP) dan Penundaan Input Pertama (FID) adalah metrik yang mengukur responsivitas terhadap input pengguna. Meskipun INP dijadwalkan untuk menggantikan FID sebagai Core Web Vital pada Maret 2024, strategi pengoptimalan untuk FID cenderung juga berlaku untuk INP. Selain itu, INP umumnya lebih sulit dioptimalkan daripada FID, karena melacak latensi interaksi penuh untuk semua interaksi halaman, bukan hanya penundaan input interaksi pertama sebagaimana diukur FID.

INP dan FID cenderung paling terpengaruh oleh JavaScript, karena JavaScript adalah yang mendorong sebagian besar interaktivitas yang dialami satu orang di seluruh web. Untuk INP dan FID, jumlah resource skrip yang didownload selama pemuatan halaman akan memulai pekerjaan yang berpotensi mahal yang terlibat dalam evaluasi dan kompilasi skrip. Makin sedikit JavaScript yang dimuat selama startup, makin sedikit pekerjaan yang harus dilakukan browser pada titik penting tersebut dalam pengalaman halaman.

Meskipun ada strategi untuk mengurangi ukuran resource JavaScript yang didownload selama startup—seperti pemisahan kode dan tree shaking—ada baiknya mengaudit paket yang Anda gunakan dalam project untuk melihat apakah paket tersebut benar-benar diperlukan. Misalnya, lodash memiliki banyak metode yang masih berguna hingga saat ini, tetapi diluncurkan dengan metode bawaan yang disediakan browser, seperti fungsi khusus Array untuk pemetaan, pengurangan, dan pemfilteran, serta banyak lagi.

Progressive enhancement juga merupakan pendekatan yang berguna untuk JavaScript, karena memungkinkan Anda untuk memberikan pengalaman dasar (tetapi masih berfungsi) bagi pengguna yang dapat Anda tambahkan untuk pengguna dengan perangkat yang lebih canggih dan koneksi jaringan yang lebih cepat. Baik Anda mematuhi prinsip {i>progressive enhancement<i} atau tidak, intinya tetap: Setiap resource JavaScript yang dapat Anda hindari mendownload dapat menghasilkan pengalaman yang merespons interaksi pengguna lebih cepat, yang merupakan aspek penting dari performa web.

Kesimpulan

Mengaudit situs untuk download yang tidak perlu mungkin hanyalah salah satu aspek dalam memberikan pengalaman pengguna yang cepat, tetapi hal ini berpotensi memberikan dampak yang besar. Ringkasnya:

  • Inventarisasi aset Anda sendiri dan aset pihak ketiga di halaman Anda.
  • Ukur performa setiap aset: nilainya dan performa teknisnya.
  • Tentukan apakah resource memberikan nilai yang memadai.
  • Memahami efek download yang tidak perlu terhadap Data Web Inti dan metrik pendukung.

Dengan mengoptimalkan efisiensi konten menggunakan cara ini, Anda tidak hanya meningkatkan performa secara keseluruhan, tetapi juga berhati-hati untuk tidak menyia-nyiakan bandwidth pengguna, serta berpotensi meningkatkan metrik yang berpusat pada pengguna dan memberikan pengalaman pengguna yang lebih baik.