Perché serve resize automatico
Caricare immagine 4000x3000px renderizzata in 400x300 e spreco di banda e CPU del browser. Serve workflow che produca varianti multiple ottimali per ogni viewport: 320w mobile, 768w tablet, 1200w desktop, 2400w retina. Il browser sceglie via srcset.
Sharp (Node.js)
Sharp e la libreria più performante per Node: usa libvips, gestisce JPEG, PNG, WebP, AVIF, GIF, SVG, TIFF. Sintassi semplice: sharp(input).resize(800).toFile('out.jpg'). Usata da Next.js Image, Gatsby, Nuxt, Eleventy per pipeline build-time. Velocissimo: convertire 1000 immagini in pochi secondi.
ImageMagick e GraphicsMagick
Standard CLI: convert input.jpg -resize 800x output.jpg. Configurabilissimo con centinaia di opzioni. Usato in molti workflow Linux server. Mogrify per batch in-place. GraphicsMagick e fork più veloce per certi operatori. Supporto formato esteso ma performance inferiori a libvips/Sharp.
WordPress: plugin automatici
WordPress genera nativamente sizes thumbnail, medium, large. Plugin estendono: ShortPixel, Imagify, Smush ottimizzano e creano WebP/AVIF varianti. EWWW Image Optimizer per ottimizzazione lossless aggressive. Adaptive Images per servire varianti basate su user-agent/screen.
Build-time vs Runtime
Build-time (Sharp, ImageMagick, ImageOptim): varianti pre-generate, salvate, servite statiche. Pro: prestazioni server eccellenti. Contro: storage più grande, nuova immagine richiede ri-build. Runtime (Image CDN, imgproxy, Thumbor): varianti generate on-demand, cached. Pro: flessibile, sempre fresco. Contro: latenza primo hit, dipendenza servizio.
Workflow consigliato
1. Upload immagine originale ad alta risoluzione (4000px+). 2. Pipeline build genera 5-6 varianti responsive. 3. Conversione automatica WebP + AVIF. 4. Compressione lossy q=80 per JPEG, q=75 WebP. 5. Output con picture/srcset per fallback. 6. CDN per delivery. 7. Lazy loading nativo per below-fold.
Hai bisogno di aiuto?
Se vuoi un sito veloce ottimizzato dal team di G Tech Group, scrivici tramite il modulo di contatto.