Periksa kompresi respons HTML, CSS, dan JavaScript melalui Chrome DevTools dengan membaca header serta membedakan ukuran transfer dan isi sumber daya.

Periksa respons yang diterima, bukan dugaan dari ukuran file

Ukuran berkas pada komputer pengembang belum menjelaskan bagaimana berkas itu dikirim kepada pengunjung. Kompresi HTTP dapat mengurangi data yang ditransfer tanpa mengubah isi yang dipulihkan oleh browser. Pemeriksaan perlu melihat respons yang benar-benar diterima untuk sumber daya tertentu. Tutorial ini memakai Chrome DevTools agar pengelola dapat mencatat keadaan HTML, CSS, dan JavaScript pada halaman publik. Tidak diperlukan perubahan konfigurasi server untuk mengumpulkan pengamatan awal yang berguna bagi percakapan teknis.

MDN membedakan kompresi pada format berkas dari kompresi pada tingkat HTTP. Karena itu, foto yang sudah menggunakan format terkompresi tidak harus diperlakukan sama dengan dokumen teks. Sasaran latihan ialah menghasilkan daftar sampel dan bukti pengirimannya, bukan menyalakan kompresi pada semua jenis berkas. Hasil pemeriksaan juga tidak membuktikan website sudah cepat secara keseluruhan. Waktu respons aplikasi, jumlah sumber daya, dan pekerjaan browser tetap memerlukan penilaian sesuai masalah yang sedang ditangani.

Diagram browser menawarkan encoding melalui Accept-Encoding dan menerima respons terkompresi dengan Content-Encoding sebelum memulihkan isinya
Kemampuan yang dikirim klien dan encoding pada respons merupakan dua bukti yang berbeda; diagram memakai contoh konseptual.

Prasyarat: tentukan halaman publik dan tiga jenis sampel

Siapkan Chrome desktop, koneksi yang stabil untuk pemeriksaan kecil, dan halaman milik sendiri yang dapat dibuka tanpa login. Pilih halaman informasi biasa, bukan proses pembayaran atau pengiriman formulir. Buat catatan dengan kolom alamat sumber daya, jenis isi, status respons, Accept-Encoding, Content-Encoding, ukuran yang diamati, dan waktu pemeriksaan. Anda tidak perlu merekam seluruh isi permintaan. Cukup salin informasi terbatas yang diperlukan untuk menjelaskan kompresi pada sumber daya publik tersebut.

Tentukan sampel dokumen halaman, satu stylesheet, dan satu berkas JavaScript jika tersedia. Jika website tidak memuat salah satu jenis itu, catat keadaan sebenarnya dan jangan membuat permintaan tambahan yang tidak diperlukan. Gunakan versi halaman yang sama ketika nanti membandingkan hasil. Bila tim baru menerapkan pembaruan, tanyakan versi aset yang menjadi acuan. Membandingkan berkas berbeda hanya karena namanya mirip dapat membuat kesimpulan tentang ukuran transfer menjadi menyesatkan sejak awal.

Ilustrasi catatan pemeriksaan terpisah untuk HTML, CSS, dan JavaScript dengan header, ukuran, serta kondisi pengujian ulang
Nilai tiap sumber daya dicatat terpisah agar pembanding tidak mencampur jenis berkas atau jalur penyajiannya.

Langkah 1: rekam pemuatan halaman pada panel Network

Buka halaman, tekan F12 atau Ctrl+Shift+I untuk membuka DevTools, lalu pilih Network. Pastikan perekaman aktif. Aktifkan Disable cache selama pemeriksaan ini dan muat ulang halaman agar pengamatan tidak sekadar berasal dari cache browser. Dokumentasi Chrome menjelaskan pengaturan tersebut untuk mengamati pengalaman pemuatan tanpa cache browser. Ini tidak berarti seluruh lapisan perantara, seperti cache pada layanan distribusi, ikut dinonaktifkan. Catat kondisi yang Anda ubah agar perbandingan berikutnya memakai keadaan yang sama.

Tunggu daftar permintaan stabil, kemudian cari dokumen utama yang memuat halaman yang sedang diuji. Cocokkan alamatnya dengan tujuan akhir yang Anda buka. Jika ada pengalihan, jangan menilai respons pengalihan sebagai isi HTML akhir. Bila permintaan gagal atau tidak menghasilkan respons isi yang dapat dinilai, tandai sampel belum dapat diperiksa. Jangan mengisi kolom kompresi berdasarkan asumsi dari sumber daya lain pada halaman, sebab respons setiap alamat dapat mempunyai perilaku berbeda.

Langkah 2: pisahkan kemampuan klien dari pilihan respons

Pilih permintaan pada kolom Name, buka tab Headers, lalu lihat bagian Request Headers dan Response Headers. Cari Accept-Encoding pada sisi permintaan serta Content-Encoding pada sisi respons. MDN menjelaskan bahwa Accept-Encoding pada permintaan menyampaikan encoding yang dapat dipahami klien, sementara Content-Encoding menjelaskan encoding yang diterapkan pada representasi respons. Adanya nama algoritma pada permintaan belum membuktikan respons memakai algoritma itu. Isi dua kolom secara terpisah sesuai informasi yang terlihat.

Jika Content-Encoding menampilkan gzip atau br, catat nilai tersebut untuk sampel yang dipilih. br merupakan penanda Brotli, sedangkan gzip merupakan encoding lain yang dapat ditemui dalam praktik. Jangan menyimpulkan daftar tersebut mencakup seluruh pilihan yang mungkin didukung sistem. Bila header tidak tampak, tulis 'tidak terlihat pada respons sampel' beserta statusnya. Kesimpulan yang terbatas lebih berguna daripada menyatakan seluruh website tidak memiliki kompresi berdasarkan satu permintaan yang belum diperiksa konteksnya.

Langkah 3: ulangi pada CSS dan JavaScript yang benar

Pilih satu stylesheet yang benar-benar digunakan halaman, lalu ulangi pencatatan header. Lakukan hal yang sama pada satu berkas JavaScript jika tersedia. Perhatikan hostname sumber daya: aset dari layanan lain belum tentu mengikuti pengaturan server website utama. Kelompokkan temuan menurut pemilik jalur penyajiannya agar laporan dapat diarahkan dengan tepat. Jangan meminta pengelola hosting mengubah respons layanan pihak lain tanpa lebih dahulu mengenali dari mana berkas tersebut berasal dan siapa yang mengendalikannya.

MDN menerangkan bahwa server dapat tidak menerapkan kompresi meskipun klien mendukung algoritma yang sama. Karena itu, nama algoritma yang berbeda antarberkas bukan otomatis kerusakan. Jika sampel teks yang besar tidak menunjukkan encoding yang diharapkan tim, tanyakan kebijakan penyajiannya kepada pengembang. Sertakan jenis isi dan alamat berkas agar pembahasan mempunyai acuan. Hindari langsung menyimpulkan penyebabnya berasal dari paket hosting, plugin tertentu, atau konfigurasi yang belum Anda lihat dan belum dikonfirmasi.

Langkah 4: baca ukuran transfer dan ukuran sumber daya secara hati-hati

Pada pengaturan Network, aktifkan Big request rows untuk melihat informasi ukuran tambahan sesuai tampilan Chrome. Dokumentasinya menjelaskan ukuran sumber daya setelah dekompresi pada tampilan tersebut. Catat label serta angka yang terlihat, kemudian cocokkan dengan header sampel. Jangan memperlakukan total seluruh halaman sebagai ukuran satu berkas. Total juga hanya mencakup permintaan yang terekam pada sesi pemeriksaan, sehingga membuka DevTools terlambat dapat menghasilkan daftar yang tidak mewakili seluruh pemuatan sejak awal.

Sebagai contoh hipotetis, dua kolom laporan dapat menyatakan 'encoding respons: br' dan 'ukuran transfer lebih kecil daripada ukuran sumber daya yang dimuat'. Jangan mengubah contoh itu menjadi klaim persentase penghematan website yang belum diukur. Bila ingin menghitung perubahan setelah perbaikan, gunakan aset dan kondisi pembanding yang sama serta jelaskan metrik yang dipakai. Selisih angka pada antarmuka perlu ditafsirkan sesuai definisinya, bukan langsung disebut sebagai penghematan tagihan atau peningkatan kecepatan yang pasti.

Langkah 5: tentukan temuan yang memerlukan tindak lanjut

Pisahkan hasil menjadi sampel dengan encoding yang teramati, sampel yang memerlukan penjelasan, dan sampel yang belum dapat dinilai. Untuk kategori kedua, tuliskan harapan yang disepakati, misalnya pengembang mengharapkan stylesheet tertentu disajikan terkompresi. Jika belum ada harapan teknis, minta penilaian kebutuhan lebih dahulu. Cara ini mencegah seluruh respons tanpa header yang Anda cari otomatis dinyatakan gagal, termasuk berkas kecil atau jenis media yang sudah mempunyai kompresi pada formatnya sendiri.

Prioritaskan pembahasan berdasarkan dampak yang dapat dijelaskan, seperti sumber daya teks besar yang dipakai banyak halaman dan berada dalam kendali tim. Sertakan tanggal, alamat, jenis respons, dan nilai header terbatas yang relevan. Jangan mengirim ekspor riwayat jaringan lengkap hanya untuk membuktikan satu nilai. Bukti yang ringkas membuat pengembang lebih mudah mengulang kasus serta meninjau lapisan penyajian yang tepat. Keputusan perubahan tetap dilakukan oleh pihak yang berwenang setelah mempertimbangkan konfigurasi dan beban pengelolaannya.

Langkah 6: uji ulang setelah perubahan yang disetujui

Sesudah pihak yang berwenang melakukan koreksi, buka kembali halaman dan ulangi pencatatan dengan keadaan pembanding yang sama. Pastikan aset yang dipilih merupakan versi yang sedang dinilai. Periksa header, status, ukuran, dan apakah isi halaman tetap tampil serta berfungsi sebagaimana mestinya. Jangan berhenti pada perubahan angka karena kompresi yang diterapkan perlu tetap menghasilkan isi yang dapat dipulihkan dengan benar oleh browser. Simpan hasil sebelum dan sesudah dengan penjelasan ruang lingkup sampelnya.

Jika tujuan pengujian tercapai, nyatakan secara konkret, misalnya encoding yang diharapkan terlihat pada tiga respons sampel dan pemuatan halaman yang diperiksa tidak menunjukkan masalah baru. Pernyataan tersebut merupakan format kesimpulan, bukan laporan hasil nyata dari situs tertentu. Nonaktifkan Disable cache setelah selesai bila pengaturan itu tidak lagi diperlukan. Pengujian ulang yang terarah membantu membuktikan perubahan pada kasus yang diperiksa, tanpa menjanjikan semua halaman dan semua perangkat otomatis mempunyai hasil yang sama.

Kesalahan umum saat menafsirkan kompresi HTTP

Kesalahan yang sering mengaburkan pemeriksaan adalah membaca Accept-Encoding sebagai bukti kompresi respons, memakai angka dari cache sebagai pembanding transfer baru, serta meminta kompresi ulang semua foto. MDN mengingatkan bahwa mengompresi media yang sudah terkompresi dapat tidak membantu dan bahkan menambah ukuran. Hindari pula menyamakan kompresi HTTP dengan penghapusan bagian kode atau pengurangan dimensi gambar. Kebutuhan optimasi berbeda harus dinilai dengan ukuran dan cara pemeriksaan yang sesuai dengan sumber masalahnya.

Kenali layanan melalui https://www.jagoweb.com/ dan informasi hosting cPanel di https://www.jagoweb.com/hosting-cpanel. Saat meminta bantuan, jelaskan sampel yang diamati dan konfirmasikan pengaturan yang tersedia untuk layanan yang digunakan. Tutorial ini tidak mengasumsikan algoritma tertentu aktif pada setiap paket. Daftar pemeriksaan dapat dipakai kembali ketika jalur aset, server, atau layanan distribusi berubah, sehingga keputusan pemeliharaan bertumpu pada respons aktual yang diterima pengunjung dan bukti yang dapat diulang.

Bacaan terkait

Sumber dan referensi