Velocitat web i SEO: per què la càrrega lenta et fa perdre posicions (i com solucionar-ho)

Quan audito una web per primera vegada —un restaurant de Gràcia, una clínica de Tarragona o una botiga online de Sabadell— el primer que miro no és el contingut ni els backlinks. Miro la velocitat. I en la majoria dels casos és el problema més gran que ningú ha tocat mai. La velocitat web és un factor de posicionament SEO confirmat per Google, però el seu impacte va molt més enllà del ranquing: determina quants usuaris es queden, naveguen i acaben comprant o contactant.

Què mesura Google exactament (i com ho comproves tu)

Google no mesura el temps total de càrrega com feia fa deu anys. Ara avalua l'experiència percebuda: quan apareix el primer contingut útil, quan l'usuari pot fer clic sense errors i si la pàgina «salta» mentre carrega. Tres eines que hauries de tenir obertes ara mateix:

• Google PageSpeed Insights: entra la URL de la teva portada i de la teva pàgina de servei o producte principal. Molts negocis optimitzen la portada i obliden les pàgines que realment converteixen. La puntuació en mòbil és la que compta: Google indexa en mode mobile-first.
• Google Search Console → Experiència de pàgina → Core Web Vitals: aquí veus quantes URLs reals del teu lloc estan en «Deficient», «Necessita millora» o «Bona». Això no és una simulació: són dades d'usuaris reals amb Chrome. Si tens URLs en vermell, Google ja sap que la teva web és lenta.
• GTmetrix: útil per identificar exactament quin recurs —una imatge concreta, un script de tercers, una font web— és el que bloqueja la càrrega. PageSpeed et diu el «què»; GTmetrix t'ajuda amb el «quin».

Core Web Vitals: les tres mètriques que importen

Des del 2021, Google utilitza tres indicadors per avaluar la velocitat i l'estabilitat de qualsevol pàgina. Entendre cadascun t'ajuda a saber on actuar primer, en lloc de tocar-ho tot a cegues.

Un detall que molts articles passen per alt: el LCP es calcula sobre dades reals d'usuaris (Chrome User Experience Report), no sobre simulacions de laboratori. Això vol dir que si els teus clients utilitzen mòbils de gamma mitjana o connexions 4G irregulars —molt habitual en zones rurals de Lleida o Tarragona—, la teva puntuació real pot ser significativament pitjor del que veus quan fas la prova des del teu ordinador d'oficina amb fibra.

L'impacte real en negocis catalans

Les generalitats no ajuden ningú. Aquí tens tres casos concrets del que ens hem trobat treballant amb clients:

Comerç de moda online a Girona. La web trigava entre 6 i 8 segons a carregar en mòbil, i el 70% del seu tràfic era mòbil. El problema principal era un carrusel de banners a la portada amb imatges de més de 2 MB cadascuna, carregades totes alhora. Quan vam reduir el LCP per sota dels 2,5 segons —comprimint imatges, eliminant el carrusel i activant caché—, la taxa de rebot va baixar i les sessions de més de dues pàgines van augmentar. Les posicions per a keywords de producte van millorar en les setmanes següents.

Clínica de fisioteràpia a Tarragona. Aquí el problema no era la velocitat bruta sinó el CLS: un banner de cookies mal configurat feia saltar tot el contingut quan apareixia, generant clics accidentals i una experiència terrible en mòbil. La solució va ser reservar espai fix per al banner al CSS. Temps d'implementació: menys d'una hora. Resultat: CLS de 0,38 a 0,04.

Restaurant de Gràcia (Barcelona) amb WordPress. Tenien un slider de fotos a la portada amb imatges de 4 MB cadascuna. El LCP era de 9 segons. Vam comprimir les imatges, eliminar el slider —que, a més, no aportava res a la conversió— i activar caché. Resultat: LCP de 2,1 segons i millora de visibilitat a Google en menys de dos mesos.

Els errors que trobo una vegada i una altra

Ordenats per freqüència real en auditories de webs catalanes:

1. Imatges sense comprimir ni convertir a WebP. El problema número u, sense discussió. Una foto pujada directament des del mòbil pot pesar 3-4 MB. En WebP, la mateixa imatge pot baixar a 80-120 KB sense pèrdua visible de qualitat. L'impacte al LCP és immediat.
2. Hosting compartit de gamma baixa. És el sostre de tot. Si el teu TTFB (Time to First Byte) supera els 600 ms, el problema és el servidor, no el codi. Cap plugin de caché compensarà un servidor que triga més de mig segon a respondre. Mesura el TTFB amb GTmetrix abans de tocar res més.
3. Plugins de WordPress sense auditar. Cada plugin actiu carrega fitxers CSS i JS a totes les pàgines, fins i tot quan no s'utilitza en aquella pàgina concreta. He vist webs amb 50 plugins actius on 20 eren redundants o no s'havien tocat en anys.
4. Scripts de tercers sense defer ni async. Píxels de Meta, Google Tag Manager mal configurat, xats en viu, widgets d'Instagram… Si es carreguen de manera síncrona, bloquegen tot el renderitzat. Afegir defer o async als scripts que no són crítics és un dels canvis amb millor ràtio impacte/esforç.
5. No revisar PageSpeed després d'actualitzar. He vist webs que passaven de 78 a 44 punts d'un dia per l'altre per una actualització de tema o plugin que afegia un nou script. Configurar una alerta mensual al calendari per revisar PageSpeed i Search Console és la mesura preventiva més senzilla que existeix.

Pla d'acció per prioritat: per on començar

La clau no és fer-ho tot alhora. És fer primer el que té més impacte amb menys esforç. Aquest és l'ordre que segueixo en els meus projectes:

Per a WordPress, la combinació Imagify + WP Rocket + Cloudflare cobreix el 70% dels problemes habituals amb una inversió mínima de temps. No és la solució perfecta per a tots els casos, però és el punt de partida que recomano per a la majoria de pimes.

Per a webs a mida, Shopify o Prestashop, les prioritats són les mateixes —imatges, caché, scripts de tercers, servidor— però l'execució requereix perfil tècnic. Si el teu equip no el té, o simplement vols saber exactament on perds punts abans de decidir res, escriu-nos i fem una revisió inicial gratuïta de la teva web. T'expliquem el diagnòstic i l'ordre d'actuació sense compromís.