feat(docker): prekompresja gzip plików statycznych

[mpasternak]

Problem

Nginx w bpp-deploy ma gzip_static on włączone od dawna. Ta dyrektywa nie znaczy „kompresuj statyki" — znaczy „wyślij x.js.gz, jeśli istnieje".

W obrazie nie było ani jednego .gz (zmierzone na 202608.1399rc5: 3429 plików, 0 sztuk). Nginx cicho spadał na gzip on i kompresował plotly.min.js (4,4 MB) od nowa przy każdym cache-missie.

Objawu nie ma żadnego: strona działa, Content-Encoding jest, różni się tylko CPU brzegu i poziom kompresji (w locie 5, offline 9).

Rozwiązanie — dwa kroki, bo jeden nie wystarczał

1. R16 w docker/bpp_base/Dockerfile — gzip -9 na staticroot.baked zaraz po collectstatic.
Zmierzone: 1813 plików, 2 s buildu, +12,5 MB do obrazu.

2. docker/appserver/entrypoint-appserver.sh — gzip na $STATIC_ROOT/CACHE po manage.py compress.

Drugi krok jest konieczny, bo bare.html pakuje bundle.js (786 KB) w {% compress js %} — przeglądarka pobiera CACHE/js/output.<hash>.js, plik, który powstaje dopiero w runtime i którego build-time nie widzi. Trzy największe assety są odwrotnie: plotly.min.js (4,4 MB), three-bundle.js (1,9 MB) i cytoscape-bundle.js (886 KB) są ładowane przez {% static %} poza blokami {% compress %}, czyli wprost z .baked.

Dlaczego build-time, a nie krok po stronie wdrożenia

Nginx serwując x.js.gz nie porównuje mtime z x.js. Nieaktualny .gz = wieczne serwowanie starego JS-a wszystkim przeglądarkom, bez śladu w logach; operator zgłasza to jako „zaktualizowałem i nic się nie zmieniło".

Generowanie .gz w tym samym kroku co plik źródłowy usuwa problem z definicji — nie ma okna, w którym mogłyby się rozjechać. W CACHE/ dodatkowo chroni content-hash w nazwie (zmiana treści = nowa nazwa, nie nadpisanie).

Zabezpieczenia

• -size +1000c odpowiada gzip_min_length 1000 z konfiguracji nginksa.
• Kompresujemy wyłącznie formaty tekstowe — woff/png/webp są już skompresowane, .gz tylko zajmowałby miejsce.
• Drugi find kasuje .gz, który wyszedł nie mniejszy od oryginału (nginx serwowałby większy plik klientom deklarującym gzip). Na obecnym drzewie takich przypadków jest 0 — to zabezpieczenie na przyszłe assety.
• Błąd w entrypoincie nie eskaluje (skrypt leci z sh -e) — degraduje się miękko do gzipu w locie, ale loguje głośno, żeby regresja nie była niewidoczna.

Weryfikacja

Fragmenty wykonane na prawdziwym drzewie z opublikowanego obrazu, dokładnie w postaci, w jakiej wykona je Docker:

• exit 0 pod set -e, 1813 plików .gz;
• integralność: gzip -dc | cmp na losowej próbce — zgodne bajt w bajt;
• guard rozmiaru sprawdzony podłożonym plikiem nieściśliwym (usunięty poprawnie, bundle.js.gz nietknięty) — żeby nie był martwym kodem;
• entrypoint przetestowany w trzech ścieżkach: CACHE z plikami / brak CACHE / find z błędem — nigdzie nie wywraca startu.

Kompresja kluczowych assetów: plotly.min.js 4558732 → 1331125 B, three-bundle.js 1942818 → 424346 B, bundle.js 805055 → 226887 B.

Nie budowałem pełnego obrazu (kilkuminutowy build z yarn/uv) — pierwszy build w CI potwierdzi resztę.

Stage testserver (dev) celowo pominięty: gzip_static to funkcja nginksa, a dev serwuje statyki Django.

Powiązane

Sparowany z iplweb/bpp-deploy#31, który zapisuje dowody i werdykt w sprawie brotli/zstd (odrzucone — trzy blokady po stronie obrazu CRS). Tamten PR nie zmienia zachowania; ten włącza gzip_static realnie.

🤖 Generated with Claude Code

https://claude.ai/code/session_01J35fM3toviqNDsGxRg6P1c