Kompresimi i të njëjtit skedar çdo herë

Apache i kompreson përgjigjet në çastin e dërgimit. Për një faqe që ndryshon çdo herë, kjo është e vetmja mundësi. Për një fletë stili që ndryshon një herë në muaj, do të thotë se serveri bën të njëjtën punë për çdo vizitor, për javë, dhe e hedh rezultatin çdo herë. Nuk ka ruajtje të tij në memorie të ndërmjetme.

E matur më 19 gusht 2026 përmes një lidhjeje ekzistuese, me skedarët e këtij uebsajti style.css (124 kB) dhe world.js (102 kB):

	koha	bajte
pa kompresim	2,9 ms	124 755
gzip, gjatë dërgimit	18,1 ms	34 995
brotli, gjatë dërgimit	14,5 ms	32 685
world.js, gzip	47,9 ms	38 283
world.js, brotli	15,9 ms	38 086

Dyzet e tetë milisekonda CPU për kërkesë, për të prodhuar një rezultat identik bajt për bajt. Në një server të vogël kjo nuk është gabim rrumbullakimi.

Kompreso një herë, në disk

Një hap përgatitjeje shkruan skedarin e kompresuar pranë origjinalit dhe një rregull rishkrimi e dërgon kur shfletuesi thotë se pranon gzip. Dërgimi i një skedari të gatshëm kushton sa dërgimi i çdo skedari.

gzip dhe jo brotli, për një arsye të thjeshtë: në këtë makinë nuk ka program brotli të instaluar. Skedarët dalin rreth 7% më të mëdhenj se me brotli dhe koha e serverit është një e pesta e kostos së brotli gjatë dërgimit. Ia vlente ky kompromis tani, në vend që të pritej një përgjigje më e bukur.

Versioni vendoset në emrin e skedarit

Përgatitja shkruan style.css.<mtime>.gz, ndërsa ?v= në kodin e faqes është e njëjta kohë ndryshimi. Rregulli i rishkrimit aktivizohet vetëm kur ekziston një skedar me numrin përkatës.

Kjo zgjidhje ka një veti që ia vlen të synohet me qëllim: nëse fleta e stilit ndryshon dhe harrohet rigjenerimi, numri në kodin e faqes tregon një skedar që nuk ekziston, rregulli nuk aktivizohet dhe Apache dërgon normalisht origjinalin. Në rastin më të keq mungon përshpejtimi. Nuk mund të dalë një fletë stili e vjetruar. Çdo skemë ruajtjeje në memorie të ndërmjetme duhet kontrolluar me këtë pyetje — kur dështon, bëhet e ngadaltë apo jep rezultat të gabuar?

Gabimi në mes

Skedari që dërgohet është tashmë gzip, prandaj nuk duhet kompresuar sërish gjatë dërgimit. Konfigurimi fillimisht caktonte no-gzip, që ndal një nga dy kompresuesit e Apache. Tjetri, mod_brotli, e kompresonte me brotli skedarin e gatshëm gzip, ndërsa koka e përgjigjes vazhdonte të thoshte gzip.

Shfletuesit merrnin përmbajtje të palexueshme. Kjo nuk u zbulua duke parë faqen — u zbulua duke mbledhur bajtet dhe duke gjetur një numër pa kuptim. Nevojiten si no-gzip ashtu edhe no-brotli dhe vetëm njëri është i dukshëm.