Mengoptimalkan encoding dan ukuran transfer aset berbasis teks

Selain menghapus download resource yang tidak diperlukan, hal terbaik yang dapat Anda lakukan untuk meningkatkan kecepatan pemuatan halaman adalah meminimalkan ukuran download 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 lain yang memenuhi syarat dan harus didownload oleh browser. Bergantung pada jenis resource—teks, gambar, font, dan sebagainya—ada banyak teknik yang dapat dipilih: alat umum yang dapat diaktifkan di server web, pengoptimalan prapemrosesan untuk jenis konten tertentu, dan pengoptimalan khusus resource yang memerlukan input dari developer.

Menghasilkan performa terbaik memerlukan kombinasi dari semua teknik berikut:

  • Kompresi adalah proses encoding informasi yang menggunakan lebih sedikit bit.
  • 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 mengurangi ukuran data adalah kompresi data. Banyak orang telah mengontribusi algoritma, teknik, dan pengoptimalan untuk meningkatkan rasio kompresi, kecepatan kompresi, dan memori yang diperlukan oleh berbagai algoritma kompresi.

Diskusi lengkap tentang kompresi data jauh di luar cakupan panduan ini. Namun, pada tingkat tinggi, Anda perlu memahami cara kerja kompresi dan teknik yang dapat digunakan untuk mengurangi ukuran berbagai aset yang diperlukan halaman Anda.

Untuk menggambarkan prinsip inti dari teknik ini, pertimbangkan proses pengoptimalan format pesan teks sederhana yang ditemukan 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
  1. Pesan dapat berisi anotasi arbitrer—terkadang disebut sebagai komentar—yang ditunjukkan dengan awalan "#". Anotasi tidak memengaruhi makna pesan, atau perilakunya.
  2. Pesan dapat berisi headers, yang merupakan key-value pair (dipisahkan oleh ":" dalam contoh sebelumnya) yang muncul di awal pesan.
  3. Pesan membawa payload teks.

Apa yang bisa dilakukan untuk mengurangi ukuran pesan sebelumnya, yang dimulai dari 200 karakter?

  1. Komentarnya menarik, tetapi tidak memengaruhi makna pesan. Hapus saat mengirim pesan.
  2. Ada teknik bagus untuk mengenkode header dengan cara yang efisien. Misalnya, jika tahu bahwa semua pesan memiliki "format" dan "tanggal", Anda dapat mengonversinya menjadi ID bilangan bulat pendek dan mengirimnya saja. Namun, itu mungkin tidak benar, jadi sebaiknya biarkan saja untuk saat ini.
  3. Payload hanya berupa teks. Meskipun kita tidak tahu konten sebenarnya (tampaknya menggunakan "secret-cipher"), melihat teks akan menunjukkan bahwa ada banyak redundansi di dalamnya. Daripada mengirim huruf berulang, Anda cukup menghitung jumlah huruf berulang dan mengenkodenya dengan lebih efisien. Misalnya, "AAA" menjadi "3A", yang mewakili urutan tiga 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%. Itu pengurangan yang signifikan!

Ini adalah contoh mainan tentang bagaimana algoritma kompresi dapat efektif mengurangi ukuran transfer resource berbasis teks. Dalam praktiknya, algoritma kompresi jauh lebih canggih daripada yang diilustrasikan oleh 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: pra-pemrosesan, dan pengoptimalan konteks tertentu

Teknik pertama yang dibahas di sini adalah minifikasi. Meskipun minifikasi bukanlah algoritma kompresi yang ketat, minifikasi adalah cara untuk menghapus karakter yang tidak perlu dan berlebihan yang digunakan dalam kode sumber agar resource lebih mudah dibaca oleh manusia. Namun, keterbacaan tersebut tidak diperlukan untuk mempertahankan fungsi kode sumber 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 sebaiknya diterapkan sebagai bagian dari proses build dan deployment Anda. Misalnya, pemaket adalah jenis software yang biasa digunakan dan dapat otomatis meminifikasi resource sebelum deployment kode produksi baru ke suatu situs.

Cara terbaik untuk mengompresi data yang redundan atau tidak perlu adalah dengan menghilangkannya. Namun, Anda tidak bisa hanya menghapus data arbitrer. Namun, dalam beberapa konteks yang membuat kami memiliki pengetahuan khusus konten tentang format data dan propertinya, ukuran payload dapat dikurangi secara signifikan tanpa memengaruhi arti 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 berisi:

  1. Markup HTML.
  2. CSS untuk menyesuaikan presentasi halaman.
  3. JavaScript untuk mendukung interaksi dan kemampuan halaman lanjutan lainnya.

Masing-masing jenis konten ini memiliki aturan berbeda terkait apa yang dianggap sebagai konten yang valid, aturan yang berbeda untuk menentukan komentar, dan sebagainya. Namun, pertanyaan yang tetap ada adalah "bagaimana ukuran halaman ini dapat dikurangi?"

  • Komentar kode adalah sahabat terbaik dari developer, namun browser tidak membutuhkannya. Menghapus komentar CSS (/* ... */), HTML (<!-- ... -->), dan JavaScript (// ...) akan mengurangi total ukuran transfer halaman dan subresource-nya.
  • Kompresor CSS yang "cerdas" dapat mengetahui bahwa kita menggunakan cara yang tidak efisien dalam menentukan aturan untuk .awesome-container, dan menciutkan dua deklarasi menjadi satu tanpa memengaruhi gaya lain, sehingga menghemat lebih banyak byte. Melalui sekumpulan besar aturan CSS, menghapus redundansi semacam ini dapat bertambah—tetapi mungkin bukan sesuatu yang dapat diterapkan secara agresif, karena pemilih sering sering kali diduplikasi dalam konteks yang berbeda, seperti dalam kueri media.
  • Spasi dan tab adalah kemudahan 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 dengan cukup agresif, selama spasi atau tab tersebut tidak diperlukan untuk presentasi halaman—misalnya, Anda ingin mempertahankan spasi dalam run dari teks di dokumen HTML, karena cara ini 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, panjang halaman berkurang dari 516 menjadi 204 karakter, yang menyatakan penghematan sekitar 60%. Memang tidak terlalu mudah dibaca, tetapi tidak harus begitu agar dapat digunakan. Praktik pengembangan modern juga memungkinkan Anda untuk memisahkan versi kode sumber yang diformat dan dapat dibaca dengan baik dari kode yang dioptimalkan dengan baik yang Anda kirimkan ke produksi. Bersama dengan peta sumber—yang memberikan representasi yang dapat dibaca dari kode produksi yang ditransformasi memungkinkan Anda 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 untuk tujuan umum—misalnya, kompresor yang dirancang untuk mengompresi teks arbitrer—dapat melakukan kompresi halaman dengan cukup baik pada contoh sebelumnya, tetapi kompresor ini tidak akan pernah tahu untuk menghapus komentar, menciutkan aturan CSS, atau puluhan pengoptimalan khusus konten lainnya. Inilah alasan pentingnya pra-pemrosesan, minifikasi, dan pengoptimalan kontekstual lainnya.

Demikian pula, teknik yang dijelaskan di atas dapat diperluas hingga lebih dari sekadar aset berbasis teks. Gambar, video, dan jenis konten lainnya berisi bentuk metadatanya sendiri dan berbagai payload. Misalnya, setiap kali Anda mengambil gambar 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 sama sekali tidak berguna. Anda harus mempertimbangkan apakah penghapusan perlu dilakukan. Dalam praktiknya, {i>metadata <i}dapat menambahkan hingga puluhan kilobyte untuk setiap gambar.

Singkatnya, sebagai langkah pertama dalam mengoptimalkan efisiensi aset Anda, buat inventaris berbagai jenis konten dan pertimbangkan jenis pengoptimalan khusus konten yang dapat diterapkan untuk mengurangi ukurannya. Kemudian—setelah Anda mengetahui pengoptimalannya, otomatiskan pengoptimalan ini dengan menambahkannya ke 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 pada aset tersebut. Hal ini selangkah lebih maju dengan menelusuri pola berulang dalam payload berbasis teks secara agresif sebelum mengirimkannya ke pengguna, dan melakukan dekompresi setelah pola tersebut tiba di browser pengguna. Hasilnya adalah pengurangan resource tersebut lebih lanjut dan signifikan, dan waktu download yang lebih cepat setelahnya.

  • 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, dan akan memberitahukan dukungan untuk keduanya di header permintaan HTTP Accept-Encoding.
  • Server Anda harus dikonfigurasi untuk mengaktifkan kompresi. Software server web akan sering mengaktifkan modul untuk mengompresi resource berbasis teks secara default.
  • Gzip dan Brotli dapat disesuaikan untuk meningkatkan rasio kompresi dengan menyesuaikan tingkat kompresi. Untuk {i>gzip<i}, pengaturan 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 trade-off terbaik antara rasio kompresi dan kecepatan. Namun, kompresi statis memungkinkan, yaitu saat respons dikompresi sebelumnya, dan oleh karena itu 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 mengurangi aspek kompresi yang perlu Anda khawatirkan.

gzip dan Brotli adalah kompresor umum yang dapat diterapkan ke aliran byte. Di balik layar, mereka mengingat beberapa konten file yang telah diperiksa sebelumnya, lalu berupaya menemukan dan mengganti fragmen data duplikat secara efisien.

Dalam praktiknya, gzip dan Brotli memiliki performa terbaik pada konten berbasis teks, dan sering kali mencapai tingkat kompresi hingga 70-90% untuk file yang lebih besar. Namun, menjalankan aset algoritma ini yang sudah dikompresi menggunakan algoritma alternatif—seperti sebagian besar format gambar yang menggunakan teknik kompresi lossless atau lossy—menghasilkan 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 melayani resource yang dikompresi saat klien memintanya.

File Algorithm Ukuran yang tidak dikompresi 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%
{i>jquery-3.7.1.js<i} Brotli 302 KiB 69 KiB 77%
{i>jquery-3.7.1.js<i} gzip 302 KiB 83 KiB 73%
{i>jquery-3.7.1.min.js<i} Brotli 85 KiB 27 KiB 68%
{i>jquery-3.7.1.min.js<i} gzip 85 KiB 30 KiB 65%
{i>lodash-4.17.21.js<i} Brotli 531 KiB 73 KiB 86%
{i>lodash-4.17.21.js<i} gzip 531 KiB 94 KiB 82%
{i>lodash-4.17.21.min.js<i} Brotli 71 KiB 23 KiB 68%
{i>lodash-4.17.21.min.js<i} gzip 71 KiB 25 KiB 65%

Tabel sebelumnya menunjukkan penghematan yang dapat diberikan oleh kompresi Brotli dan gzip untuk beberapa library JavaScript yang populer. Penghematannya berkisar dari 65% hingga 86%, bergantung pada file dan algoritma. Sebagai referensi, tingkat kompresi maksimum diterapkan ke setiap file untuk Brotli dan gzip. Jika memungkinkan, sebaiknya gunakan 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 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 cara kerja kompresi adalah dengan membuka Chrome DevTools, membuka panel Jaringan, memuat halaman pilihan Anda, dan mengamati bagian paling bawah panel jaringan.

Pembacaan DevTools dari ukuran sebenarnya versus ukuran transfer.
Representasi ukuran transfer (yaitu, dikompresi) dari semua resource halaman versus ukuran sebenarnya seperti yang divisualisasikan di panel jaringan Chrome DevTools.

Seperti gambar sebelumnya, Anda akan melihat perincian:

  • Jumlah permintaan, yaitu jumlah resource yang dimuat untuk halaman.
  • Ukuran transfer semua permintaan. Hal ini mencerminkan efektivitas kompresi yang diterapkan ke resource halaman mana pun.
  • Ukuran resource semua permintaan. Hal ini mencerminkan seberapa besar resource untuk halaman setelah didekompresi.

Efek pada Data Web Inti

Peningkatan performa tidak dapat diukur kecuali ada metrik yang mencerminkan peningkatan tersebut. Inisiatif Data Web Inti dibuat untuk membuat dan meningkatkan awareness terhadap metrik yang mencerminkan pengalaman pengguna sebenarnya. Berbeda dengan metrik, seperti waktu muat halaman yang sederhana, yang tidak secara jelas menentukan kualitas pengalaman pengguna.

Saat Anda menerapkan pengoptimalan yang diuraikan dalam panduan ini ke resource di situs Anda, efeknya pada Data Web Inti dapat bervariasi, berdasarkan resource yang dioptimalkan dan metrik yang terkait. Namun, berikut adalah beberapa contoh ketika penerapan pengoptimalan ini dapat meningkatkan Data Web Inti situs Anda:

  • Resource HTML yang diminifikasi dan dikompresi dapat meningkatkan pemuatan HTML tersebut, visibilitas subresource-nya, sehingga meningkatkan pemuatan HTML tersebut. 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 dapat menyebabkan masalah pertentangan 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, waktu pemuatan resource dapat dikurangi melalui kompresi berbasis teks. Hal ini berbeda dengan pengoptimalan yang akan Anda lakukan untuk 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. Jika Anda menggunakan font web, maka praktik terbaik pengoptimalan font web akan berlaku. Namun, jika Anda tidak menggunakan font web—melainkan font sistem yang ditampilkan tanpa menimbulkan waktu pemuatan resource—meminimalkan dan mengompresi CSS akan mengurangi waktu pemuatannya, yang berarti rendering node teks LCP potensial dapat terjadi lebih cepat.

Kesimpulan

Cara Anda mengoptimalkan encoding dan transfer aset berbasis teks adalah konsep performa dasar, tetapi konsep tersebut memiliki dampak besar. Pastikan Anda melakukan semua yang bisa dilakukan agar resource yang memenuhi syarat untuk diminifikasi dan kompresi akan mendapatkan manfaat dari pengoptimalan tersebut.

Lebih penting lagi, pastikan bahwa proses ini berjalan secara otomatis. 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. Agar prosesnya semudah mungkin, gunakan CDN untuk mengotomatiskan kompresi, karena CDN tidak hanya dapat mengompresi resource untuk Anda, tetapi juga dapat melakukannya dengan sangat cepat.

Dengan menggabungkan konsep performa dasar ini ke dalam arsitektur situs, Anda dapat memastikan bahwa upaya pengoptimalan performa Anda berjalan dengan baik, dan bahwa pengoptimalan berikutnya dapat didasarkan pada dasar praktik dasar yang kuat.