Tu web puede ser visualmente impactante, tener el copy perfecto y estar llena de testimonios convincentes. Pero si tarda más de tres segundos en cargar, la mayoría de tus visitantes ya se fue. Y Google lo sabe — y te penaliza por eso.

La velocidad de carga no es un detalle técnico secundario: es un factor de posicionamiento directo en Google desde 2021, cuando la empresa incorporó los Core Web Vitals como señal de ranking. En este artículo te explicamos qué son, cómo medirlos y qué podés hacer para mejorarlos, incluso sin ser programador.

¿Por qué Google premia la velocidad?

La respuesta es simple: Google quiere que sus usuarios tengan buenas experiencias. Si el buscador te manda a una web lenta, el usuario vuelve a Google frustrado — y eso daña la reputación del buscador. Por eso Google empezó a medir la experiencia real del usuario en cada sitio y a usarla como señal de calidad.

Pero además de SEO, hay un argumento de negocio puro:

53%

de los usuarios móviles abandona un sitio que tarda más de 3 segundos en cargar. Cada segundo adicional de demora reduce las conversiones en un 7% promedio. Fuente: Google/SOASTA Research.

Una web lenta no solo pierde posición en Google — pierde clientes en el momento exacto en que más los necesita.

¿Qué son los Core Web Vitals?

Los Core Web Vitals son tres métricas oficiales de Google que miden aspectos concretos de la experiencia del usuario en tu web. No son teóricas: se calculan a partir del comportamiento real de visitantes reales en el Chrome Real User Monitoring (CrUX).

LCP Largest Contentful Paint < 2.5 s

Tiempo hasta que el elemento más grande visible (imagen, titular, bloque) termina de cargarse. Mide la percepción de velocidad inicial.

CLS Cumulative Layout Shift < 0.1

Cuánto se mueve visualmente el contenido mientras carga la página. Un CLS alto significa que los botones y textos saltan — frustrante para el usuario.

INP Interaction to Next Paint < 200 ms

Tiempo que tarda la página en responder cuando el usuario hace clic o toca algo. Reemplazó al FID en 2024 y mide la interactividad real.

Si los tres están en verde, Google considera que tu web tiene una buena experiencia de página. Eso no garantiza el primer puesto — el contenido sigue siendo rey — pero te da una ventaja real sobre competidores con webs lentas.

Cómo medirlos ahora mismo (sin pagar nada)

Herramienta Qué mide Tipo
PageSpeed Insights
pagespeed.web.dev
LCP, CLS, INP + puntuación 0–100 + sugerencias concretas. Combina datos reales (CrUX) con datos de laboratorio. Gratis
Google Search Console
search.google.com/search-console
Informe de "Experiencia de página" con datos reales de tus usuarios. Muestra URLs con problemas y su estado. Gratis
GTmetrix
gtmetrix.com
Análisis detallado de waterfall (qué recurso tarda qué), con filmstrip visual del proceso de carga. Gratis
WebPageTest
webpagetest.org
El más técnico y detallado. Permite testar desde múltiples ubicaciones geográficas y con conexiones simuladas. Gratis
Lighthouse (Chrome DevTools) Auditoría completa de performance, SEO, accesibilidad y best practices. Se ejecuta en tu propio navegador. Gratis

Por dónde empezar: abrí pagespeed.web.dev, pegá la URL de tu web y mirá el score en móvil. Si está por debajo de 70, tenés trabajo por hacer. Si está por debajo de 50, es urgente.

Las 6 causas más comunes de lentitud (y cómo solucionarlas)

La gran mayoría de los problemas de velocidad viene de las mismas fuentes. Estas son las más frecuentes y lo que podés hacer con cada una:

1. Imágenes sin optimizar

Es el problema número uno en webs de pequeñas y medianas empresas. Una imagen de 3 MB en formato JPEG puede pesar 180 KB en formato WebP con la misma calidad visual. Multiplicá eso por las 10–20 imágenes de tu home y el impacto es brutal.

Qué hacer: convertí todas tus imágenes a WebP usando Squoosh (gratis, del mismo Google). Además, siempre especificá el tamaño real con width y height en el HTML — esto evita el CLS porque el navegador sabe cuánto espacio reservar.

2. Imágenes que cargan aunque no se vean

Sin lazy loading, tu web descarga todas las imágenes de una sola vez — incluyendo las que están al final de la página y que el usuario quizás nunca llega a ver. Eso demora la carga del contenido visible y sube el LCP.

Qué hacer: agregá loading="lazy" a todas las imágenes que no estén en el hero. La excepción es la imagen principal del hero: a esa le ponés fetchpriority="high" para que cargue antes que todo.

3. Scripts de JavaScript bloqueantes

Muchos plugins, píxeles de redes sociales y herramientas de analytics se cargan en el <head> del HTML y bloquean todo el renderizado hasta que terminan. Cada milisegundo que esperan es un milisegundo de pantalla en blanco para el usuario.

Qué hacer: mové todos los scripts al final del <body> o usá el atributo defer (para scripts que dependen del DOM) o async (para scripts independientes como Analytics).

4. Fuentes tipográficas que bloquean el texto

Cuando tu web carga una tipografía desde Google Fonts u otro servidor, el navegador espera a tenerla antes de mostrar el texto — a esto se le llama FOIT (Flash Of Invisible Text) y es una fuente común de mal LCP.

Qué hacer: asegurate de tener font-display: swap en tu definición de fuentes. Esto hace que el navegador muestre el texto con una fuente del sistema mientras descarga la tipografía correcta, y la cambia cuando está lista.

5. Hosting lento o geográficamente lejano

Si tu web está alojada en un servidor en Estados Unidos y tu audiencia está en Argentina, cada request tiene que viajar miles de kilómetros. Eso se traduce en latencia alta — especialmente en móvil.

Qué hacer: elegí hosting con servidores en tu región (para Argentina: DonWeb, SiteGround con región US-Este, o Cloudflare Pages/Netlify que tienen edge nodes en LatAm). Para webs estáticas como las de Vialtio, Netlify y Cloudflare Pages son gratis y extremadamente rápidos desde cualquier parte del mundo.

6. WordPress con demasiados plugins

WordPress es un CMS poderoso, pero cada plugin agrega código JavaScript y CSS que el navegador tiene que procesar. Una instalación con 30–40 plugins puede tener tiempos de carga de 8–12 segundos en móvil, incluso con caché activo.

Qué hacer: auditá qué plugins realmente necesitás. Muchas funcionalidades se pueden lograr con código nativo. En proyectos nuevos, nosotros elegimos HTML estático siempre que sea posible — sin WordPress, sin page builders, sin JavaScript innecesario. El resultado son webs con scores de 95–100 en PageSpeed de entrada.

¿Querés saber exactamente qué está frenando tu web? En Vialtio hacemos una auditoría de velocidad y te decimos los tres cambios con mayor impacto para tu caso específico.

Pedí tu auditoría gratuita

Checklist rápida: lo mínimo no negociable

Si tenés que priorizar, estos son los puntos que mayor impacto tienen en menor tiempo:

  • Imágenes en formato WebP y peso inferior a 200 KB por imagen
  • width y height definidos en todas las imágenes del HTML
  • loading="lazy" en imágenes fuera del primer viewport
  • fetchpriority="high" en la imagen principal del hero
  • font-display: swap en todas las declaraciones de fuentes
  • Scripts con defer o async — nunca bloqueantes en el head
  • CSS crítico inlineado en el head — el resto cargando de forma no bloqueante
  • Sin plugins, librerías o frameworks que no se usen en la página
  • Hosting con servidor próximo al mercado principal (LatAm o España)
  • Score de PageSpeed Insights en móvil ≥ 80 como mínimo aceptable

¿Cuánto impacta realmente en el negocio?

Hay datos concretos de empresas que invirtieron en mejorar su velocidad. Walmart descubrió que cada segundo de mejora en el tiempo de carga aumentó las conversiones en un 2%. Mobify reportó que una mejora de 100 ms en el tiempo de carga de su homepage representó un 1,11% de aumento en conversiones — que para un e-commerce de volumen alto son millones de dólares.

Para una PyME argentina o española, el impacto es proporcional pero igual de real: menos rebotes, más tiempo en el sitio, más consultas por WhatsApp o formulario, mejor posicionamiento en Google. Son resultados que se miden y se ven en las primeras semanas.

La velocidad como parte del proceso, no como un parche

El error más común es construir una web sin pensar en performance y después tratar de "arreglarla" con plugins de caché o CDN. Esos parches ayudan, pero no resuelven el problema de raíz: código mal estructurado, imágenes gigantes, dependencias innecesarias.

En Vialtio construimos las webs con performance como restricción desde la primera línea de código. Sin WordPress, sin page builders, sin dependencias que no se justifiquen. El resultado son sitios que salen del deploy con 90+ en PageSpeed, no sitios que necesitan tres meses de optimización para llegar a 60.

Esa decisión de arquitectura es lo que distingue una web que posiciona de una web que existe.

¿Tu web actual tiene problemas de velocidad? Podemos auditarla, decirte exactamente qué está frenando tu posicionamiento y proponerte un plan de acción concreto — sin compromiso.

Hablemos de tu web
← Landing page vs. web corporativa SEO técnico: qué es y por qué importa →