Es común ver frases como "cada segundo de más cuesta tanto por ciento de las ventas". Hay estudios serios sobre el tema, pero sus números valen para el contexto de quien midió y no se trasladan automáticamente a tu sitio. Lo que sí se puede afirmar con seguridad es más simple: las páginas lentas, o que se mueven mientras cargan, frustran a quien está del otro lado, sobre todo en el celular. Y Google tiene una forma pública de medirlo: las Core Web Vitals.
En este post explico las tres métricas de forma práctica y lo que suele haber detrás de un sitio lento.
Datos de campo y datos de laboratorio
Antes de las métricas, una distinción que evita mucha confusión. Los datos de laboratorio son una simulación: Lighthouse carga la página en condiciones controladas y le pone una nota. Los datos de campo son lo que vivieron usuarios reales de Chrome, reunidos en el informe CrUX y mostrados en PageSpeed Insights y en Search Console.
Una nota de 100 en tu laptop no garantiza una buena experiencia para quien abre el sitio en un celular de gama media con poca señal. web.dev recomienda evaluar el percentil 75 de las visitas, separando celular y computadora. Es decir: la meta es que la gran mayoría de las personas tenga una buena experiencia, no solo el promedio.
Las tres métricas en resumen
| Métrica | Qué mide | Bueno |
|---|---|---|
| LCP (Largest Contentful Paint) | cuándo aparece el contenido principal | hasta 2,5 s |
| INP (Interaction to Next Paint) | cuánto tarda la página en responder a un toque o clic | hasta 200 ms |
| CLS (Cumulative Layout Shift) | cuánto se mueve el diseño por sí solo | hasta 0,1 |
LCP: ¿apareció el contenido principal?
El LCP marca el momento en que el elemento visible más grande, por lo general la imagen destacada o el bloque del título, termina de mostrarse. web.dev divide ese tiempo en cuatro partes: la respuesta del servidor, la demora hasta que el navegador empieza a descargar ese recurso, la descarga en sí y la demora hasta que se dibuja en pantalla.
Los culpables más comunes:
- una imagen destacada enorme, sin versiones para cada tamaño de pantalla y sin un formato moderno como WebP o AVIF;
- lazy loading aplicado justo a la imagen principal, lo que retrasa lo que debería llegar primero;
- una imagen que se descubre tarde porque viene de un CSS o la inserta JavaScript;
- un servidor lento o sin caché;
- una página que solo arma el contenido después de descargar y ejecutar mucho JavaScript.
INP: ¿respondió la página?
El INP reemplazó al antiguo FID como Core Web Vital en 2024. Mide el tiempo entre una interacción (tocar un botón, abrir un menú, escribir) y el siguiente fotograma que muestra el resultado en pantalla. Ese tiempo tiene tres fases: la espera hasta que el navegador puede atender el evento, el procesamiento en sí y la actualización visual.
Casi siempre el problema es demasiado JavaScript compitiendo por el mismo hilo principal: scripts de terceros (widgets de chat, píxeles de anuncios, gestores de etiquetas), tareas largas que no le devuelven el control al navegador y páginas con una cantidad enorme de elementos. La corrección empieza con una pregunta poco técnica: ¿este script de verdad tiene que estar aquí?
CLS: ¿dejó de moverse la página?
El CLS mide los cambios inesperados de diseño. Es el botón que baja justo en el momento en que ibas a tocarlo. Las causas más frecuentes, según el propio web.dev, son imágenes sin ancho y alto definidos; anuncios, embeds y banners insertados después de la carga; cambios de fuente que alteran el tamaño del texto; y animaciones hechas con propiedades que afectan el diseño en lugar de transform.
La solución suele ser reservar espacio: dimensiones o aspect-ratio en las imágenes, un área fija para lo que carga después y una fuente de respaldo con proporciones parecidas a la fuente final.
Lo que de verdad hace lento un sitio
En la práctica, los sitios de pequeñas y medianas empresas rara vez son lentos por una sola razón. El patrón que más encuentro es la acumulación: un tema prediseñado que carga los recursos de todas las páginas en todas las páginas, un video de fondo arriba, un carrusel, fotos subidas directo desde el celular, fuentes con muchos pesos y varios scripts de marketing instalados a lo largo de los años sin que nadie recuerde por qué.
Un ejemplo concreto: un botón de WhatsApp puede ser un simple enlace, que prácticamente no pesa nada, o un widget de terceros que descarga JavaScript en cada visita. Hablo más de esto en WhatsApp en landing pages.
¿Y la conversión?
La relación es real, pero indirecta. Quien llega desde Google o Instagram, en el celular, quiere entender la oferta y encontrar el contacto rápido. Cada fricción (contenido que tarda, un botón que no responde, un diseño que salta) es una oportunidad más de abandono. El rendimiento no reemplaza una oferta clara ni una página bien construida, como expliqué en landing page que convierte. Lo que hace es quitar obstáculos del camino.
Si quieres saber el efecto en tu caso, mídelo: registra los contactos antes y después de las mejoras, comparando periodos con el mismo tipo de tráfico.
Cómo trato el rendimiento en un proyecto
Mucho se decide ya en el diseño: cuántas fuentes, si la parte superior lleva video o imagen, qué scripts son indispensables. En el desarrollo, uso imágenes en tamaños y formatos adecuados, fuentes alojadas en el propio sitio con pocos pesos y el mínimo de JavaScript en la carga inicial.
Antes de la entrega, pruebo en PageSpeed Insights. Después del lanzamiento, sigo los datos de campo en Search Console cuando el sitio ya tiene tráfico suficiente para aparecer en ellos. Explico este trabajo con más detalle en la página de websites.
Si sientes que tu sitio es lento y quieres entender por dónde empezar, puedes enviarme la dirección desde la página de contacto.