Velocitat de Càrrega i SEO: Guia Completa per al Teu Web

Un e-commerce de Barcelona que perdia 40.000 euros al mes per 2 segons

Un e-commerce de moda a Barcelona facturava 180.000 euros mensuals a través de trànsit orgànic. El setembre de 2025, després d’una migració de tema a Shopify, el temps de càrrega mitjà va passar d’1,8 a 3,9 segons. En sis setmanes, el trànsit orgànic va caure un 23% i les vendes en línia es van reduir en 42.000 euros mensuals. El diagnòstic va ser clar: el nou tema carregava tres biblioteques JavaScript d’animació que blocaven el renderitzat i les imatges de producte havien perdut la compressió WebP durant la migració.

Aquest cas no és excepcional. És representatiu d’un patró que es repeteix en empreses de totes les mides. La velocitat de càrrega no és una mètrica tècnica abstracta: és un multiplicador directe d’ingressos. Segons l’estudi de Google i Deloitte “Milliseconds Make Millions”, una millora de tan sols 0,1 segons en la velocitat de càrrega pot incrementar les conversions un 8,4% en retail i un 10,1% en viatges. L’estudi va analitzar dades reals de 37 marques durant un període de 30 dies, amb un nivell de confiança del 90%.

Aquesta guia desglossa la relació entre velocitat web i SEO amb dades verificables, identifica les causes més freqüents de webs lents, revisa les eines de mesurament disponibles i proposa un full de ruta concret per millorar el rendiment. L’objectiu no és perseguir una puntuació a PageSpeed Insights, sinó entendre quines palanques tècniques tenen impacte real en el posicionament i en el negoci.

Les 5 causes més freqüents d’un web lent

Abans de mesurar o intentar optimitzar, cal entendre què frena la velocitat de la majoria dels llocs web. Segons les dades de l’HTTP Archive, que analitza més de 8 milions de llocs web mensualment, les causes es repeteixen amb una consistència notable independentment del sector o la mida de l’empresa.

Imatges sense optimitzar

Les imatges representen de mitjana el 42% del pes total d’una pàgina web, segons HTTP Archive. Servir imatges en format JPEG o PNG quan podrien utilitzar WebP o AVIF, no definir dimensions explícites (cosa que causa CLS) i carregar totes les imatges a l’inici en lloc de fer servir lazy loading són errors que per si sols poden afegir 2–4 segons al temps de càrrega. Convertir imatges a formats de nova generació com imatges WebP redueix el seu pes entre un 25% i un 35% sense pèrdua visible de qualitat.

CSS render-blocking

Els arxius CSS bloquen el renderitzat del navegador: fins que no es descarreguen i processen completament, l’usuari veu una pantalla en blanc. Quan un lloc carrega un arxiu CSS monolític de 300 KB que inclou estils per a seccions que l’usuari no veurà en la càrrega inicial, està pagant un cost de renderitzat innecessari. Tècniques com l’extracció de CSS crític, la càrrega diferida del CSS no visible i l’eliminació de CSS render-blocking poden reduir el temps fins al primer pintat en 500–800 mil·lisegons.

JavaScript excessiu

El JavaScript és sovint el recurs més costós en termes de rendiment: no només cal descarregar-lo, sinó parsejar-lo, compilar-lo i executar-lo. Una pàgina web mitjana carrega 500 KB de JavaScript, però molts llocs superen els 2 MB. Cada kilobyte de JavaScript afegeix un cost de processament desproporcionat en dispositius mòbils de gamma mitjana. Eliminar JavaScript no utilitzat és una de les intervencions amb més impacte en LCP i INP.

Hosting inadequat

El temps de resposta del servidor (TTFB, Time to First Byte) és el punt de partida de tota la cascada de càrrega. Un hosting compartit saturat pot tenir un TTFB de 800 ms o més, cosa que significa que el navegador no comença a treballar fins que gairebé ha passat un segon complet. Com a referència, Google recomana un TTFB inferior a 800 ms, però els llocs millor optimitzats estan per sota de 200 ms.

Absència d’estratègia de memòria cau

Sense capçaleres de memòria cau adequades, el navegador descarrega tots els recursos des de zero en cada visita. Configurar correctament Cache-Control amb durades apropiades per a cada tipus de recurs (immutable per a arxius versionats, més curta per a HTML) pot reduir dràsticament els temps de càrrega en visites repetides, que representen de mitjana el 35% del trànsit d’un lloc.

Dades reals: com la velocitat afecta el CTR, bounce rate i conversió

Les dades sobre l’impacte de la velocitat en el comportament de l’usuari són consistents al llarg de múltiples estudis i sectors. No són projeccions teòriques: són mesuraments reals d’empreses que han documentat l’abans i el després de les seves optimitzacions.

Abandonament i bounce rate. Think with Google va publicar dades que mostren que el 53% de les visites mòbils s’abandonen si la pàgina tarda més de 3 segons a carregar. La probabilitat de rebot augmenta un 32% quan el temps de càrrega passa d’1 a 3 segons, un 90% quan arriba als 5 segons, i un 123% quan arriba als 10 segons. Aquestes dades procedeixen d’una anàlisi d’11 milions de sessions mòbils.

Conversió. L’estudi de Google i Deloitte “Milliseconds Make Millions” de 2020 va documentar que una millora de 0,1 segons en el temps de càrrega genera resultats mesurables en totes les verticals analitzades. En retail, les conversions van pujar un 8,4%. En viatges, un 10,1%. En el sector luxe, la millora va ser del 8% en pàgines vistes. Vodafone va reportar que una millora del seu LCP del 31% va generar un 8% més de vendes. Segons les dades de WPO Stats, que recopila més de 150 casos d’estudi de rendiment web, la relació entre velocitat i conversió és pràcticament lineal fins als 5 segons de temps de càrrega.

Impacte en la velocitat i conversió. Un cas específic documentat per Google: Renault va reconstruir el seu lloc amb un enfocament en rendiment i va aconseguir una millora del 40% en LCP. El resultat directe va ser una reducció del 14% en el bounce rate i un increment del 13% en conversions de lead. Aquestes dades corresponen a un test A/B controlat amb trànsit real, no a una correlació observacional.

SEO directe. Més enllà del comportament de l’usuari, la velocitat afecta el crawl budget de Googlebot. Search Engine Land va documentar que servidors amb TTFB superior a 500 ms reben sistemàticament menys rastreig de Googlebot. Per a llocs amb desenes de milers de pàgines, aquesta diferència pot significar que Google descobreix canvis en el contingut amb dies o setmanes de retard.

La relació entre velocitat web i SEO: què diu Google oficialment

Google ha estat progressivament més explícit sobre el paper de la velocitat en el posicionament. La cronologia de les seves declaracions oficials no deixa espai a l’ambigüitat.

El 2010, Google va anunciar que la velocitat del lloc era un factor de rànquing per a cerques d’escriptori. El juliol de 2018, amb la “Speed Update”, va estendre aquest factor a les cerques mòbils. El maig de 2020, va introduir els Core Web Vitals com a mètriques específiques d’experiència d’usuari. I des del juny de 2021, els Core Web Vitals es van integrar com a senyals directes de rànquing dins el sistema d’experiència de pàgina.

No obstant això, la posició de Google sempre ha inclòs un matís important que convé entendre. John Mueller, Search Advocate de Google, va declarar el 2023: “Speed is a ranking factor, but it’s not the most important one. If you have great content that happens to be a bit slow, it can still rank well.” Això no significa que la velocitat sigui irrellevant; significa que és un factor entre molts. Però l’evidència mostra que funciona com a desempat: quan dues pàgines tenen contingut de qualitat comparable, la més ràpida té avantatge.

Segons Addy Osmani, enginyer de Chrome i autor de “Learning Patterns” i expert en rendiment web de Google, “el rendiment web no és una optimització opcional; és una qüestió d’accessibilitat. Quan el teu lloc tarda 6 segons a carregar en un dispositiu mòbil de gamma mitjana amb 3G, estàs excloent milions d’usuaris.” Aquesta perspectiva amplia la conversa més enllà del SEO: la velocitat determina qui pot fer servir el teu web i qui no.

Les tres mètriques que Google utilitza com a senyals de rànquing són els Core Web Vitals:

• LCP (Largest Contentful Paint): mesura quant tarda l’element visual més gran a carregar-se completament. El llindar de “bo” és inferior a 2,5 segons.
• INP (Interaction to Next Paint): mesura la capacitat de resposta de la pàgina davant interaccions de l’usuari. Va substituir FID el març de 2024. El llindar de “bo” és inferior a 200 mil·lisegons.
• CLS (Cumulative Layout Shift): mesura l’estabilitat visual de la pàgina mentre es carrega. El llindar de “bo” és inferior a 0,1.

Una distinció crítica: Google mesura aquestes mètriques amb dades reals d’usuaris de Chrome (dades “de camp” del Chrome User Experience Report), no només amb mesuraments de laboratori. Un lloc pot tenir una puntuació perfecta a Lighthouse però fallar en dades de camp si els seus usuaris reals accedeixen des de dispositius lents o connexions inestables.

Com mesurar la velocitat web: eines i mètriques clau

Mesurar la velocitat web correctament requereix distingir entre dos tipus de dades fonamentalment diferents: dades de laboratori i dades de camp. Ambdues són necessàries, però mesuren coses diferents i porten a decisions diferents.

Dades de laboratori són mesuraments realitzats en un entorn controlat, amb un dispositiu simulat, una connexió de xarxa predeterminada i sense interferència d’extensions del navegador. Són reproduïbles i útils per diagnosticar problemes tècnics específics. L’eina de referència és Lighthouse (integrada a Chrome DevTools i a PageSpeed Insights).

Dades de camp són mesuraments reals recopilats d’usuaris de Chrome que visiten el teu lloc. Reflecteixen les condicions reals dels teus usuaris: els seus dispositius, les seves connexions, la seva ubicació geogràfica. Les dades de camp procedeixen del Chrome User Experience Report (CrUX) i són les que Google utilitza com a senyal de rànquing. Es consulten a Google Search Console (secció “Core Web Vitals”) i a PageSpeed Insights (panell “Dades de camp”).

La diferència entre ambdues pot ser dramàtica. Un lloc pot obtenir 95 a Lighthouse amb la simulació estàndard de Moto G Power a 4G i, tanmateix, tenir un LCP de 4,2 segons en dades de camp perquè la majoria dels seus usuaris accedeixen des de zones rurals amb connexions 3G. Per això, optimitzar només per a la puntuació de Lighthouse sense monitoritzar dades de camp és un error estratègic.

Eines essencials:

• PageSpeed Insights (pagespeed.web.dev): l’eina més completa per obtenir dades de camp i de laboratori en una sola consulta. Mostra Core Web Vitals reals del CrUX i recomanacions prioritzades de Lighthouse.
• Google Search Console: la secció “Core Web Vitals” mostra el percentatge d’URLs que passen els llindars d’LCP, INP i CLS amb dades de camp. És la font definitiva per saber si Google considera que el teu lloc té un bon rendiment.
• WebPageTest (webpagetest.org): permet mesurar des d’ubicacions geogràfiques específiques, amb dispositius i connexions concretes. Genera filmstrip visual i diagrama de cascada (waterfall) per diagnosticar colls d’ampolla.
• Chrome DevTools (pestanya Performance): per a anàlisi granular del rendiment en temps real: temps de parseig de JavaScript, cost d’estils, layout shifts i long tasks.
• Lighthouse CI: per integrar mesuraments de rendiment al pipeline de desenvolupament i detectar regressions abans que arribin a producció.

La mètrica més rellevant per al SEO és l’LCP, perquè és la que millor reflecteix la percepció de velocitat de l’usuari i la més correlacionada amb taxes d’abandonament. Un LCP inferior a 2,5 segons és l’objectiu. Un LCP entre 2,5 i 4 segons requereix atenció. Un LCP superior a 4 segons és un problema urgent.

Velocitat web en mòbil vs escriptori: prioritats diferents

Google va adoptar el Mobile-First Indexing de manera universal el 2023. Això significa que la versió mòbil del teu lloc és la que Google rastreja, indexa i utilitza per determinar el rànquing. Si el teu web és ràpid a l’escriptori però lent al mòbil, Google avalua la versió lenta.

Les dades de l’HTTP Archive mostren una disparitat persistent entre rendiment mòbil i d’escriptori. La mediana d’LCP a l’escriptori és de 2,1 segons, però al mòbil puja a 3,8 segons. Només el 43% dels llocs web compleixen els llindars de Core Web Vitals al mòbil, enfront del 72% a l’escriptori. La bretxa es deu a tres factors: processadors menys potents, connexions més lentes i pantalles que exigeixen renderitzat adaptatiu.

La diferència de processament entre un MacBook Pro i un telèfon Android de gamma mitjana és d’un factor 4-6x en capacitat de CPU. Això significa que un arxiu JavaScript d’1 MB que es parseja en 200 ms en un portàtil pot tardar 800-1.200 ms en un Redmi Note o un Samsung Galaxy A. Com assenyala Addy Osmani, “el JavaScript és el recurs més costós byte per byte, i aquest cost es multiplica en dispositius mòbils.”

Prioritats específiques per a mòbil:

• Reduir el pes total de la pàgina. La mediana de pes al mòbil és 2,1 MB segons HTTP Archive. Un objectiu raonable és mantenir-se per sota d’1,5 MB, prioritzant la compressió d’imatges i l’eliminació de JavaScript innecessari.
• Optimitzar el critical rendering path. Al mòbil, cada mil·lisegon compta més. Servir el CSS crític inline i diferir la resta redueix el temps fins al primer pintat (FCP) de manera significativa.
• Implementar responsive images amb srcset. Servir imatges de 2.000 px d’ample a un mòbil amb pantalla de 375 px és un malbaratament d’ample de banda. Les imatges responsives serveixen la resolució correcta per a cada dispositiu.
• Prioritzar l’INP. Al mòbil, les interaccions de l’usuari (tocs, desplaçaments, formularis) són més freqüents i la tolerància al retard és menor. Un INP alt al mòbil genera una percepció de “web travat” que augmenta els abandonaments.

Per a llocs amb audiència majoritàriament mòbil (que a Catalunya representa més del 65% del trànsit web segons dades d’Statcounter), l’optimització de rendiment mòbil no és una millora marginal: és el factor que determina si el lloc competeix o no als resultats de cerca.

Casos reals: webs que van millorar velocitat i multiplicar el trànsit

Els casos d’estudi documentats per WPO Stats i per les pròpies publicacions de Google ofereixen evidència concreta de l’impacte que té la velocitat en resultats de negoci. No són escenaris teòrics; són dades de producció d’empreses reals.

Vodafone. L’operadora va optimitzar el seu LCP i va aconseguir una millora del 31%. El resultat: un increment del 8% en vendes en línia. L’optimització es va centrar en dues àrees: compressió d’imatges hero amb formats de nova generació i eliminació de JavaScript de tercers que blocava el renderitzat.

Rakuten. El marketplace japonès va reportar un increment del 33,13% en conversions i del 53,37% en ingressos per visitant després d’una optimització integral de Core Web Vitals. El treball va incloure refactorització del JavaScript de producte, implementació de lazy loading per a imatges below-the-fold i millora del TTFB mitjançant memòria cau en edge.

The Telegraph. El mitjà britànic va documentar que una millora de 4 segons en el temps de càrrega va generar un 11% més de pàgines vistes per sessió. L’optimització es va basar en l’eliminació de codi CSS i JavaScript legacy que s’havia acumulat durant anys.

Pinterest. La xarxa social va reduir els temps d’espera percebuts un 40% i va aconseguir un increment del 15% en trànsit orgànic i un 44% més en registres de nous usuaris. L’optimització es va centrar en la implementació de progressive rendering i la reducció del bundle JavaScript.

Yelp. La plataforma de ressenyes va millorar el seu First Contentful Paint en 2,4 segons i va documentar un increment del 15% en conversions. La clau va ser implementar Server-Side Rendering per a les pàgines de resultat de cerca, que abans depenien completament de CSR.

Aquests casos comparteixen un patró: les empreses no van optimitzar “la velocitat” com a concepte abstracte. Van identificar les causes concretes de lentitud en el seu stack tecnològic, van prioritzar per impacte mesurable i van validar cada canvi amb dades de producció.

Full de ruta per millorar la velocitat del teu web

Una optimització de velocitat web efectiva segueix un procés estructurat. No es tracta d’aplicar una llista de trucs, sinó de diagnosticar, prioritzar, implementar i validar. Aquest full de ruta està ordenat per impacte i pot aplicar-se tant a llocs WordPress com a aplicacions web custom.

Fase 1: Diagnòstic (setmana 1)

1. Mesurar l’estat actual amb PageSpeed Insights i Google Search Console. Documentar LCP, INP i CLS tant de camp com de laboratori per a les 10 pàgines amb més trànsit.
2. Analitzar el waterfall amb WebPageTest o Chrome DevTools per identificar els recursos que bloquen el renderitzat.
3. Auditar el pes de la pàgina desglossat per tipus de recurs: imatges, CSS, JavaScript, tipografies, tercers.
4. Comparar mòbil vs escriptori i identificar les majors disparitats.

Fase 2: Quick wins (setmanes 2-3)

1. Optimitzar imatges: convertir a WebP/AVIF, definir dimensions explícites, implementar lazy loading per a imatges below-the-fold.
2. Eliminar CSS i JavaScript no utilitzats: auditar amb l’eina Coverage de Chrome DevTools.
3. Configurar memòria cau del navegador: establir Cache-Control: max-age=31536000, immutable per a recursos estàtics versionats.
4. Habilitar compressió: verificar que Brotli o gzip estan actius a nivell de servidor per a HTML, CSS i JavaScript.

Fase 3: Optimització profunda (setmanes 4-6)

1. Extreure i inline el CSS crític per eliminar CSS render-blocking de l’above-the-fold.
2. Implementar code splitting en JavaScript per carregar només el codi necessari a cada pàgina.
3. Optimitzar tipografies web: fer servir font-display: swap, precarregar la tipografia principal amb <link rel="preload">, i considerar tipografies del sistema com a fallback.
4. Avaluar el TTFB i, si és superior a 500 ms, considerar un upgrade de hosting, implementar una capa de memòria cau amb CDN o adoptar generació estàtica.

Fase 4: Validació i monitorització (contínua)

1. Mesurar l’impacte comparant les mètriques de Core Web Vitals abans i després de cada canvi.
2. Configurar alertes a Google Search Console per a regressions de Core Web Vitals.
3. Integrar Lighthouse CI al pipeline de desplegament per detectar regressions abans de producció.
4. Revisar trimestralment les mètriques de camp al CrUX i ajustar l’estratègia en funció dels canvis en els patrons de trànsit.

La velocitat no és un projecte, és un estàndard operatiu

La velocitat web no és una tasca que es completa una vegada i s’oblida. És un estàndard operatiu que s’ha d’integrar en el procés de desenvolupament, disseny i publicació de contingut de forma permanent. Cada nova imatge sense optimitzar, cada biblioteca JavaScript afegida sense avaluar el seu cost de rendiment, cada canvi de tema o plugin sense auditoria prèvia és una regressió potencial que erosiona el posicionament orgànic.

Les empreses que de manera consistent dominen els resultats de cerca en els seus sectors no són necessàriament les que tenen el millor contingut o el major pressupost de màrqueting. Són les que han construït una cultura interna on el rendiment és un criteri de decisió, no una conseqüència de la bona sort. Això implica que l’equip de desenvolupament comprèn el cost real de cada dependència, que l’equip de disseny treballa amb pressupostos de pes per pàgina, i que l’equip de màrqueting sap que una landing page de campanya que tarda 5 segons a carregar malbaratarà bona part de la inversió publicitària.

Com mostren les dades de Google, Deloitte, Vodafone, Rakuten i desenes d’altres casos documentats, la relació entre velocitat i resultats de negoci no és teòrica ni marginal. És lineal, mesurable i replicable. Cada dècima de segon compta.