Poze încărcate la greutatea pe care vopsirea și-o permite

A doua jumătate a lui #69 (closed), după ce Vitalie a ales varianta ușoară pe comparația randată: aceeași poză la o compresie mai strânsă, fără diferență vizibilă nici la detaliu pixel cu pixel.

De ce acum

După livrarea din !95 (merged), fereastra pe care Lantern o taxează pentru cea mai mare vopsire s-a strâns la 3 cereri și 100.658 de octeți pe prima pagină. Dintre ei, 80.278 sunt poza. Documentul și /config.js nu se mai pot strânge fără a atinge altceva, deci poza e tot ce a mai rămas între 2,48 s măsurat și pragul de 2,5 s cu marjă.

Ce se schimbă

Treapta de calitate. ENCODE_STEPS din backend/src/lib/uploads.ts pornea de la WebP q80; pornește acum de la 68. Aici numerele nu mai coincid cu cele ale uneltei de build (tools/image-optimizer, rămasă la 80) — și e în regulă: aceea encodează fișiere puse de un designer la mărimea la care se văd, asta o fotografie pe care un operator o alege, o publică pe toată lățimea și n-o mai vede niciodată. Poza de 77 KB devine 53.

Pozele deja publicate nu câștigă nimic dintr-un număr care se aplică la încărcare, și tocmai pe ele se face măsurătoarea. prisma/reencode-banner-images.ts le re-encodează.

Adresă nouă, nu același fișier rescris: /uploads/ se servește cu immutable, deci un fișier înlocuit pe loc și-ar păstra octeții vechi în orice cache care l-a văzut, un an. Ordinea e cea a lui convert-uploads-to-webp.ts: fișierul nou scris întâi, rândul repointat al doilea, cel vechi șters ultimul — o rulare întreruptă oriunde lasă o pagină care merge.

Doar banner-ele. Restul încărcărilor sunt tot la 80 și merită aceeași trecere, dar nu în aceeași schimbare: astea sunt cele din drumul vopsirii și astea au fost arătate și confirmate. Restul primește issue propriu.

Prag de 15%. Re-encodarea unui fișier deja la calitatea asta economisește un procent-două, deci scriptul îl ignoră. Pragul e ce face a doua apăsare un gol, nu o a doua generație de pierdere.

Verificat

Backend: build plus 723 de teste, dintre care 4 noi care rulează scriptul cap-coadă — adresă nouă, fișier vechi șters abia după repointare, calea committată neatinsă, a doua rulare fără efect, fișier deja ușor lăsat în pace. Frontend: lint, build și 502 teste.

Jobul manual care rulează scriptul pe producție vine într-o cerere separată, fiindcă orice schimbare de .gitlab-ci.yml anulează pipeline-ul pentru tot ce o însoțește.