Chunk-urile rutei și poza paginii de produs, anunțate în cap

Ține de #10 (closed), nu îl închide: issue-ul se închide când cifrele de pe producție confirmă, nu când codul e scris.

Măsurat azi pe producție cu Lighthouse 13.4.1, mobil, mediana a 3 rulări: LCP 4,44 s pe prima pagină, 3,55 s pe colecție, 4,22 s pe pagina de produs, față de pragul de 2,5 s. CLS și TBT trec peste tot. Acest MR atacă două dintre cauze.

Chunk-urile rutei, numite în cap. Fiecare rută e leneșă, deci chunk-urile din care e construită o pagină nu se pot afla până nu se descarcă și se execută pachetul de intrare. Măsurat pe pagina de produs: pachetul de intrare s-a terminat la 279 ms, chunk-urile rutei au pornit abia la ~300 ms și s-au terminat la 496 ms, iar nimic nu se putea desena până atunci. Adresa spune deja ce rută e, deci rendererul le numește în cap și cele două valuri se descarcă odată. Build-ul emite route-chunks.json pentru că numele fișierelor au amprentă — exact tiparul care există deja pentru chunk-urile de limbă.

Poza pe care o desenează pagina de produs, anunțată. Descompunerea LCP arăta 657 ms de resourceLoadDelay: timp pierdut doar ca browserul să afle ce poză să ceară. Fișierul are 10 KB — nu e o problemă de mărime, ci exclusiv de descoperire.

Două capcane evitate, amândouă verificate în cod:

• meta.image din renderer este cardul de partajare, nu poza paginii. Un preload pe el ar fi descărcat degeaba un fișier și tot ar fi lăsat LCP-ul neanunțat.
• Galeria nu vine din data/productDetails.ts — acela e doar sursă de seed, importat numai ca tip. Vine din baza de date și se editează din panou, deci un manifest de build ar fi rămas în urmă la prima editare și ar fi anunțat o poză pe care pagina n-o randează. Rendererul o citește din DB, cu o singură interogare.
• Adresa anunțată oglindește webpSibling din Picture.tsx: browserul cere .webp, nu .png-ul din rând. Un test citește componenta și cade dacă regula se schimbă acolo.

Verificat. Backend: build curat, 521 de teste în 33 de fișiere. Frontend: tsc curat, build reușit, 215 teste în 27 de fișiere. Manifestul emis, citit efectiv din dist/: 11 / 9 / 8 chunk-uri, toate existente pe disc, zero duplicate față de ce numește deja index.html și zero suprapunere cu chunk-urile de limbă. Randarea unei pagini de produs cu galeria reală dă în cap exact /products/pdp/hypervolt-3-pro/1.webp, adică fișierul din raportul Lighthouse.

Ce rămâne după acest MR. LCP nu poate fi mai devreme decât prima vopsire, iar prima vopsire e la 2,7 s pentru că pagina nu desenează nimic până nu ajunge și pornește JavaScript-ul — corpul HTML servit are 871 de octeți. Măsurătoarea de după deploy va spune cât s-a câștigat; pragul de 2,5 s cere și ca zona de sus a paginii să se vopsească din HTML-ul servit, care e o lucrare separată.