Selain menghilangkan download resource yang tidak diperlukan, hal terbaik yang dapat Anda lakukan untuk meningkatkan kecepatan pemuatan halaman adalah meminimalkan ukuran download secara keseluruhan dengan mengoptimalkan dan mengompresi resource yang tersisa.
Dasar-dasar kompresi data
Setelah menyiapkan situs untuk menghindari download resource yang tidak digunakan, langkah berikutnya adalah mengompresi resource yang memenuhi syarat dan tersisa yang harus didownload oleh browser. Bergantung pada jenis resource—teks, gambar, font, dan sebagainya—ada banyak teknik berbeda yang dapat dipilih: alat generik yang dapat diaktifkan di server web, pengoptimalan pra-pemrosesan untuk jenis konten tertentu, dan pengoptimalan khusus resource yang memerlukan input dari developer.
Untuk memberikan performa terbaik, diperlukan kombinasi dari semua teknik berikut:
- Kompresi adalah proses encoding informasi menggunakan bit yang lebih sedikit.
- Menghilangkan data yang tidak diperlukan selalu memberikan hasil terbaik.
- Ada banyak teknik dan algoritma kompresi yang berbeda.
- Anda akan memerlukan berbagai teknik untuk mencapai kompresi terbaik.
Proses pengurangan ukuran data disebut kompresi data. Banyak orang telah berkontribusi dalam algoritma, teknik, dan pengoptimalan untuk meningkatkan rasio kompresi, kecepatan kompresi, dan memori yang diperlukan oleh berbagai algoritma kompresi.
Pembahasan lengkap tentang kompresi data berada di luar cakupan panduan ini. Namun, penting untuk memahami—pada tingkat tinggi—cara kerja kompresi, dan teknik yang dapat Anda gunakan untuk mengurangi ukuran berbagai aset yang diperlukan halaman Anda.
Untuk mengilustrasikan prinsip inti teknik ini, pertimbangkan proses mengoptimalkan format pesan teks sederhana yang dibuat khusus untuk contoh ini:
# Below is a secret message, which consists of a set of headers in
# key-value format followed by a newline and the encrypted message.
format: secret-cipher
date: 08/25/16
AAAZZBBBBEEEMMM EEETTTAAA
- Pesan dapat berisi anotasi arbitrer—terkadang disebut sebagai komentar—yang ditunjukkan dengan awalan "#". Anotasi tidak memengaruhi makna pesan, atau perilakunya.
- Pesan dapat berisi header, yang merupakan key-value pair (dipisahkan oleh
":"dalam contoh sebelumnya) yang muncul di awal pesan. - Pesan membawa payload teks.
Apa yang dapat dilakukan untuk mengurangi ukuran pesan sebelumnya, yang dimulai dengan 200 karakter?
- Komentar tersebut menarik, tetapi tidak memengaruhi makna pesan. Hilangkan saat mengirimkan pesan.
- Ada teknik yang baik untuk mengenkode header secara efisien. Misalnya, jika Anda tahu bahwa semua pesan memiliki "format" dan "tanggal", Anda dapat mengonversinya menjadi ID bilangan bulat pendek dan mengirimkannya. Namun, hal itu mungkin tidak benar, jadi sebaiknya biarkan saja untuk saat ini.
- Payload hanya berupa teks. Meskipun kita tidak tahu apa isi sebenarnya (tampaknya, file ini menggunakan
"secret-cipher"), hanya dengan melihat teksnya, kita dapat melihat bahwa ada banyak redundansi di dalamnya. Daripada mengirimkan huruf berulang, Anda dapat menghitung jumlah huruf berulang dan mengenkodekannya dengan lebih efisien. Misalnya,"AAA"menjadi"3A", yang mewakili urutan tiga huruf A.
Menggabungkan teknik ini akan memberikan hasil berikut:
format: secret-cipher
date: 08/25/16
3A2Z4B3E3M 3E3T3A
Pesan baru ini memiliki panjang 56 karakter, yang berarti Anda telah mengompresi pesan asli sebesar 72%. Pengurangan yang signifikan.
Ini adalah contoh sederhana tentang bagaimana algoritma kompresi dapat efektif dalam mengurangi ukuran transfer resource berbasis teks. Dalam praktiknya, algoritma kompresi jauh lebih canggih daripada yang diilustrasikan dalam contoh sebelumnya, dan di web, algoritma kompresi dapat digunakan untuk mengurangi waktu download resource secara signifikan. Dengan menerapkan kompresi ke aset berbasis teks, halaman web dapat menghabiskan lebih sedikit waktu untuk memuat resource, sehingga pengguna dapat melihat efek resource tersebut lebih cepat daripada tanpa kompresi.
Minifikasi: Prapemrosesan dan pengoptimalan khusus konteks
Teknik pertama yang dibahas di sini adalah minifikasi. Meskipun minifikasi bukanlah algoritma kompresi, ini adalah cara untuk menghapus karakter yang tidak perlu dan redundan yang digunakan dalam kode sumber untuk membuat resource lebih mudah dibaca oleh manusia. Namun, keterbacaan tersebut tidak diperlukan untuk mempertahankan fungsi kode sumber tersebut di situs produksi, dan dapat menunda pemuatan resource di web.
Minifikasi adalah jenis pengoptimalan khusus konten yang dapat mengurangi ukuran resource yang dikirim secara signifikan, dan pengoptimalan ini paling baik diterapkan sebagai bagian dari proses build dan deployment Anda. Misalnya, pemaket adalah jenis software yang umum digunakan yang dapat otomatis meminimalkan resource tepat sebelum deployment kode produksi baru ke situs.
Cara terbaik untuk mengompresi data yang redundan atau tidak diperlukan adalah dengan menghapusnya. Namun, Anda tidak dapat menghapus data arbitrer begitu saja. Namun, dalam beberapa konteks saat kita memiliki pengetahuan khusus konten tentang format data dan propertinya, kita dapat mengurangi ukuran payload secara signifikan tanpa memengaruhi makna atau kemampuan sebenarnya.
<html>
<head>
<style>
/* awesome-container is only used on the landing page */
.awesome-container {
font-size: 120%;
}
.awesome-container {
width: 50%;
}
</style>
</head>
<body>
<!-- awesome container content: START -->
<div>
This is my awesome container, and it is <em>so</em> awesome.
</div>
<!-- awesome container content: END -->
<script>
awesomeAnalytics(); // Beacon conversion metrics
</script>
</body>
</html>
Pertimbangkan cuplikan HTML sebelumnya dan tiga jenis konten berbeda yang dimuatnya:
- Markup HTML.
- CSS untuk menyesuaikan presentasi halaman.
- JavaScript untuk mendukung interaksi dan kemampuan halaman lanjutan lainnya.
Setiap jenis konten ini memiliki aturan yang berbeda untuk menentukan konten yang valid, aturan yang berbeda untuk menentukan komentar, dan sebagainya. Namun, pertanyaan yang tersisa adalah "bagaimana cara mengurangi ukuran halaman ini?"
- Komentar kode sangat berguna bagi developer, tetapi browser tidak membutuhkannya. Menghapus komentar CSS (
/* ... */), HTML (<!-- ... -->), dan JavaScript (// ...) akan mengurangi total ukuran transfer halaman dan subresource-nya. - Kompresor CSS "cerdas" dapat melihat bahwa kita menggunakan cara yang tidak efisien untuk
menentukan aturan untuk
.awesome-container, dan menciutkan dua deklarasi menjadi satu tanpa memengaruhi gaya lainnya, sehingga menghemat lebih banyak byte. Pada kumpulan aturan CSS yang besar, menghapus redundansi semacam ini dapat memberikan dampak yang signifikan, tetapi mungkin tidak dapat diterapkan secara agresif, karena pemilih sering kali perlu diduplikasi dalam konteks yang berbeda, seperti dalam kueri media. - Spasi dan tab adalah kemudahan bagi developer dalam HTML, CSS, dan JavaScript. Kompresor tambahan dapat menghapus semua tab dan spasi. Tidak seperti teknik penghapusan duplikat lainnya, pengoptimalan semacam ini dapat diterapkan secara cukup agresif, selama spasi atau tab tersebut tidak diperlukan untuk presentasi halaman—misalnya, Anda ingin mempertahankan spasi dalam rangkaian teks dalam dokumen HTML, karena spasi tersebut memastikan keterbacaan konten yang akan benar-benar dilihat pengguna.
<html><head><style>.awesome-container{font-size:120%;width:50%}</style></head><body><div>This is my awesome container, and it is <em>so</em> awesome.</div><script>awesomeAnalytics()</script></body></html>
Setelah menerapkan langkah-langkah sebelumnya, halaman akan berubah dari 516 menjadi 204 karakter, yang mewakili penghematan sekitar 60%. Memang, kode ini tidak terlalu mudah dibaca, tetapi tidak perlu mudah dibaca agar dapat digunakan. Praktik pengembangan modern juga memungkinkan Anda menyimpan versi kode sumber yang diformat dengan baik dan mudah dibaca terpisah dari kode yang dioptimalkan dengan baik yang Anda kirim ke produksi. Digabungkan dengan peta sumber—yang memberikan representasi yang dapat dibaca dari kode produksi yang diubah sehingga Anda dapat memecahkan masalah bug dalam produksi dengan lebih mudah—Anda dapat memiliki pengalaman developer yang baik sekaligus mengoptimalkan performa demi pengalaman pengguna.
Contoh sebelumnya mengilustrasikan poin penting: kompresor tujuan umum—misalnya, yang dirancang untuk mengompresi teks arbitrer—dapat melakukan pekerjaan yang cukup baik dalam mengompresi halaman pada contoh sebelumnya, tetapi tidak akan pernah tahu cara menghapus komentar, menciutkan aturan CSS, atau lusinan pengoptimalan khusus konten lainnya. Inilah sebabnya pra-pemrosesan, minifikasi, dan pengoptimalan berbasis konteks lainnya menjadi penting.
Demikian pula, teknik yang dijelaskan di atas dapat diperluas tidak hanya untuk aset berbasis teks. Gambar, video, dan jenis konten lainnya semuanya berisi bentuk metadata dan berbagai payload-nya sendiri. Misalnya, setiap kali Anda mengambil foto dengan kamera, filenya biasanya menyertakan banyak informasi tambahan: setelan kamera, lokasi, dan sebagainya. Bergantung pada aplikasi Anda, data ini mungkin sangat penting (misalnya, situs berbagi foto) atau mungkin sama sekali tidak berguna. Anda harus mempertimbangkan apakah hal itu layak dihapus. Dalam praktiknya, metadata ini dapat bertambah hingga puluhan kilobyte untuk setiap gambar.
Singkatnya, sebagai langkah pertama dalam mengoptimalkan efisiensi aset, buat inventaris berbagai jenis konten dan pertimbangkan jenis pengoptimalan khusus konten yang dapat Anda terapkan untuk mengurangi ukurannya. Kemudian—setelah Anda mengetahui apa saja pengoptimalan tersebut, otomatiskan pengoptimalan ini dengan menambahkannya ke langkah-langkah build dan rilis untuk memastikan bahwa pengoptimalan diterapkan secara konsisten untuk setiap rilis baru ke produksi.
Kompresi teks dengan algoritma kompresi
Langkah berikutnya untuk mengurangi ukuran aset berbasis teks adalah dengan menerapkan algoritma kompresi ke aset tersebut. Hal ini dilakukan dengan mencari pola yang dapat diulang secara agresif dalam payload berbasis teks sebelum mengirimkannya kepada pengguna, dan mendekompresinya setelah tiba di browser pengguna. Hasilnya adalah pengurangan lebih lanjut dan signifikan pada resource tersebut, dan waktu download yang lebih cepat.
- gzip dan Brotli adalah algoritma kompresi yang umum digunakan dan berperforma terbaik pada aset berbasis teks: CSS, JavaScript, HTML.
- Semua browser modern mendukung kompresi gzip dan Brotli, serta akan mengiklankan
dukungan untuk keduanya di header permintaan HTTP
Accept-Encoding. - Server Anda harus dikonfigurasi untuk mengaktifkan kompresi. Software server web sering kali akan mengaktifkan modul untuk mengompresi resource berbasis teks secara default.
- Gzip dan Brotli dapat disesuaikan untuk meningkatkan rasio kompresi dengan menyesuaikan tingkat kompresi. Untuk gzip, setelan kompresi berkisar dari 1 hingga 9, dengan 9 sebagai yang terbaik. Untuk Brotli, rentang ini adalah 0 hingga 11, dengan 11 sebagai yang terbaik. Namun, setelan kompresi yang lebih tinggi memerlukan lebih banyak waktu. Untuk resource yang dikompresi secara dinamis—yaitu, pada saat permintaan—setelan di tengah rentang cenderung menawarkan kompromi terbaik antara rasio kompresi dan kecepatan. Namun, kompresi statis dapat dilakukan, yaitu saat respons dikompresi terlebih dahulu, sehingga dapat menggunakan setelan kompresi paling agresif yang tersedia untuk setiap algoritma kompresi.
- Jaringan Penayangan Konten (CDN) biasanya menawarkan kompresi otomatis untuk resource yang memenuhi syarat. CDN juga dapat mengelola kompresi dinamis dan statis untuk Anda, sehingga Anda tidak perlu khawatir tentang aspek kompresi.
gzip dan Brotli adalah kompresor umum yang dapat diterapkan ke aliran byte apa pun. Di balik layar, algoritma ini mengingat beberapa konten file yang telah diperiksa sebelumnya, lalu mencoba menemukan dan mengganti fragmen data duplikat dengan cara yang efisien.
Dalam praktiknya, gzip dan Brotli berperforma terbaik pada konten berbasis teks, sering kali mencapai rasio kompresi setinggi 70-90% untuk file yang lebih besar. Namun, menjalankan algoritma ini pada aset yang sudah dikompresi menggunakan algoritma alternatif—seperti sebagian besar format gambar yang menggunakan teknik kompresi lossless atau lossy—hanya memberikan sedikit atau bahkan tidak ada peningkatan.
Semua browser modern mengiklankan dukungan untuk gzip dan Brotli di
header permintaan HTTP Accept-Encoding. Namun, penyedia hosting bertanggung jawab untuk memastikan bahwa server web dikonfigurasi dengan benar untuk menyajikan resource yang dikompresi saat klien memintanya.
| File | Algoritma | Ukuran tanpa kompresi | Ukuran terkompresi | Rasio kompresi |
|---|---|---|---|---|
| angular-1.8.3.js | Brotli | 1.346 KiB | 256 KiB | 81% |
| angular-1.8.3.js | gzip | 1.346 KiB | 329 KiB | 76% |
| angular-1.8.3.min.js | Brotli | 173 KiB | 53 KiB | 69% |
| angular-1.8.3.min.js | gzip | 173 KiB | 60 KiB | 65% |
| jquery-3.7.1.js | Brotli | 302 KiB | 69 KiB | 77% |
| jquery-3.7.1.js | gzip | 302 KiB | 83 KiB | 73% |
| jquery-3.7.1.min.js | Brotli | 85 KiB | 27 KiB | 68% |
| jquery-3.7.1.min.js | gzip | 85 KiB | 30 KiB | 65% |
| lodash-4.17.21.js | Brotli | 531 KiB | 73 KiB | 86% |
| lodash-4.17.21.js | gzip | 531 KiB | 94 KiB | 82% |
| lodash-4.17.21.min.js | Brotli | 71 KiB | 23 KiB | 68% |
| lodash-4.17.21.min.js | gzip | 71 KiB | 25 KiB | 65% |
Tabel sebelumnya menunjukkan penghematan yang dapat diberikan oleh kompresi Brotli dan gzip untuk beberapa library JavaScript terkenal. Penghematannya berkisar antara 65% hingga 86%, bergantung pada file dan algoritmanya. Sebagai referensi, tingkat kompresi maksimum diterapkan ke setiap file untuk Brotli dan gzip. Jika memungkinkan, pilih Brotli daripada gzip.
Mengaktifkan kompresi adalah salah satu pengoptimalan paling sederhana dan efektif untuk diterapkan. Jika situs Anda tidak memanfaatkannya, Anda akan kehilangan peluang besar untuk meningkatkan performa bagi pengguna. Untungnya, banyak server web menyediakan konfigurasi default yang memungkinkan pengoptimalan penting ini, dan CDN khususnya sangat efektif dalam menerapkannya dengan cara yang menyeimbangkan kecepatan dan rasio kompresi.
Cara cepat untuk melihat kompresi yang sedang berjalan adalah dengan membuka Chrome DevTools, membuka panel Jaringan, memuat halaman pilihan Anda, dan mengamati bagian paling bawah panel jaringan.
Seperti gambar sebelumnya, Anda akan melihat perincian:
- Jumlah permintaan, yang merupakan jumlah resource yang dimuat untuk halaman.
- Ukuran transfer semua permintaan. Hal ini mencerminkan efektivitas kompresi yang diterapkan ke salah satu resource halaman.
- Ukuran resource dari semua permintaan. Hal ini mencerminkan seberapa besar resource untuk halaman setelah didekompresi.
Efek pada Core Web Vitals
Peningkatan performa tidak dapat diukur kecuali ada metrik yang mencerminkan peningkatan tersebut. Inisiatif Core Web Vitals ada untuk membuat dan meningkatkan kesadaran akan metrik yang mencerminkan pengalaman pengguna yang sebenarnya. Hal ini berbeda dengan metrik—seperti waktu pemuatan halaman sederhana, misalnya—yang tidak secara jelas diterjemahkan ke kualitas pengalaman pengguna.
Saat Anda menerapkan pengoptimalan yang diuraikan dalam panduan ini ke resource di situs Anda, efeknya pada Core Web Vitals dapat bervariasi, berdasarkan resource yang dioptimalkan dan metrik yang terlibat. Namun, berikut adalah beberapa contoh penerapan pengoptimalan ini yang dapat meningkatkan Core Web Vitals situs Anda:
- Resource HTML yang diminifikasi dan dikompresi dapat meningkatkan pemuatan
HTML tersebut, visibilitas sub-resource-nya, dan dengan demikian meningkatkan
pemuatannya. Hal ini dapat bermanfaat untuk Largest Contentful Paint
(LCP) halaman. Meskipun petunjuk resource seperti
rel="preload"dapat digunakan untuk memengaruhi visibilitas resource, penggunaan terlalu banyak petunjuk dapat menyebabkan masalah perebutan bandwidth. Dengan memastikan respons HTML untuk permintaan navigasi dikompresi, resource di dalamnya dapat ditemukan sesegera mungkin oleh pemindai pramuat. - Beberapa kandidat LCP juga dapat dimuat lebih cepat menggunakan kompresi. Misalnya, gambar SVG yang merupakan kandidat LCP dapat dikurangi durasi pemuatan resource-nya melalui kompresi berbasis teks. Hal ini berbeda dengan pengoptimalan yang akan Anda lakukan pada jenis gambar lain—yang dikompresi secara intrinsik melalui metode kompresi lain—seperti cara gambar JPEG menggunakan kompresi lossy.
- Selain itu, node teks juga dapat menjadi kandidat LCP. Cara teknik yang dijelaskan dalam panduan ini bergantung pada apakah Anda menggunakan font web untuk teks di halaman web Anda. Jika Anda menggunakan font web, praktik terbaik pengoptimalan font web akan berlaku. Namun, jika Anda tidak menggunakan font web—tetapi font sistem yang ditampilkan tanpa menimbulkan durasi pemuatan resource—memperkecil dan mengompresi CSS akan mengurangi durasi ini, yang berarti rendering potensi node teks LCP dapat terjadi lebih cepat.
Kesimpulan
Cara Anda mengoptimalkan encoding dan transfer aset berbasis teks adalah konsep performa dasar, tetapi memiliki dampak yang besar. Pastikan Anda melakukan semua yang Anda bisa untuk memastikan bahwa resource yang memenuhi syarat untuk minifikasi dan kompresi mendapatkan manfaat dari pengoptimalan tersebut.
Yang lebih penting, pastikan proses ini diotomatiskan. Untuk minifikasi, gunakan pemaket untuk menerapkan minifikasi ke resource yang memenuhi syarat. Pastikan konfigurasi server web Anda mendukung kompresi, tetapi lebih dari itu, gunakan kompresi paling efektif yang tersedia. Untuk membuatnya sesederhana mungkin, gunakan CDN untuk mengotomatiskan kompresi, karena CDN tidak hanya dapat mengompresi resource untuk Anda, tetapi juga dapat melakukannya dengan sangat cepat.
Dengan memperkuat konsep performa dasar ini ke dalam arsitektur situs, Anda dapat memastikan bahwa upaya pengoptimalan performa Anda berada di posisi yang baik, dan pengoptimalan berikutnya dapat mengandalkan fondasi yang kuat dari praktik dasar yang baik.