Per què les imatges són la causa número 1 de webs lentes
Les imatges representen el 50% del pes mitjà d’una pàgina web. Aquesta dada, publicada per HTTP Archive al seu informe State of the Web de 2025, no és una estadística abstracta: és la raó per la qual milions de llocs web carreguen més lentament del necessari i perden posicions a Google cada dia.
Per posar-ho en context, la pàgina mediana d’escriptori pesa 2,3 MB, dels quals 1,15 MB corresponen a imatges. A mòbil, on el 73% del tràfic web global es concentra segons Statista, aquests 1,15 MB es descarreguen a través de connexions 4G amb latències de 50-100 ms per recurs. El resultat és previsible: les imatges són el factor que més retarda el LCP a la majoria dels llocs web.
La relació entre imatges i velocitat web i SEO és directa i quantificable. Segons l’estudi de Google i Deloitte “Milliseconds Make Millions”, una millora de 0,1 segons en la velocitat de càrrega pot incrementar les conversions un 8,4% en retail. A la majoria dels llocs que auditem, l’optimització d’imatges és la intervenció amb la millor ràtio entre impacte i esforç.
El problema no és que les empreses ignorin la importància de les imatges. El problema és que l’optimització d’imatges té múltiples dimensions —format, compressió, dimensions, atributs HTML, estratègia de càrrega— i fallar en qualsevol d’elles dilueix el benefici de les altres. Una imatge WebP perfectament comprimida que es serveix sense atributs srcset malbarata amplada de banda a mòbil. Una imatge amb srcset impecable però sense lazy loading obliga el navegador a descarregar recursos que l’usuari potser mai veurà. Aquesta guia aborda cada dimensió amb dades verificables i recomanacions concretes.
Segons Cloudflare, els llocs que implementen una estratègia completa d’optimització d’imatges —format modern, compressió adaptativa, responsive images i lazy loading— redueixen el pes total de la pàgina entre un 40% i un 60%, amb millores de LCP d’entre 1 i 3 segons en connexions mòbils.
WebP vs JPEG vs PNG vs AVIF: quan usar cada format
L’elecció del format d’imatge no és una decisió trivial. Cada format té un perfil de compressió, qualitat i compatibilitat diferent, i triar malament pot significar servir imatges un 40% més pesades del necessari sense cap guany visual.
WebP és el format que ofereix el millor equilibri entre compressió i compatibilitat el 2026. Desenvolupat per Google el 2010 i basat en el còdec VP8 del format de vídeo WebM, WebP ofereix compressió amb pèrdua un 25-34% superior a JPEG a qualitat visual equivalent, segons les proves de Google. En compressió sense pèrdua, WebP és un 26% més petit que PNG. Suporta transparència (canal alfa), animacions i perfils de color. La seva compatibilitat en navegadors arriba al 97% global, incloent Safari des de la versió 14 publicada el 2020.
JPEG continua sent rellevant com a format de fallback i en entorns on la generació de WebP no és viable. La seva compressió amb pèrdua és eficient per a fotografies, però no suporta transparència i el seu algorisme de compressió no ha evolucionat significativament en dues dècades. MozJPEG, una implementació optimitzada de JPEG desenvolupada per Mozilla, millora la compressió un 5-10% respecte al codificador estàndard, però queda per darrere de WebP.
PNG és el format correcte per a imatges que requereixen transparència sense pèrdua de qualitat: logotips, icones i gràfics amb text. No s’ha d’usar per a fotografies: un PNG de 1920x1080 pot pesar 5-10 MB on l’equivalent en WebP pesaria 200-400 KB. És un error freqüent en CMS com WordPress on el sistema de pujada no converteix automàticament a WebP.
AVIF és el format de nova generació, basat en el còdec AV1. Ofereix compressió un 20% superior a WebP i un 50% superior a JPEG en proves de Netflix. Tanmateix, la seva compatibilitat en navegadors és del 92% el 2026 —inferior a WebP— i el seu temps de codificació és significativament major. Per a llocs amb pipelines de build automatitzats, AVIF és una opció excel·lent com a format primari amb fallback a WebP. Per a llocs que generen imatges dinàmicament, el cost computacional de la codificació AVIF pot ser prohibitiu.
La recomanació pràctica per a la majoria dels llocs web el 2026 és clara: WebP com a format principal, amb AVIF com a format prioritari on el pipeline de build ho permeti, i JPEG com a fallback universal mitjançant l’element <picture>.
Com convertir imatges a WebP: eines i automatització
La conversió manual d’imatges a WebP no escala. Un e-commerce amb 5.000 productes necessita un pipeline automatitzat que converteixi cada imatge pujada al CMS, la comprimeixi amb els paràmetres correctes i generi les variants de mida necessàries per a srcset. Sense automatització, el deute tècnic d’imatges s’acumula fins a convertir-se en un problema de rendiment crònic.
Per a la conversió individual, Squoosh (squoosh.app) és l’eina de referència per a experimentació amb paràmetres de compressió. Desenvolupada per l’equip de Chrome de Google, permet comparar visualment la qualitat entre formats i nivells de compressió. Per a WebP, un nivell de qualitat de 75-80 ofereix el millor equilibri entre mida i fidelitat visual per a fotografies. Per a icones i gràfics, WebP lossless és preferible.
Per a la conversió per línia de comandes, cwebp és l’eina oficial de Google. La comanda cwebp -q 75 -m 6 input.jpg -o output.webp produeix resultats consistents per a fotografies. El paràmetre -m 6 activa el nivell màxim de compressió, que és més lent però produeix fitxers un 5-8% més petits. Sharp, la biblioteca de Node.js utilitzada per Astro i Next.js, ofereix una API programàtica equivalent amb suport natiu per a WebP i AVIF.
Pel que fa a l’automatització en CMS, WordPress disposa de plugins com ShortPixel, Imagify i WebP Express que converteixen automàticament les imatges pujades a la biblioteca de mitjans. Per a Shopify, les apps d’optimització d’imatges apliquen conversió WebP a nivell de CDN. A Astro, el component <Image> aplica conversió WebP automàtica durant el build amb qualitat configurable a astro.config.mjs.
L’automatització a nivell de CDN (Cloudflare, Fastly, AWS CloudFront) converteix WebP a l’edge detectant la capçalera Accept del navegador, sense modificar els fitxers originals al servidor. Aquesta aproximació és la més eficient per a llocs que no controlen directament el pipeline de build, com marketplaces o plataformes SaaS.
Un aspecte freqüentment ignorat és la necessitat d’establir un pressupost d’imatge per pàgina. HTTP Archive documenta que la pàgina mediana serveix 30-40 imatges. Si cada imatge pesa 50 KB després de la compressió WebP, el pes total d’imatges és d’1,5-2 MB. Per a pàgines amb objectius de LCP agressius —per sota de 2 segons en 4G—, el pressupost realista és de 200-400 KB per a les imatges above the fold i la resta amb lazy loading.
Atributs src, srcset i sizes: implementació correcta per al SEO
Els atributs srcset i sizes existeixen per resoldre un problema concret: servir la imatge de la mida correcta per al viewport de l’usuari. Sense ells, un smartphone amb pantalla de 375px descarrega la mateixa imatge de 1920px que un monitor d’escriptori, malbaratant un 80% de l’amplada de banda.
L’atribut srcset declara una llista de versions de la mateixa imatge amb diferents amplades. El navegador selecciona automàticament la versió més eficient segons el viewport, la densitat de píxels del dispositiu i la velocitat de connexió. Un srcset típic inclou tres variants: 480w per a mòbil, 800w per a tauleta i 1200w per a escriptori.
L’atribut sizes indica al navegador l’amplada que ocuparà la imatge en el layout abans de descarregar-la. Això és crític perquè el navegador necessita decidir quina variant de srcset descarregar abans que el CSS s’hagi carregat i el layout s’hagi calculat. Sense sizes, el navegador assumeix que la imatge ocupa el 100% del viewport (100vw), cosa que produeix seleccions subòptimes en layouts amb columnes.
Un error comú que identifiquem en auditories és declarar srcset sense sizes. El resultat és que el navegador descarrega sempre la versió més gran per a pantalles d’alta densitat (Retina), anul·lant el benefici de responsive images. Un altre error freqüent és generar variants de srcset amb amplades arbitràries en lloc d’alinear-les amb els breakpoints reals del disseny.
La implementació correcta per a una imatge que ocupa el 100% de l’amplada a mòbil i el 50% a escriptori seria: sizes="(max-width: 768px) 100vw, 50vw". Amb aquesta declaració, un iPhone 14 (390px de viewport, 3x de densitat) seleccionarà la variant de 1200w, mentre que un monitor d’escriptori a 1440px seleccionarà la variant de 800w. Tots dos obtenen la imatge amb la resolució justa per al seu context, sense excés ni defecte.
Per a Google Images, la implementació correcta de srcset i sizes és un senyal de qualitat tècnica. Google pot indexar les diferents variants de la imatge i servir la més adequada als resultats de cerca visual. A més, les pàgines que implementen responsive images correctament tendeixen a tenir millor LCP, cosa que es reflecteix a les mètriques de Core Web Vitals reportades per Chrome UX Report.
Lazy loading d’imatges: quan sí i quan no usar-lo
El lazy loading és una tècnica que retarda la descàrrega d’imatges fins que estan a punt d’entrar al viewport de l’usuari. Correctament implementat, redueix el pes de la càrrega inicial de la pàgina entre un 30% i un 50% per a pàgines amb moltes imatges. Mal implementat, pot impedir que Googlebot vegi les imatges, perjudicant la indexació a Google Images i eliminant senyals de contingut rellevants.
L’API nativa del navegador per al lazy loading és l’atribut loading="lazy" a l’etiqueta <img>. Suportat pel 95% dels navegadors el 2026, no requereix JavaScript i és la implementació recomanada per Google Search Central. El navegador retarda la descàrrega fins que la imatge està aproximadament a 1.250 píxels del viewport en connexions ràpides, o 2.500 píxels en connexions lentes (4G i 3G).
La regla que no admet excepcions: les imatges above the fold (visibles sense scroll) mai han de tenir lazy loading. La imatge LCP —la més gran visible a la càrrega inicial— s’ha de carregar amb la màxima prioritat. Afegir-li loading="lazy" retarda el LCP i perjudica directament el Core Web Vital més visible. Per a la imatge LCP, la implementació correcta és combinar loading="eager" (o simplement no declarar loading) amb fetchpriority="high" i una etiqueta <link rel="preload"> al <head>.
Googlebot gestiona correctament loading="lazy" en imatges natives del navegador. Tanmateix, les implementacions basades en JavaScript que reemplacen el src amb un placeholder i el substitueixen en el scroll —el patró d’Intersection Observer— requereixen que Googlebot executi el JavaScript per veure la imatge real. Google Search Central documenta explícitament que Googlebot simula scroll per activar lazy loading, però aquesta simulació no és perfecta i pot fallar en implementacions no estàndard.
Les bones pràctiques per a lazy loading compatible amb SEO són: usar loading="lazy" natiu, no aplicar lazy loading a les primeres 3-5 imatges de la pàgina, assegurar que l’element <img> tingui src real des de l’HTML inicial (no substituït per JavaScript), i proporcionar dimensions explícites amb width i height per evitar layout shifts (CLS).
Un patró que observem freqüentment en e-commerces és aplicar lazy loading a totes les imatges de producte, incloent la imatge principal de la fitxa. Això retarda el LCP entre 800 ms i 2 segons, suficient per caure del llindar de “bo” de 2,5 segons al de “necessita millora”. Corregir aquest únic error —eliminar loading="lazy" de la imatge de producte principal— pot millorar el LCP de tota la secció de producte sense cap altre canvi tècnic.
Mètriques: com mesurar l’impacte de l’optimització d’imatges
Optimitzar imatges sense mesurar l’impacte és treballar a cegues. Les eines disponibles permeten quantificar l’abans i el després amb precisió, tant a nivell de pàgina individual com a nivell de lloc complet.
El PageSpeed Insights és el punt de partida. La seva auditoria “Properly size images” calcula quants KB s’estalviarien servint cada imatge a la mida correcta per al viewport. L’auditoria “Serve images in next-gen formats” identifica les imatges que es beneficiarien de la conversió a WebP o AVIF. Ambdues auditories inclouen una estimació de l’estalvi potencial en segons de càrrega, cosa que permet prioritzar les imatges amb major impacte.
La Chrome DevTools Network tab permet analitzar el pes real de les imatges descarregades en una visita concreta. Filtrant per tipus “Img”, s’obté el pes total d’imatges, el nombre de peticions i el temps de descàrrega de cadascuna. La columna “Size” mostra el pes transferit (comprimit amb gzip/brotli) versus el pes real, identificant imatges que no s’estan comprimint a nivell de servidor.
El Lighthouse CI automatitza l’auditoria d’imatges a cada deploy. Configurant llindars per a “Properly size images” i “Serve images in next-gen formats”, el pipeline de CI pot bloquejar deploys que introdueixin regressions de rendiment d’imatges. Per a equips amb múltiples desenvolupadors pujant contingut a un CMS, aquesta automatització és l’única forma escalable de mantenir la disciplina d’optimització.
L’HTTP Archive proporciona dades de benchmarking per comparar el teu lloc amb l’ecosistema web. El percentil 50 de pes d’imatges per pàgina és d’1,15 MB en escriptori i 900 KB en mòbil. Si el teu lloc està significativament per sobre d’aquests valors, hi ha marge de millora. Si està per sota, ets al quartil superior d’optimització.
El Google Search Console ofereix la perspectiva d’impacte SEO. L’informe de Core Web Vitals mostra el percentatge d’URLs amb LCP “bo”, “necessita millora” i “deficient” en dades de camp. Comparar aquest informe abans i després d’una optimització d’imatges quantifica l’impacte real en l’experiència dels usuaris de Chrome, que és la mètrica que Google usa per al rànquing.
La mètrica més directa per avaluar l’optimització d’imatges és la ràtio de bytes d’imatge respecte al pes total de la pàgina. Una ràtio superior al 50% indica que les imatges són el factor dominant de pes i que hi ha marge per millorar. Una ràtio del 20-30% és típica de llocs ben optimitzats. Per sota del 20%, l’optimització d’imatges té rendiments marginals i l’esforç s’hauria de concentrar en altres àrees com el CSS render-blocking o l’eliminació de JavaScript no utilitzat.
Per a llocs empresarials amb milers de pàgines, l’eina més eficient és Screaming Frog amb l’extracció personalitzada d’atributs d’imatge. Permet auditar massivament quines imatges no tenen alt, quines no tenen width i height explícits, quines usen formats obsolets i quines tenen loading="lazy" en posició above the fold. Aquesta auditoria massiva, creuada amb les dades de Core Web Vitals de Search Console, permet prioritzar les pàgines on l’optimització d’imatges tindrà major impacte en el rànquing orgànic.