Mengompresi file yang sama setiap kali

Apache mengompresi respons secara langsung saat dikirim. Untuk halaman yang berbeda setiap kali, itulah satu-satunya pilihan. Untuk stylesheet yang berubah sebulan sekali, artinya server melakukan pekerjaan yang sama berulang-ulang untuk setiap pengunjung, selama berminggu-minggu, dan membuang hasilnya setiap kali. Tidak ada cache untuk itu.

Diukur pada 19 Agustus 2026 melalui koneksi yang sudah terbuka, dengan style.css (124 kB) dan world.js (102 kB) milik situs ini sendiri:

	waktu	byte
tanpa kompresi	2,9 ms	124.755
gzip, saat dikirim	18,1 ms	34.995
brotli, saat dikirim	14,5 ms	32.685
world.js, gzip	47,9 ms	38.283
world.js, brotli	15,9 ms	38.086

Empat puluh delapan milidetik CPU, per permintaan, untuk menghasilkan hasil yang identik byte demi byte. Pada server kecil, itu bukan sekadar kesalahan pembulatan.

Kompresi sekali, di disk

Sebuah langkah build menulis file terkompresi di sebelah file aslinya, dan aturan rewrite menyajikannya ketika browser menyatakan bahwa ia menerima gzip. Menyajikan file yang sudah jadi memakan biaya yang sama dengan menyajikan file apa pun.

gzip, bukan brotli, karena alasan yang membosankan: tidak ada biner brotli yang terpasang di mesin ini. File yang dihasilkan sekitar 7% lebih besar daripada jika dibuat dengan brotli, dan waktu server hanya seperlima dari biaya brotli yang dikompresi saat dikirim. Kompromi itu layak diambil sekarang daripada menunggu jawaban yang lebih bagus.

Versinya dimasukkan ke nama file

Build menulis style.css.<mtime>.gz, dan ?v= di markup adalah waktu modifikasi yang sama. Rewrite hanya dijalankan jika ada file dengan nomor yang cocok.

Susunan itu memiliki sifat yang layak dirancang dengan sengaja: jika stylesheet berubah dan build ulang terlupakan, nomor di markup menunjuk ke file yang tidak ada, rewrite tidak dijalankan, dan Apache menyajikan file aslinya seperti biasa. Kemungkinan terburuknya, percepatan itu tidak ada. Stylesheet yang usang tidak mungkin tersaji. Setiap skema cache perlu diuji dengan pertanyaan itu — ketika terjadi kesalahan, apakah jadi lambat atau jadi salah?

Bug di tengah-tengahnya

File yang disajikan sudah berupa gzip, jadi tidak boleh dikompresi lagi saat dikirim. Konfigurasi awalnya menetapkan no-gzip, yang menghentikan salah satu dari dua kompresor Apache. Kompresor lainnya, mod_brotli, dengan riang mengompresi file gzip yang sudah jadi itu dengan brotli, sementara header respons tetap menyatakan gzip.

Browser menerima konten yang tidak dapat dibaca. Hal ini tidak ketahuan dengan melihat halaman — melainkan dengan menjumlahkan byte dan menemukan angka yang tidak masuk akal. Baik no-gzip maupun no-brotli diperlukan, dan hanya salah satunya yang terlihat jelas.