Mengoptimalkan encoding dan ukuran transfer aset berbasis teks

Selain menghilangkan unduhan sumber daya yang tidak perlu, hal terbaik yang dapat Anda lakukan untuk meningkatkan kecepatan pemuatan halaman adalah meminimalkan ukuran download secara dan mengompresi resource yang tersisa.

Dasar-dasar kompresi data

Setelah Anda menyiapkan situs web agar tidak mengunduh sumber daya yang tidak terpakai, langkah berikutnya adalah mengompresi sisa resource yang memenuhi syarat yang dimiliki browser yang akan diunduh. Tergantung pada jenis resource—teks, gambar, font, dan sebagainya ada banyak teknik berbeda yang bisa dipilih: alat generik yang bisa diaktifkan di server web, pengoptimalan pra-pemrosesan untuk konten tertentu serta pengoptimalan spesifik per resource yang memerlukan input dari developer.

Memberikan performa terbaik membutuhkan kombinasi dari semua hal berikut teknik:

  • 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 memiliki kontribusi algoritma, teknik, dan pengoptimalan untuk meningkatkan kompresi data, rasio kompresi, kecepatan kompresi, dan memori yang dibutuhkan oleh berbagai kompresi algoritme.

Diskusi lengkap tentang kompresi data berada di luar cakupan panduan ini. Namun, penting untuk dipahami—pada tingkat tinggi—cara kerja kompresi, dan teknik yang dapat Anda gunakan untuk mengurangi ukuran berbagai aset yang halaman Anda butuhkan.

Untuk menggambarkan prinsip-prinsip inti dari teknik-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 "#" . Anotasi tidak memengaruhi makna pesan, atau perilakunya.
  2. Pesan dapat berisi header, yang merupakan pasangan nilai kunci (dipisahkan oleh ":" di contoh sebelumnya) yang muncul di awal pesan.
  3. Pesan membawa payload teks.

Apa yang dapat dilakukan untuk mengurangi ukuran pesan sebelumnya, yang dimulai dengan 200 karakter?

  1. Komentarnya menarik, tetapi tidak memengaruhi makna pesan. Hilangkan saat mengirimkan pesan.
  2. Ada teknik bagus untuk mengenkode header dengan cara yang efisien. Sebagai misalnya jika Anda tahu bahwa semua pesan memiliki "format" dan “tanggal”, Anda bisa mengubahnya menjadi ID bilangan bulat pendek dan mengirimnya saja. Namun, hal itu mungkin itu tidak benar, jadi lebih baik untuk membiarkannya saja untuk saat ini.
  3. Payload berupa teks saja. Meskipun kita tidak tahu sebenarnya apa isi dari (tampaknya, ini menggunakan "secret-cipher"), hanya dengan melihat teks menunjukkan bahwa ada banyak redundansi di dalamnya. Mungkin alih-alih mengirim berulang, Anda cukup menghitung jumlah huruf yang berulang dan mengenkodenya dengan lebih efisien. Misalnya, "AAA" menjadi "3A", yang mewakili deret tiga A.

Menggabungkan teknik ini akan memberikan hasil berikut:

format: secret-cipher
date: 08/25/16
3A2Z4B3E3M 3E3T3A

Pesan baru tersebut panjangnya 56 karakter, yang berarti Anda telah mengompresi pesan asli sebesar 72%. Itu pengurangan yang signifikan!

Ini adalah sebuah contoh mainan tentang bagaimana algoritma kompresi dapat efektif dalam mengurangi ukuran transfer resource berbasis teks. Dalam praktiknya, kompresi algoritma jauh lebih canggih daripada yang digambarkan dalam contoh sebelumnya, dan di web, algoritma kompresi dapat digunakan untuk mengurangi jumlah download secara signifikan atau waktu untuk sumber daya. Dengan menerapkan kompresi pada aset berbasis teks, halaman web akan dapat menghabiskan lebih sedikit waktu untuk memuat resource, sehingga pengguna dapat melihat dampak dari sumber daya itu lebih cepat daripada tanpa kompresi.

Minifikasi: pra-pemrosesan, dan pengoptimalan khusus konteks

Teknik pertama yang dibahas di sini adalah minifikasi. Meskipun minifikasi tidak hanya algoritma kompresi, ini adalah cara untuk menghilangkan kebutuhan dan karakter berlebihan yang digunakan dalam kode sumber untuk membuat sumber daya lebih mudah dibaca manusia. Namun, keterbacaan tidak diperlukan untuk mempertahankan fungsionalitas kode sumber tersebut di situs produksi, dan dapat menunda pemuatan referensi yang tersedia di web.

Minifikasi adalah jenis pengoptimalan khusus konten yang dapat secara signifikan mengurangi ukuran resource yang dikirim, dan pengoptimalan merupakan solusi terbaik sebagai bagian dari proses build dan deployment. Misalnya, pemaket adalah jenis perangkat lunak yang biasa digunakan yang secara otomatis dapat mengecilkan sumber daya yang sebelum deployment kode produksi baru ke situs.

Cara terbaik untuk mengompresi data yang redundan atau tidak perlu adalah dengan menghilangkannya. Namun, Anda tidak bisa begitu saja menghapus data arbitrer. Namun, dalam beberapa konteks di mana kita memiliki pengetahuan khusus tentang format data dan propertinya, mengurangi ukuran {i>payload<i} secara signifikan tanpa mempengaruhi makna atau kemampuan yang 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 yang berbeda mengenai apa saja yang dianggap valid konten, aturan yang berbeda untuk menentukan komentar, dan sebagainya. Pertanyaan pertanyaan yang muncul adalah "bagaimana ukuran halaman ini bisa dikurangi?"

  • Komentar kode adalah sahabat terbaik seorang developer, tetapi browser tidak memerlukan mereka! Menghapus CSS (/* ... */), HTML (<!-- ... -->), dan JavaScript (// ...) mengurangi total ukuran transfer halaman dan subresource.
  • "Cerdas" Kompresor CSS dapat melihat bahwa kita menggunakan cara yang tidak efisien untuk menentukan aturan untuk .awesome-container, dan menciutkan dua deklarasi menjadi satu tanpa mempengaruhi gaya lain, menghemat lebih banyak byte. Di atas serangkaian aturan CSS, menghapus redundansi semacam ini bisa menambah—tetapi mungkin menjadi sesuatu yang dapat diterapkan secara agresif, karena pemilih sering yang diduplikasi dalam konteks yang berbeda, seperti dalam kueri media.
  • Spasi dan tab adalah kemudahan developer dalam HTML, CSS, dan JavaScript. Kompresor tambahan bisa menghapus semua tab dan spasi. Tidak seperti lainnya penghapusan duplikat, pengoptimalan semacam ini dapat diterapkan secara adil agresif, asalkan spasi atau tab itu tidak diperlukan untuk presentasi—misalnya, Anda ingin mempertahankan spasi dalam teks di dokumen HTML, karena mereka memastikan keterbacaan konten yang 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 sebelumnya, halaman berkurang dari 516 menjadi 204 karakter, menghemat sekitar 60%. Memang, tidak terlalu mudah dibaca, tapi tidak harus harus dapat digunakan. Praktik pengembangan modern juga memungkinkan Anda untuk menyimpan versi kode program yang terformat dengan baik dan dapat dibaca terpisah dari kode yang dioptimalkan dengan baik yang dikirim ke produksi. Dikombinasikan dengan peta sumber—yang memberikan representasi yang dapat dibaca dari kode produksi mempermudah Anda memecahkan masalah bug dalam produksi—Anda dapat memiliki pengalaman developer yang baik sekaligus mengoptimalkan performa dari pengalaman pengguna.

Contoh sebelumnya menggambarkan poin penting: contoh tujuan umum kompresor—misalnya, yang dirancang untuk mengompresi teks arbitrer—dapat melakukan mengompresi halaman pada contoh sebelumnya, tetapi tidak akan pernah tahu menghapus komentar, menciutkan aturan CSS, atau lusinan aturan khusus konten lainnya pengoptimalan. Inilah sebabnya mengapa pra-pemrosesan, minifikasi, dan sumber daya kontekstual pengoptimalan itu penting.

Demikian pula, teknik yang dijelaskan di atas dapat diperluas lebih dari sekadar teknik aset. Gambar, video, dan jenis konten lainnya semuanya memiliki bentuk metadata dan berbagai payload. Misalnya, setiap kali Anda mengambil gambar dengan kamera, filenya biasanya menyematkan banyak informasi tambahan: pengaturan kamera, lokasi, dan sebagainya. Bergantung pada aplikasi Anda, data ini mungkin sangat penting (misalnya, situs berbagi foto) atau mungkin sama sekali tidak berguna. Anda pertimbangkan apakah layak dihapus atau tidak. Dalam praktiknya, {i>metadata <i}ini dapat menambahkan hingga puluhan kilobita untuk setiap gambar.

Singkatnya, sebagai langkah pertama dalam mengoptimalkan efisiensi aset Anda, bangun inventaris dari berbagai jenis konten dan mempertimbangkan jenis pengoptimalan khusus konten yang dapat Anda terapkan untuk mengurangi ukurannya. Kemudian—setelah Anda telah mengetahuinya, otomatiskan pengoptimalan tersebut 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 kompresinya. Hal ini selangkah lebih maju dengan menelusuri pola berulang dalam {i>payload<i} berbasis teks sebelum mengirimkannya ke pengguna, dan melakukan dekompresi setelah mereka masuk ke {i>browser<i} pengguna. Tujuan pengurangan sumber daya tersebut secara signifikan dan terus-menerus, dan dampak waktu download yang lebih cepat.

  • {i>gzip<i} dan Brotli adalah algoritma kompresi yang umum digunakan dengan kinerja terbaik pada aset berbasis teks: CSS, JavaScript, HTML.
  • Semua browser modern mendukung kompresi gzip dan Brotli, dan akan mengiklankan mendukung keduanya dalam 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.
  • Baik gzip maupun Brotli dapat di-fine-tune untuk meningkatkan rasio kompresi dengan menyesuaikan tingkat kompresi. Untuk gzip, setelan kompresinya berkisar dari 1 sampai 9, 9 adalah yang terbaik. Untuk Brotli, rentang ini adalah 0 hingga 11, dengan 11 menjadi yang terbaik. Namun, setelan kompresi yang lebih tinggi memerlukan waktu lebih lama. Sebagai resource yang dikompresi secara dinamis—yaitu, pada saat permintaan—setelan yang berada di tengah rentang cenderung menawarkan kompromi terbaik rasio kompresi dan kecepatan. Namun, kompresi statis yaitu ketika respons dikompres sebelumnya, dan dapat Oleh karena itu, gunakan setelan kompresi paling agresif yang tersedia untuk setiap algoritma kompresi.
  • Jaringan Penayangan Konten (CDN) biasanya menawarkan kompresi otomatis sebesar sumber daya yang memenuhi syarat. CDN juga dapat mengelola kompresi dinamis dan statis untuk mengurangi aspek kompresi yang perlu Anda khawatirkan.

gzip dan Brotli adalah kompresor umum yang dapat diterapkan ke aliran data {i>byte.<i} Di balik layar, mereka mengingat beberapa isian yang telah diperiksa dari sebuah file, dan kemudian mencoba menemukan dan mengganti fragmen data duplikat di 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 yang sudah dikompresi menggunakan algoritma alternatif—seperti karena sebagian besar format gambar yang menggunakan teknik kompresi lossless atau lossy—menghasilkan sedikit atau bahkan tidak ada peningkatan.

Semua browser modern mengiklankan dukungan untuk gzip dan Brotli di Header permintaan HTTP Accept-Encoding. Namun, itu adalah milik tanggung jawab untuk memastikan bahwa server web dikonfigurasi dengan benar untuk melayani resource terkompresi saat klien memintanya.

File Algoritma Ukuran tidak dikompresi Ukuran terkompresi Rasio kompresi
sudut-1.8.3.js Brotli 1.346 KiB 256 KiB 81%
sudut-1.8.3.js gzip 1.346 KiB 329 KiB 76%
sudut-1.8.3.min.js Brotli 173 KiB 53 KiB 69%
sudut-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%
lodash-4.17.21.js Brotli 531 KiB 73 KiB 86%
lodash-4.17.21.js 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 dilakukan dengan kompresi Brotli dan gzip menyediakan beberapa library JavaScript yang sudah dikenal luas. Penghematan berkisar dari 65% hingga 86%, bergantung pada file dan algoritmanya. Sebagai referensi, nilai maksimum tingkat kompresi diterapkan ke setiap file untuk Brotli dan gzip. Di mana pun sebaiknya, lebih suka Brotli daripada gzip.

Mengaktifkan kompresi adalah salah satu cara pengoptimalan yang paling sederhana dan efektif untuk diterapkan. Jika situs web Anda tidak memanfaatkannya, Anda kehilangan peluang besar untuk meningkatkan performa bagi pengguna Anda. Untungnya, ada banyak jaringan server akan menyediakan konfigurasi {i>default<i} yang memungkinkan pengoptimalan penting ini, dan CDN sangat efektif dalam menerapkannya dengan cara menyeimbangkan antara kecepatan dan rasio kompresi.

Cara cepat untuk melihat cara kerja kompresi adalah dengan membuka Chrome DevTools, membuka Network, muat halaman pilihan Anda, dan amati bagian paling bawah panel jaringan.

Pembacaan DevTools untuk ukuran sebenarnya versus ukuran transfer.
Representasi ukuran transfer (yaitu, terkompresi) dari semua aset halaman versus ukuran sebenarnya seperti yang divisualisasikan dalam jaringan di Chrome DevTools.

Seperti gambar sebelumnya, Anda akan melihat perincian:

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

Efek pada Core Web Vitals

Peningkatan kinerja tidak dapat diukur kecuali jika ada metrik yang mencerminkan perbaikan tersebut. Inisiatif Core Web Vitals dilakukan untuk menciptakan dan meningkatkan awareness terhadap metrik yang mencerminkan pengalaman pengguna yang sebenarnya. Hal ini berbeda dengan metrik—seperti waktu muat halaman sederhana, misalnya—yang tidak dapat diterjemahkan menjadi kualitas pengalaman pengguna.

Saat Anda menerapkan pengoptimalan yang diuraikan dalam panduan ini ke referensi di efek pada Core Web Vitals dapat bervariasi, berdasarkan sumber daya dioptimalkan dan metrik yang terlibat. Namun, dalam beberapa kasus, menerapkan pengoptimalan ini dapat meningkatkan Core Web Vitals situs Anda:

  • Sumber daya HTML yang diminifikasi dan dikompresi dapat meningkatkan pemuatan HTML, visibilitas subsumber dayanya, dan karenanya meningkatkan memuatnya. Hal ini dapat bermanfaat untuk Largest Contentful Paint (LCP) laman (LCP). Meskipun petunjuk resource seperti rel="preload" dapat digunakan untuk memengaruhi kemudahan untuk menemukan sumber daya, menggunakan terlalu banyak resource dapat menyebabkan masalah pada pertentangan bandwidth. Dengan memastikan respons HTML untuk permintaan navigasi dikompresi, sumber daya di dalamnya dapat ditemukan sesegera mungkin oleh pemindai pramuat.
  • Beberapa kandidat LCP juga dapat dimuat lebih cepat menggunakan kompresi. Sebagai misalnya, gambar SVG yang merupakan kandidat LCP dapat memiliki muatan resource durasi dikurangi melalui kompresi berbasis teks. Hal ini berbeda dengan pengoptimalan yang akan Anda lakukan pada jenis gambar lainnya dikompresi secara intrinsik melalui metode kompresi lainnya—seperti cara JPEG gambar menggunakan kompresi lossy.
  • Selain itu, node teks juga dapat menjadi kandidat LCP. Bagaimana teknik yang dijelaskan dalam panduan ini tergantung pada apakah Anda menggunakan font web untuk teks laman web Anda. Jika Anda menggunakan font web, maka pengoptimalan font web praktik berlaku. Namun, jika Anda tidak menggunakan font web—melainkan font font yang ditampilkan tanpa menimbulkan durasi pemuatan resource apa pun—meminimalkan dan mengompresi CSS akan mengurangi durasi ini, yang berarti bahwa rendering node teks LCP potensial dapat terjadi lebih cepat.

Kesimpulan

Cara mengoptimalkan encoding dan transfer aset berbasis teks merupakan dasar konsep performa, tetapi ini adalah salah satu yang memiliki dampak besar. Pastikan Anda melakukan semua yang Anda bisa untuk memastikan bahwa sumber daya memenuhi syarat untuk minifikasi dan kompresi data akan diuntungkan dengan adanya pengoptimalan tersebut.

Yang lebih penting, pastikan bahwa proses ini dilakukan secara otomatis. Sebagai minifikasi, menggunakan bundler 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, menggunakan CDN untuk mengotomatiskan kompresi Anda, karena CDN sumber daya untuk Anda, tetapi mereka juga dapat melakukannya dengan sangat cepat.

Dengan menggabungkan konsep dasar performa ini ke dalam Anda dapat memastikan bahwa upaya pengoptimalan performa Anda berjalan pijakan yang baik, dan bahwa pengoptimalan selanjutnya dapat didasarkan pada fondasi yang kuat praktik dasar yang baik.