Selain menghilangkan download resource yang tidak perlu, hal terbaik yang dapat Anda lakukan untuk meningkatkan kecepatan pemuatan halaman adalah meminimalkan ukuran download secara keseluruhan dengan mengoptimalkan dan memampatkan resource yang tersisa.
Dasar-dasar kompresi data
Setelah Anda menyiapkan situs untuk menghindari download resource yang tidak digunakan, langkah selanjutnya adalah mengompresi resource yang memenuhi syarat yang harus didownload browser. Bergantung pada jenis resource—teks, gambar, font, dan sebagainya—ada banyak teknik berbeda yang dapat dipilih: alat umum 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 semua teknik berikut:
- Kompresi adalah proses encoding informasi menggunakan lebih sedikit bit.
- Menghilangkan data yang tidak perlu selalu memberikan hasil terbaik.
- Ada banyak teknik dan algoritma kompresi yang berbeda.
- Anda akan memerlukan berbagai teknik untuk mencapai kompresi terbaik.
Proses mengurangi ukuran data adalah kompresi data. Banyak orang telah berkontribusi dalam mengembangkan 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—secara umum—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 hanya 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 oleh 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 dari 200 karakter?
- Komentarnya menarik, tetapi tidak memengaruhi arti pesan. Menghilangkannya 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 hanya mengirim ID tersebut. Namun, hal itu mungkin tidak benar, jadi sebaiknya biarkan saja untuk saat ini.
- Payload hanya berupa teks. Meskipun kami tidak tahu apa isinya (tampaknya, menggunakan
"secret-cipher"), hanya dengan melihat teksnya, kita bisa melihat bahwa ada banyak redundansi di dalamnya. Mungkin alih-alih mengirim huruf berulang, Anda dapat menghitung jumlah huruf berulang dan mengenkodenya dengan lebih efisien. Misalnya,"AAA"menjadi"3A", yang mewakili urutan tiga A.
Penggabungan teknik ini akan menghasilkan hasil berikut:
format: secret-cipher
date: 08/25/16
3A2Z4B3E3M 3E3T3A
Pesan baru memiliki panjang 56 karakter, yang berarti Anda telah memampatkan pesan asli sebesar 72%. Itu adalah pengurangan yang signifikan.
Ini adalah contoh sederhana tentang bagaimana algoritma kompresi dapat efektif dalam mengurangi ukuran transfer resource berbasis teks. Pada 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 pada 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: praproses, dan pengoptimalan khusus konteks
Teknik pertama yang dibahas di sini adalah minifikasi. Meskipun bukan algoritma kompresi, minifikasi adalah cara untuk menghapus karakter yang tidak perlu dan berlebihan 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 secara signifikan mengurangi ukuran resource yang dikirimkan, dan pengoptimalan ini paling baik diterapkan sebagai bagian dari proses build dan deployment Anda. Misalnya, bundler adalah jenis software yang umum digunakan yang dapat secara otomatis meminimalkan resource tepat sebelum men-deploy kode produksi baru ke situs.
Cara terbaik untuk mengompresi data yang berlebih atau tidak perlu adalah dengan menghapusnya. Namun, Anda tidak dapat menghapus data secara acak. 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 ada di dalamnya:
- 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 masih ada adalah "bagaimana cara mengurangi ukuran halaman ini?"
- Komentar kode sangat berguna bagi developer, tetapi browser tidak memerlukannya. Menghapus komentar CSS (
/* ... */), HTML (<!-- ... -->), dan JavaScript (// ...) akan mengurangi total ukuran transfer halaman dan sub-sumber dayanya. - Kompresor CSS "pintar" dapat melihat bahwa kita menggunakan cara yang tidak efisien untuk
menentukan aturan untuk
.awesome-container, dan menggabungkan kedua deklarasi menjadi satu tanpa memengaruhi gaya lainnya, sehingga menghemat lebih banyak byte. Untuk sekumpulan besar aturan CSS, penghapusan redundansi semacam ini dapat menambah efisiensi—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 developer di 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 ruang atau tab tersebut tidak diperlukan untuk presentasi halaman—misalnya, Anda sebaiknya mempertahankan ruang dalam rangkaian teks dalam dokumen HTML, karena ruang tersebut memastikan keterbacaan konten yang akan 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, tidak terlalu mudah dibaca, tetapi tidak perlu demikian agar dapat digunakan. Praktik pengembangan modern juga memungkinkan Anda menyimpan versi kode sumber yang diformat dengan baik dan mudah dibaca secara terpisah dari kode yang dioptimalkan dengan baik yang Anda kirimkan ke produksi. Jika digabungkan dengan peta sumber—yang memberikan representasi kode produksi yang diubah dan mudah dibaca 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 menggambarkan poin penting: kompresor tujuan umum—misalnya, yang dirancang untuk mengompresi teks arbitrer—dapat melakukan tugas yang cukup baik dalam mengompresi halaman dalam contoh sebelumnya, tetapi tidak akan pernah tahu cara menghapus komentar, menciutkan aturan CSS, atau puluhan pengoptimalan khusus konten lainnya. Itulah sebabnya praproses, minifikasi, dan pengoptimalan lainnya yang sadar konteks penting.
Demikian pula, teknik yang dijelaskan di atas dapat diperluas tidak hanya untuk aset berbasis teks. Gambar, video, dan jenis konten lainnya memiliki bentuk metadata dan berbagai payloadnya sendiri. Misalnya, setiap kali Anda mengambil foto dengan kamera, filenya biasanya menyematkan banyak informasi tambahan: setelan kamera, lokasi, dan sebagainya. Bergantung pada aplikasi Anda, data ini mungkin sangat penting (misalnya, situs berbagi foto) atau mungkin tidak berguna sama sekali. Anda harus mempertimbangkan apakah perlu menghapusnya. Dalam praktiknya, metadata ini dapat menambahkan 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 yang perlu dioptimalkan, otomatiskan pengoptimalan ini dengan menambahkannya ke langkah-langkah build dan rilis untuk memastikan pengoptimalan diterapkan secara konsisten untuk setiap rilis baru ke produksi.
Kompresi teks dengan algoritma kompresi
Langkah berikutnya untuk mengurangi ukuran aset berbasis teks adalah menerapkan algoritma kompresi padanya. Hal ini dilakukan selangkah lebih jauh dengan agresif mencari pola yang dapat diulang dalam payload berbasis teks sebelum mengirimkannya ke pengguna, dan mendekompresinya setelah tiba di browser pengguna. Hasilnya adalah pengurangan lebih lanjut dan signifikan pada resource tersebut, dan waktu download yang lebih cepat berikutnya.
- gzip dan Brotli adalah algoritma kompresi yang umum digunakan dan memiliki performa 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 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 adalah yang terbaik. Untuk Brotli, rentang ini adalah 0 hingga 11, dengan 11 adalah yang terbaik. Namun, setelan kompresi yang lebih tinggi memerlukan waktu yang lebih lama. 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 mungkin dilakukan, yaitu saat respons dikompresi terlebih dahulu, dan oleh karena itu dapat menggunakan setelan kompresi yang 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 mengkhawatirkan satu aspek kompresi.
gzip dan Brotli adalah kompresor umum yang dapat diterapkan ke aliran byte apa pun. Di balik layar, mereka mengingat beberapa konten file yang sebelumnya diperiksa, dan selanjutnya mencoba menemukan dan mengganti fragmen data duplikat secara 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 tanpa kehilangan data atau dengan kehilangan data—hanya memberikan sedikit atau 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 server web dikonfigurasi dengan benar untuk menayangkan resource yang dikompresi saat klien memintanya.
| File | Algoritma | Ukuran tidak terkompresi | 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 kompresi Brotli dan gzip untuk beberapa library JavaScript terkenal. Penghematan berkisar antara 65% hingga 86%, bergantung pada file dan algoritma. 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 melewatkan peluang besar untuk meningkatkan performa bagi pengguna Anda. 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 cara kerja kompresi adalah dengan membuka Chrome DevTools, membuka panel Network, memuat halaman pilihan Anda, dan mengamati bagian paling bawah panel jaringan.
Seperti gambar sebelumnya, Anda akan melihat perincian:
- Jumlah permintaan, yaitu jumlah resource yang dimuat untuk halaman.
- Ukuran transfer semua permintaan. Metrik ini mencerminkan efektivitas kompresi yang diterapkan pada salah satu resource halaman.
- Ukuran resource 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 awareness tentang 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 saat penerapan pengoptimalan ini dapat meningkatkan Core Web Vitals situs Anda:
- Aset HTML yang diperkecil dan dikompresi dapat meningkatkan pemuatan HTML tersebut, kemampuan sub-asetnya untuk ditemukan, dan dengan demikian meningkatkan pemuatannya. Hal ini dapat bermanfaat bagi Largest Contentful Paint
(LCP) halaman. Meskipun petunjuk resource seperti
rel="preload"dapat digunakan untuk memengaruhi kemampuan penemuan resource, penggunaan terlalu banyak petunjuk resource dapat menyebabkan masalah pada persaingan 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 dengan menggunakan kompresi. Misalnya, gambar SVG yang merupakan kandidat LCP dapat mengurangi durasi pemuatan sumber daya melalui kompresi berbasis teks. Hal ini berbeda dengan pengoptimalan yang akan Anda lakukan pada jenis gambar lain—yang secara intrinsik dikompresi 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 berlaku. Namun, jika Anda tidak menggunakan font web—melainkan font sistem yang ditampilkan tanpa menimbulkan durasi pemuatan resource—meminimalkan dan mengompresi CSS akan mengurangi durasi ini, yang berarti bahwa 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 dapat Anda lakukan untuk memastikan bahwa resource yang memenuhi syarat untuk minifikasi dan kompresi mendapatkan manfaat dari pengoptimalan tersebut.
Yang lebih penting, pastikan proses ini diotomatiskan. Untuk penyusutan, gunakan bundler untuk menerapkan penyusutan pada resource yang memenuhi syarat. Pastikan konfigurasi server web Anda mendukung kompresi, tetapi lebih dari itu, gunakan kompresi yang paling efektif yang tersedia. Untuk membuatnya sesederhana mungkin, gunakan CDN untuk mengotomatiskan kompresi bagi Anda, karena CDN tidak hanya dapat mengompresi resource untuk Anda, tetapi juga dapat melakukannya dengan sangat cepat.
Dengan memantapkan konsep performa dasar ini ke dalam arsitektur situs Anda, Anda dapat memastikan bahwa upaya pengoptimalan performa Anda berada di jalur yang tepat, dan pengoptimalan berikutnya dapat bertumpu pada fondasi yang kuat dari praktik dasar yang baik.