Què és el lazy loading i com funciona al navegador
El lazy loading és l’optimització que pot sortir cara si s’aplica malament. La tècnica consisteix a diferir la càrrega de recursos no visibles fins que l’usuari es desplaça cap a ells, reduint el pes inicial de la pàgina i accelerant el temps de renderitzat. En teoria, és una de les optimitzacions de rendiment web més eficaces. A la pràctica, és també una de les que més freqüentment s’implementa de manera incorrecta, amb conseqüències directes sobre el Largest Contentful Paint i, per extensió, sobre el posicionament a Google.
El principi és simple: si una imatge, un iframe o un vídeo està fora del viewport inicial de l’usuari, no té sentit descarregar-lo fins que l’usuari s’acosti a aquella zona de la pàgina. Un article amb 15 imatges on només 2 són visibles sense scroll carrega 13 imatges innecessàriament si no implementa lazy loading. Depenent del pes d’aquestes imatges, això pot afegir entre 2 i 10 MB de transferència de dades que l’usuari no necessita en el primer segon de càrrega.
El mecanisme natiu del navegador, activat mitjançant l’atribut loading="lazy" als elements <img> i <iframe>, funciona de la manera següent: el navegador detecta la posició de l’element respecte al viewport i decideix automàticament quan iniciar la descàrrega. Chrome, per exemple, utilitza un llindar dinàmic que varia segons el tipus de connexió de l’usuari: en connexions 4G, comença a carregar imatges quan són a uns 1.250 píxels del viewport; en connexions lentes, a uns 2.500 píxels. Aquest comportament intel·ligent garanteix que la imatge estigui carregada abans que l’usuari arribi a veure-la, eliminant la percepció d’espai en blanc.
Abans de la implementació nativa, el lazy loading requeria biblioteques JavaScript com lazysizes, lozad.js o polyfills d’IntersectionObserver. Aquestes solucions funcionaven però afegien JavaScript addicional a la pàgina, creant una ironia: una tècnica dissenyada per reduir la càrrega acabava afegint pes de JavaScript per funcionar. Amb l’atribut natiu loading="lazy", suportat pel 96% dels navegadors globals segons Can I Use, la necessitat d’aquestes biblioteques ha desaparegut per a la majoria de casos d’ús.
La relació entre lazy loading i SEO és directa. Google utilitza el Largest Contentful Paint com una de les tres mètriques Core Web Vitals que afecten el rànquing. El LCP mesura quant tarda a carregar-se l’element visual més gran del viewport inicial. Si aquest element és una imatge amb lazy loading, el navegador retarda la seva càrrega perquè primer necessita renderitzar el layout de la pàgina per determinar si la imatge és al viewport, i només llavors inicia la descàrrega. Aquest retard addicional pot sumar entre 1 i 3 segons al LCP, una penalització devastadora en termes de rendiment i posicionament.
Per a una visió completa de com la velocitat web afecta el SEO i el negoci, consulta la nostra guia sobre velocitat web i SEO.
Lazy loading natiu amb loading=“lazy”: avantatges i limitacions
L’atribut HTML loading="lazy" va representar un canvi fonamental en l’optimització d’imatges web quan Chrome el va implementar a la versió 76 el 2019. Per primera vegada, els desenvolupadors podien diferir la càrrega d’imatges sense dependències de JavaScript, sense configuració complexa i sense risc de trencar la indexació a Google.
La implementació és deliberadament simple: <img src="foto.jpg" loading="lazy" alt="Descripció" width="800" height="600">. Els atributs width i height són essencials en aquest context, no opcionals. Sense dimensions explícites, el navegador no pot calcular la posició de l’element respecte al viewport sense primer descarregar-lo, cosa que anul·la parcialment el benefici del lazy loading i pot causar CLS (desplaçaments de layout) quan la imatge finalment carrega i empeny el contingut circumdant.
Els avantatges de l’atribut natiu són significatius. Primer: zero JavaScript. El navegador gestiona tot el procés de detecció de viewport i càrrega, cosa que significa que no hi ha impacte en el pes de JavaScript del bundle ni en el temps de parseig. Segon: compatibilitat amb Googlebot. La documentació oficial de Google confirma que l’atribut loading="lazy" funciona correctament amb el seu rastrejador, que renderitza les pàgines com un navegador Chrome complet. Tercer: degradació elegant. Els navegadors que no suporten l’atribut simplement l’ignoren i carreguen la imatge de forma normal, sense trencar res.
Tanmateix, el lazy loading natiu té limitacions que convé conèixer. La principal és que el desenvolupador no té control sobre el llindar de càrrega: Chrome decideix quan iniciar la descàrrega basant-se en els seus propis algorismes. Això significa que en alguns casos, el navegador pot ser massa conservador (carregant imatges massa aviat, reduint el benefici) o massa agressiu (carregant massa tard, mostrant breument un espai en blanc). A la pràctica, els llindars de Chrome estan ben calibrats per a la majoria de situacions, però existeixen escenaris on un control més fi és necessari.
Una altra limitació és l’absència d’efectes de transició. Amb loading="lazy" natiu, la imatge apareix abruptament quan carrega. No hi ha fade-in, blur-up ni cap efecte visual que suavitzi l’aparició. Per a llocs web on l’experiència visual és prioritària — portfolis de fotografia, e-commerce de moda, webs de disseny — aquesta limitació pot justificar l’ús de solucions JavaScript complementàries.
El patró correcte d’ús en una pàgina típica és el següent: les imatges above the fold (hero, logotip, primeres seccions) utilitzen loading="eager" (el valor per defecte, que pot ometre’s) i la imatge LCP rep a més fetchpriority="high" per indicar al navegador que la prioritzi sobre altres recursos. Totes les imatges sota el fold utilitzen loading="lazy". Aquesta combinació maximitza la velocitat de la primera impressió visual sense penalitzar el LCP.
Intersection Observer API: lazy loading avançat amb JavaScript
La Intersection Observer API és el mecanisme JavaScript modern per implementar lazy loading amb control granular. A diferència de l’atribut natiu, que delega tota la lògica al navegador, Intersection Observer permet al desenvolupador definir exactament quan, com i sota quines condicions es carreguen els recursos diferits.
El funcionament d’Intersection Observer és elegant: es crea un observador que monitoritza si un element entra al viewport (o en una àrea definida al voltant del viewport), i executa un callback quan això passa. El navegador optimitza internament aquesta detecció, agrupant els càlculs d’intersecció i executant-los de manera asíncrona, cosa que el fa significativament més eficient que les solucions antigues basades en scroll listeners.
Un patró típic d’implementació comença amb la creació de l’observador configurant un rootMargin de 200px 0px (això carrega les imatges quan són a 200 píxels del viewport, no quan ja són visibles) i un threshold de 0.01 (s’activa quan amb prou feines un 1% de l’element és visible). El callback rep les entrades que estan intersectant, reemplaça l’atribut data-src per src per iniciar la càrrega, i deixa d’observar l’element un cop carregat.
L’avantatge principal d’Intersection Observer sobre el lazy loading natiu és el control del rootMargin. En connexions lentes, un rootMargin de 300-500 píxels dona més temps al navegador per descarregar la imatge abans que sigui visible. En connexions ràpides, un rootMargin de 100-200 píxels redueix les descàrregues innecessàries. Aquesta adaptació al context de xarxa és una cosa que l’atribut natiu fa internament, però que el desenvolupador no pot configurar.
Un altre cas d’ús on Intersection Observer supera el natiu és el lazy loading de contingut que no són imatges: components React que només es renderitzen quan són visibles, seccions d’una single-page application que carreguen dades sota demanda, o mòduls d’analytics que s’inicialitzen només quan l’usuari arriba a determinada secció de la pàgina. L’atribut loading="lazy" només funciona amb <img> i <iframe>, mentre que Intersection Observer funciona amb qualsevol element del DOM.
Des de la perspectiva de SEO, Intersection Observer requereix una precaució addicional que el lazy loading natiu no necessita. Googlebot executa JavaScript, però el seu procés de renderitzat té particularitats: renderitza la pàgina en una sola passada, sense simular scroll. Això significa que si la teva implementació d’Intersection Observer depèn d’un scroll real per activar-se, Googlebot pot no veure les imatges. La solució és usar l’atribut src amb una imatge placeholder de baixa resolució i data-src amb la imatge real, assegurant que Googlebot almenys té accés al placeholder. Alternativament, incloure una etiqueta <noscript> amb la imatge original com a fallback garanteix la indexació fins i tot si el JavaScript falla.
La recomanació pràctica per a la majoria de llocs web el 2026 és clara: usar loading="lazy" natiu com a solució per defecte i reservar Intersection Observer només per a casos que requereixin control avançat sobre el comportament de càrrega. La simplicitat i fiabilitat de l’atribut natiu superen els avantatges del control manual en el 90% dels escenaris.
L’error més greu: lazy loading a l’element LCP
Si hi ha un sol concepte a retenir d’aquesta guia, és aquest: mai, sota cap circumstància, apliquis lazy loading a la imatge que constitueix el Largest Contentful Paint de la teva pàgina. Aquest error, documentat per Google com un dels més freqüents en auditories de Core Web Vitals, penalitza directament el teu LCP i, per extensió, el teu posicionament orgànic.
El mecanisme pel qual el lazy loading danya el LCP és tècnic però comprensible. Quan el navegador troba una imatge amb loading="lazy", segueix aquest procés: primer parseja l’HTML, construeix el DOM i el CSSOM, calcula el layout de la pàgina, determina quins elements són al viewport, i només llavors inicia la descàrrega de les imatges marcades com a lazy que resulten estar visibles. Aquest procés afegeix un retard que no existeix amb una imatge de càrrega normal (loading="eager"), on el navegador comença a descarregar la imatge tan bon punt troba l’etiqueta a l’HTML, en paral·lel amb la resta del parseig.
Les dades del Chrome User Experience Report mostren que aplicar lazy loading a l’element LCP augmenta el temps de LCP entre 1.200 i 3.000 mil·lisegons de mitjana, depenent de la velocitat de connexió. En una pàgina amb un LCP d’1,8 segons (dins del llindar “bo” de Google), afegir lazy loading pot portar-lo a 3-4,8 segons, creuant directament al llindar “pobre” que Google penalitza al rànquing.
El problema és especialment insidiós perquè molts CMS i frameworks apliquen lazy loading de forma automàtica a totes les imatges. WordPress, des de la versió 5.5, afegeix loading="lazy" a totes les etiquetes <img> per defecte. Alguns temes i plugins sobreescriuen aquesta lògica per excloure la imatge de la capçalera, però molts no ho fan. El resultat: milions de webs WordPress tenen la seva imatge LCP amb lazy loading sense que el propietari ho sàpiga.
L’auditoria d’aquest problema és directa. PageSpeed Insights assenyala explícitament quan detecta lazy loading a l’element LCP amb el missatge “Don’t lazy-load Largest Contentful Paint image.” Lighthouse Core Web Vitals també ho marca. Però la forma més fiable de detectar-ho és inspeccionar el codi font de la pàgina i verificar que la imatge hero o la imatge principal visible sense scroll no tingui l’atribut loading="lazy".
El patró correcte per a la imatge LCP inclou tres elements: loading="eager" (o simplement ometre l’atribut loading, que té el mateix efecte), fetchpriority="high" per indicar al navegador que la prioritzi sobre altres recursos, i un preload al <head> del document: <link rel="preload" as="image" href="imatge-hero.webp" fetchpriority="high">. Aquesta combinació garanteix que el navegador comenci a descarregar la imatge LCP el més aviat possible, abans fins i tot d’haver construït el layout complet de la pàgina.
Els Core Web Vitals depenen directament de decisions com aquesta. Un LCP optimitzat no és només una mètrica tècnica: és un factor de rànquing directe que afecta la visibilitat orgànica de la teva pàgina.
Lazy loading d’iframes, vídeos i contingut embegut
L’impacte del lazy loading en iframes és proporcionalment major que en imatges, perquè un iframe de YouTube, Google Maps o un widget social carrega tot el seu propi HTML, CSS, JavaScript i recursos associats. Un sol iframe de YouTube sense lazy loading pot afegir entre 500 KB i 1,5 MB de transferència i diverses connexions HTTP addicionals, tot per un element que pot no ser visible sense scroll.
L’atribut loading="lazy" funciona nativament amb <iframe> als mateixos navegadors que el suporten per a <img>. La implementació és idèntica: <iframe src="https://www.youtube.com/embed/ID" loading="lazy"></iframe>. Tanmateix, hi ha una diferència important: mentre que una imatge amb lazy loading simplement no es descarrega fins que és necessària, un iframe amb lazy loading no descarrega res del domini embegut fins que l’iframe entra al viewport. Això significa que si l’iframe conté JavaScript que registra esdeveniments o estableix cookies, aquestes accions es difereixen també.
Per a vídeos embeguts, la millor pràctica el 2026 combina lazy loading amb la tècnica de “façana”: en lloc de carregar l’iframe de YouTube directament, es mostra una imatge thumbnail del vídeo amb un botó de play. Només quan l’usuari fa clic al play es reemplaça la imatge per l’iframe real de YouTube. Aquesta tècnica, recomanada per web.dev a la seva guia de rendiment, elimina completament la càrrega de l’iframe per als usuaris que mai interactuen amb el vídeo (que, segons estudis de Wistia, són entre el 60% i el 80% dels visitants d’una pàgina amb vídeo embegut).
Els widgets de tercers — chatbots, formularis de subscripció, calendaris de reserva, reproductors de podcast — representen un cas especial. Molts d’aquests widgets es carreguen mitjançant scripts que injecten iframes dinàmicament, i l’atribut loading="lazy" no funciona amb iframes creats per JavaScript. Per a aquests casos, la solució és usar Intersection Observer per detectar quan el contenidor del widget és a prop del viewport i només llavors injectar l’script del widget.
Google Maps és l’exemple més clar del benefici del lazy loading d’iframes. Un embed de Google Maps sense lazy loading inicia entre 15 i 25 connexions HTTP i descarrega aproximadament 800 KB de dades. En una pàgina de contacte on el mapa és sota un formulari i un bloc de text, la majoria d’usuaris veuen el mapa només després de fer scroll. Aplicar loading="lazy" a l’iframe del mapa elimina aquella càrrega inicial de 800 KB, millorant significativament el temps total de càrrega de la pàgina.
Des de la perspectiva de SEO, els iframes amb lazy loading no afecten negativament la indexació del contingut de la pàgina principal. Google no indexa el contingut dins d’iframes com a part de la pàgina contenidora, de manera que diferir la seva càrrega no té impacte en quin contingut veu Googlebot. El que sí millora és la puntuació de rendiment de la pàgina, cosa que indirectament beneficia el posicionament.
Com verificar que el teu lazy loading funciona correctament
Implementar lazy loading és només la meitat de la feina. Verificar que funciona correctament — i que no està causant problemes no desitjats — és l’altra meitat, i la que la majoria de desenvolupadors omet.
La primera verificació és visual: obre la teva pàgina a Chrome DevTools amb la pestanya Network oberta, filtra per “Img”, i fes scroll lentament cap avall. Hauries de veure les peticions d’imatge aparèixer progressivament a mesura que t’acostes a cada imatge, no totes de cop en carregar la pàgina. Si totes les imatges es carreguen de seguida, el lazy loading no està funcionant. Si cap imatge es carrega fins que literalment la veus, el llindar és massa agressiu i els usuaris veuran espais en blanc.
La segona verificació és tècnica: assegura’t que la imatge LCP no té loading="lazy". A DevTools, inspecciona l’element LCP (pots identificar-lo amb Lighthouse, que el marca específicament) i confirma que no té l’atribut loading o que té loading="eager". Si uses un CMS que afegeix lazy loading automàticament, verifica que la primera imatge de cada plantilla de pàgina estigui exclosa de la lògica automàtica.
La tercera verificació és d’indexació. A Google Search Console, usa l’eina d’inspecció d’URLs per renderitzar una pàgina amb lazy loading i verifica que les imatges apareixen a l’HTML renderitzat. També pots usar el test de resultats enriquits de Google per veure com Googlebot veu la teva pàgina. Si les imatges no apareixen a la vista renderitzada, la teva implementació de lazy loading amb JavaScript té un problema que l’atribut natiu no tindria.
La quarta verificació és de rendiment. Executa Lighthouse a les principals plantilles de pàgina (inici, llistat, detall) i revisa les auditories específiques de lazy loading: “Defer offscreen images” (hauria d’estar en verd si el lazy loading funciona) i “Don’t lazy-load LCP image” (no hauria d’aparèixer). WebPageTest ofereix una anàlisi més detallada amb la seva vista de “filmstrip” que mostra fotograma a fotograma com carrega la pàgina, permetent detectar si hi ha imatges que haurien de ser visibles però apareixen amb retard.
Per a llocs web amb múltiples plantilles (e-commerce amb pàgines de producte, categoria, inici, blog), la verificació s’ha de repetir a cada tipus de plantilla, perquè la imatge LCP varia entre elles. A la pàgina d’inici pot ser el banner hero; a una pàgina de producte, la primera foto del producte; a un article de blog, la imatge destacada. Cadascuna d’aquestes imatges ha d’estar exclosa del lazy loading.
Una pràctica recomanada és automatitzar aquestes verificacions amb eines com pa11y o unlighthouse, que permeten auditar centenars d’URLs en batch i generar informes de rendiment que inclouen les mètriques de lazy loading. Integrar aquestes auditories al pipeline de CI/CD garanteix que futures actualitzacions del lloc no reintrodueixin accidentalment lazy loading a l’element LCP.
La diferència entre lazy loading implementat correctament i lazy loading implementat per defecte pot ser la diferència entre un LCP d’1,5 segons i un LCP de 4 segons. En un mercat on Google utilitza els Core Web Vitals com a factor de rànquing, aquesta diferència té impacte directe en la visibilitat orgànica i, en darrera instància, en els ingressos del negoci.