Компресиране на един и същ файл всеки път

Apache компресира отговорите в движение. За страница, която всеки път е различна, това е единствената възможност. За стилов лист, който се променя веднъж месечно, това означава, че сървърът върши същата работа отново за всеки посетител, седмици наред, и всеки път изхвърля резултата. Кеш за това няма.

Измерено на 19 август 2026 г. по съществуваща връзка, със собствените файлове на този сайт style.css (124 kB) и world.js (102 kB):

	време	байтове
без компресия	2,9 ms	124 755
gzip, в движение	18,1 ms	34 995
brotli, в движение	14,5 ms	32 685
world.js, gzip	47,9 ms	38 283
world.js, brotli	15,9 ms	38 086

Четирийсет и осем милисекунди процесорно време на заявка, за да се получи байт по байт идентичен резултат. На малък сървър това не е грешка от закръгляване.

Компресиране веднъж, на диска

Стъпка при изграждането записва компресирания файл до оригинала, а правило за пренаписване го сервира, когато браузърът съобщи, че приема gzip. Сервирането на готов файл струва колкото сервирането на всеки друг файл.

gzip, а не brotli, по скучна причина: на тази машина няма инсталиран изпълним файл на brotli. Файловете излизат с около 7 % по-големи, отколкото биха били с brotli, а времето на сървъра е една пета от това, което струва brotli в движение. Този компромис си струваше да се приеме сега, вместо да се чака по-хубаво решение.

Версията е в името на файла

Изграждането записва style.css.<mtime>.gz, а ?v= в HTML кода е същото време на промяна. Пренаписването се задейства само когато съществува файл със съответстващото число.

Тази подредба има свойство, което си струва да се заложи нарочно: ако стиловият лист се промени, а повторното изграждане бъде забравено, числото в HTML кода сочи към файл, който не съществува, пренаписването не се задейства и Apache сервира оригинала нормално. Най-лошият случай е, че ускорението липсва. Остарял стилов лист не може да излезе. Всяка схема за кеширане трябва да се проверява с този въпрос — когато нещо се обърка, става ли бавно или става грешно?

Грешката по средата

Сервираният файл вече е gzip, така че не бива да се компресира отново на излизане. Първоначално конфигурацията задаваше no-gzip, което спира единия от двата компресора на Apache. Другият, mod_brotli, весело компресира готовия gzip файл с brotli, докато заглавката на отговора продължаваше да казва gzip.

Браузърите получаваха нечетимо съдържание. Това не беше забелязано при поглед към страницата — беше забелязано при сумиране на байтовете, когато се получи число без никакъв смисъл. Трябват и двете: no-gzip и no-brotli — и само едното от тях е очевидното.