Imatges WebP: reduir el pes sense perdre qualitat | Ighenatt

Les imatges són el recurs més pesat de la majoria de pàgines web. Segons HTTP Archive, representen el 50% del pes total d’una pàgina mitjana. Optimitzar-les correctament té un impacte directe en la velocitat de càrrega i, per tant, en el SEO i l’experiència d’usuari.

WebP és el format que millor equilibra compressió i qualitat el 2026, però usar-lo bé implica més que convertir arxius: requereix implementar srcset, sizes i una estratègia de lazy loading coherent.

Per què les imatges són la causa número 1 dels webs lents

Quan una pàgina carrega, el navegador descarrega HTML, CSS, JavaScript i imatges. De tots aquests recursos, les imatges solen representar el major volum de bytes transferits. Una foto hero sense optimitzar pot pesar 2-5MB, més que tot el codi HTML, CSS i JS combinat.

L’impacte en els Core Web Vitals és directe:

• LCP (Largest Contentful Paint): la imatge principal de la pàgina sol ser l’element LCP. Si pesa massa, el LCP es degrada proporcionalment al temps de descàrrega.
• CLS (Cumulative Layout Shift): les imatges sense dimensions definides (width i height) causen salts de disseny quan acaben de carregar.
• Temps total de càrrega: cada imatge no optimitzada consumeix amplada de banda que podria usar-se per a altres recursos crítics.

Google ha identificat les imatges no optimitzades com una de les oportunitats de millora més freqüents a Lighthouse. El motiu és senzill: la majoria de llocs serveixen imatges en format JPEG o PNG amb resolucions superiors a les que el dispositiu necessita.

WebP vs JPEG vs PNG vs AVIF: quan usar cada format

Cada format té un cas d’ús òptim:

JPEG continua sent vàlid per a fotografies on la compatibilitat universal és prioritària. La seva compressió amb pèrdua produeix artefactes visibles a nivells alts de compressió, però a qualitat 75-85 ofereix resultats acceptables.

PNG és necessari quan la imatge requereix transparència o conté text, línies fines o gràfics vectorials rasteritzats. La seva compressió sense pèrdua genera arxius més pesants que JPEG per a fotografies.

WebP supera tots dos en la majoria d’escenaris. Segons l’estudi de compressió de Google, WebP redueix la mida un 25-34% respecte a JPEG i un 26% respecte a PNG amb qualitat visual equivalent. Suporta tant compressió amb pèrdua com sense pèrdua, transparència i animacions. El 2026, el 97% dels navegadors el suporten.

AVIF ofereix una compressió superior a WebP (fins a un 50% menys que JPEG), però amb limitacions: el suport de navegadors és del 89%, la codificació és més lenta i alguns CDN no el serveixen correctament. És l’opció ideal com a format principal quan s’usa amb fallback a WebP.

L’estratègia recomanada és servir AVIF com a primera opció, WebP com a fallback i JPEG com a últim recurs, usant l’element <picture> d’HTML.

Com convertir imatges a WebP: eines i automatització

Conversió manual

Squoosh (squoosh.app) és l’eina de Google per a conversió individual. Permet comparar visualment la imatge original amb la comprimida, ajustar la qualitat i veure l’estalvi de pes en temps real. Funciona al navegador sense instal·lar res.

cwebp és l’eina de línia d’ordres oficial de Google. Permet automatitzar la conversió amb scripts bash per processar directoris complets.

Automatització en el build

Els frameworks moderns automatitzen la conversió durant el build:

• Astro usa Sharp per generar WebP i AVIF automàticament amb el component <Image>. Configura qualitats per format i genera les variants en temps de build.
• Next.js converteix imatges a WebP a demanda amb el seu component next/image.
• CDN com Cloudflare poden convertir imatges a WebP automàticament segons la capçalera Accept del navegador, sense canvis al codi.

L’automatització és preferible a la conversió manual perquè garanteix que totes les imatges noves s’optimitzen sense dependre que l’equip se’n recordi.

Atributs src, srcset i sizes: implementació correcta per al SEO

L’atribut srcset permet al navegador triar la imatge més adequada segons l’amplada de la pantalla i la densitat de píxels. Sense srcset, tots els dispositius descarreguen la mateixa imatge, cosa que significa que un mòbil amb pantalla de 375px descarrega la mateixa imatge de 1920px que un monitor d’escriptori.

La implementació correcta combina srcset amb sizes:

• srcset defineix les versions disponibles i la seva amplada real en píxels.
• sizes indica al navegador quina amplada ocuparà la imatge en el disseny, per tal que pugui triar la versió adequada abans de descarregar-la.

És important incloure sempre els atributs width i height a les imatges perquè el navegador pugui reservar l’espai correcte abans de carregar-les. Això prevé el CLS (Cumulative Layout Shift), una de les causes més comunes de problemes de LCP.

L’atribut alt descriptiu és obligatori per a l’accessibilitat i el SEO. Google l’utilitza per indexar imatges a Google Imatges i per entendre el context de la pàgina. Un alt genèric com “imatge” és gairebé tan dolent com no posar-ne cap.

Lazy loading d’imatges: quan sí i quan no usar-lo

L’atribut loading="lazy" indica al navegador que pospossi la descàrrega de la imatge fins que estigui a prop del viewport. Això redueix el pes inicial de la pàgina i millora el temps de càrrega percebut.

Quan usar lazy loading

• Imatges per sota del fold (les que l’usuari no veu sense fer scroll).
• Galeries d’imatges.
• Imatges en llistats d’articles o productes.
• Thumbnails i avatars.

Quan NO usar lazy loading

• La imatge LCP: aplicar lazy loading a la imatge hero o principal de la pàgina retarda la seva càrrega i empitjora el LCP. Aquesta imatge s’ha de carregar el més aviat possible.
• Imatges above the fold: qualsevol imatge visible sense fer scroll s’ha de carregar immediatament.

Per a la imatge LCP, la combinació correcta és:

• loading="eager" (o simplement no posar loading="lazy")
• fetchpriority="high" per indicar al navegador que és un recurs prioritari
• Un <link rel="preload"> a l’encapçalament per iniciar la descàrrega el més aviat possible

La diferència entre aplicar lazy loading i preload a la imatge LCP pot ser d’1-3 segons en connexions lentes.

Preguntes freqüents sobre optimització d’imatges

Tots els navegadors suporten WebP?

El 2026, el suport de WebP arriba al 97% dels navegadors, incloent-hi Chrome, Firefox, Safari (des de la versió 14), Edge i Opera. Els navegadors sense suport són versions antigues que representen menys del 3% del trànsit global. Per a aquest percentatge residual, l’element <picture> amb fallback a JPEG cobreix tots els casos.

Cal l’atribut alt en totes les imatges?

Sí. L’atribut alt és obligatori per a l’accessibilitat i el SEO. Google l’utilitza per entendre el contingut de la imatge i pot mostrar-lo als resultats de Google Imatges. Les imatges purament decoratives han de tenir alt="" (buit), però mai ometre l’atribut completament.

Com afecten les imatges al LCP?

La imatge hero o la imatge principal de la pàgina sol ser l’element que defineix el LCP. Si aquesta imatge és pesant, no està optimitzada o té lazy loading aplicat, el LCP es degradarà. La solució passa per usar WebP o AVIF, aplicar preload amb fetchpriority="high" i no usar lazy loading en la imatge LCP.

Optimitzar les imatges és una de les millores amb millor relació esforç-impacte en el rendiment web. Si vols que analitzem la velocitat del teu lloc i implementem una estratègia d’optimització d’imatges adaptada a la teva tecnologia, parla amb el nostre equip.