Si tu sitio web tarda más de 3 segundos en mostrar el contenido principal, un usuario móvil ya se marchó. Y no volvió. Este comportamiento está tan bien documentado que Google decidió convertirlo en un factor oficial de ranking: si tu web es lenta o inestable, aparecés más abajo en los resultados de búsqueda, independientemente de qué tan buen contenido tengas o cuánto hayas invertido en SEO.
Para cuantificar exactamente qué significa "lento" o "inestable", Google lanzó los Core Web Vitals: un conjunto de métricas técnicas que miden la experiencia real del usuario cuando visita tu sitio. No son métricas teóricas de laboratorio. Son datos capturados de millones de visitas reales, del Chrome User Experience Report, que Google usa para evaluar tu sitio en las condiciones en que tus propios clientes lo experimentan.
Para una PyME o empresa argentina con presencia online, esto tiene implicancias directas. Tu competencia en Google no es solo de contenido ni de keywords: es también de rendimiento técnico. Un sitio rápido y estable tiene una ventaja estructural en el posicionamiento orgánico. Uno lento paga ese costo todos los días, en visitas que no llegan y clientes que se van antes de ver tu propuesta.
Entender qué miden los Core Web Vitals, cómo se evalúan y qué acciones concretas mejoran cada uno es el primer paso para tomar decisiones inteligentes sobre tu presencia digital. No hace falta ser desarrollador para entender el concepto; sí hace falta un equipo técnico capaz para implementar las soluciones.
LCP — Qué mide y cómo mejorarlo
El LCP (Largest Contentful Paint) mide el tiempo que tarda en renderizarse el elemento visual más grande de la página: generalmente una imagen hero, un banner principal o un bloque de texto destacado. Google considera que un LCP menor a 2,5 segundos es "bueno". Entre 2,5 y 4 segundos es "necesita mejorar". Por encima de 4 segundos, directamente "malo".
El LCP es probablemente la métrica que más impacto tiene en la percepción de velocidad, porque define cuándo el usuario siente que la página "llegó". Si tu imagen principal tarda 5 segundos en aparecer, la persona tiene 5 segundos para preguntarse si algo falló y cerrar la pestaña.
Las causas más frecuentes de un LCP elevado en sitios argentinos son:
- Imágenes sin optimizar: Subir una foto de 4 MB en formato JPEG cuando podría servirse en WebP con 200 KB es uno de los problemas más comunes. El formato WebP reduce el peso de las imágenes entre un 25% y un 35% respecto a JPEG sin pérdida visual perceptible. Agregar
loading="lazy"a las imágenes fuera del viewport evita cargas innecesarias al inicio. - Falta de preload para recursos críticos: Si tu imagen principal no está declarada con
<link rel="preload">en el HTML, el navegador la descubre tarde, cuando ya procesó el CSS y el JS. Priorizar la carga de ese recurso crítico puede recortar el LCP en 1 o 2 segundos. - Servidores lentos o sin CDN: Un hosting compartido de bajo costo ubicado en Estados Unidos puede agregar 300-500 ms solo por latencia geográfica. Un servidor en Brasil o Argentina con CDN hace una diferencia concreta para usuarios locales.
- JavaScript bloqueante: Los scripts que se cargan de forma síncrona en el
<head>detienen el renderizado completo de la página. Diferir o mover esos scripts al final del<body>libera el renderizado inicial.
En LUMORA trabajamos con imágenes en formato WebP generadas en el proceso de build, implementamos preload selectivo para los recursos above-the-fold y utilizamos servidores con baja latencia para Argentina. El resultado habitual es bajar el LCP por debajo de los 2 segundos.
FID/INP — Interactividad y respuesta del navegador
Google reemplazó el FID (First Input Delay) por el INP (Interaction to Next Paint) como métrica oficial en 2024. Mientras el FID medía solo la primera interacción del usuario con la página, el INP mide la latencia de todas las interacciones durante toda la sesión: clics en botones, selecciones en formularios, apertura de menús desplegables.
Google considera un INP menor a 200 ms como "bueno". Esto significa que cuando un usuario hace clic en tu botón de contacto o agrega un producto al carrito, el navegador debe responder visualmente en menos de 200 milisegundos. Si tarda más, el usuario siente que el sitio "no responde" o que "está roto", aunque técnicamente esté funcionando.
El culpable principal de un INP elevado es casi siempre el JavaScript. Específicamente:
- Tareas largas en el hilo principal: El navegador tiene un solo hilo de ejecución para JS y renderizado. Si un script ocupa ese hilo durante más de 50 ms, las interacciones del usuario quedan en cola y el sitio parece no responder.
- Frameworks o librerías pesadas mal implementadas: WordPress con una docena de plugins activos, o una landing page construida con un page builder que carga 800 KB de JS, son recetas para un INP elevado.
- Terceros no optimizados: Scripts de analytics, chat, publicidad y redes sociales pueden bloquear el hilo principal. Cargarlos de forma asíncrona y diferida es clave.
La solución requiere auditar el JS con herramientas como Chrome DevTools o Lighthouse, identificar qué tareas bloquean el hilo principal y refactorizarlas, diferirlas o eliminarlas. En sitios construidos con código propio y limpio, este problema es mucho más fácil de controlar que en plataformas genéricas.
CLS — El problema de los elementos que "saltan"
El CLS (Cumulative Layout Shift) es la métrica más frustrante para los usuarios y, curiosamente, una de las más ignoradas en el desarrollo web argentino. Mide cuánto se desplazan los elementos visuales de la página mientras se carga. Google considera un CLS menor a 0,1 como "bueno".
¿Cuándo ocurre el CLS? Cuando visitás un sitio, empezás a leer, y de repente el texto salta hacia abajo porque una imagen cargó sin dimensiones definidas. O cuando estás a punto de hacer clic en un botón y un banner publicitario aparece encima y hacés clic en el banner sin querer. O cuando una fuente web reemplaza la fuente de sistema y todo el texto se redistribuye visualmente.
Esto no es solo molesto: tiene consecuencias económicas directas. Un usuario que intenta hacer clic en "Comprar" y termina haciendo clic en otro elemento por un salto de layout no va a intentarlo de nuevo. Se va.
Las causas más comunes del CLS elevado son:
- Imágenes sin atributos
widthyheight: Si el navegador no sabe el tamaño de la imagen antes de descargarla, no puede reservar el espacio. Cuando la imagen carga, empuja todo lo que estaba debajo. - Anuncios y embeds sin contenedores de tamaño fijo: Los banners de Google Ads o los embeds de redes sociales que "aparecen" de la nada son los responsables habituales.
- Fuentes web cargadas tarde (FOUT): El cambio visual entre la fuente de fallback y la fuente web final puede causar redistribución del texto.
La solución es relativamente directa: definir dimensiones en todas las imágenes, usar font-display: optional o precargar fuentes críticas, y reservar espacio para contenido de terceros con CSS.
Cómo impactan en ventas y conversiones
Las métricas técnicas son importantes, pero lo que le interesa a una empresa argentina es el impacto en resultados concretos. Los datos de la industria son contundentes:
- Por cada segundo adicional de tiempo de carga, las conversiones caen entre un 7% y un 12%, según estudios de Akamai y Deloitte Digital.
- Google reportó que los sitios que mejoran su LCP ven aumentos de hasta 20% en conversiones.
- Vodafone observó un aumento del 31% en ventas tras reducir su LCP en 31%.
- Un CLS elevado puede reducir las intenciones de compra hasta un 24%, según datos de Google/SOASTA.
Para una tienda online, una landing de servicios o un sitio de generación de leads, estas diferencias son directamente dinero. Si tu sitio recibe 1.000 visitas mensuales y tiene una tasa de conversión del 2%, mejorar el rendimiento hasta promediar un 3% de conversión son 10 clientes más por mes sin aumentar ni un peso el presupuesto de publicidad.
En el contexto argentino, donde la mayoría de las búsquedas se realizan desde dispositivos móviles con conexiones variables, el impacto del rendimiento es todavía más pronunciado. Un sitio lento en 4G no es solo una mala experiencia: es una oportunidad de venta que se pierde.
La ventaja del código a medida vs plantillas
WordPress es la plataforma más usada del mundo y tiene méritos indiscutibles para muchos casos de uso. Pero también es la fuente más frecuente de problemas de rendimiento en los sitios que auditamos. La razón es estructural: WordPress fue diseñado para ser flexible y extensible, no para ser veloz. Cada plugin activo agrega código al frontend. Un tema premium genérico puede cargar entre 1 y 3 MB de CSS y JS que tu sitio en particular nunca usa.
Los page builders populares como Elementor o Divi, aunque facilitan la construcción visual, generan HTML anidado y pesado, cargan docenas de scripts de manera global y hacen muy difícil el control fino sobre qué se carga y cuándo. Conseguir un LCP menor a 2,5 segundos en WordPress con un page builder requiere un nivel de optimización agresiva (caché, minificación, plugins de performance, CDN) que a menudo introduce su propia complejidad y puntos de falla.
En LUMORA desarrollamos sitios con código HTML, CSS y JavaScript a medida. Esto significa que cada línea de código que llega al navegador tiene un propósito específico. No hay CSS de funcionalidades que no usás. No hay JS de plugins que solo necesitan el 10% de lo que traen. El resultado son sitios que parten desde un baseline de rendimiento muy superior, donde alcanzar un LCP menor a 2 segundos, un INP bajo 200 ms y un CLS prácticamente nulo no es una tarea de optimización: es el punto de partida por defecto.
Para empresas que compiten en Google y dependen de su presencia digital para generar clientes, esa diferencia estructural en el rendimiento es una ventaja competitiva sostenida en el tiempo.
¿Querés saber cómo está rindiendo tu sitio actual? En LUMORA hacemos una auditoría de Core Web Vitals gratuita y te contamos exactamente dónde está perdiendo puntos tu web y cómo resolverlo.
Auditá mi sitio web