La velocidad se percibe en varios momentos
Una web puede mostrar algo rápidamente y tardar en permitir una acción. También puede cargar todos sus elementos y mover el botón justo cuando una persona quiere pulsarlo. Hablar de velocidad requiere observar estos momentos por separado. El visitante necesita ver contenido, recibir respuesta a sus acciones y mantener una posición estable mientras lee o completa una tarea.
Los Core Web Vitals proporcionan métricas para aspectos concretos de esa experiencia. Son una parte del diagnóstico, no una evaluación completa del negocio o del diseño. Una página con buenos valores todavía puede tener textos confusos, información incompleta o un formulario que no entrega mensajes. El rendimiento debe integrarse con las pruebas funcionales y de usabilidad.
Qué miden LCP, INP y CLS
Según web.dev, LCP observa cuándo se presenta el elemento de contenido más grande relevante para la carga inicial; INP evalúa la capacidad de respuesta a las interacciones; y CLS cuantifica cambios inesperados de disposición. Los umbrales considerados buenos son LCP de hasta 2,5 segundos, INP de hasta 200 milisegundos y CLS de hasta 0,1. Para valorar la experiencia real se considera el percentil 75, separando móvil y escritorio.
Estos límites son referencias de calidad, no una promesa que pueda hacerse antes de medir el sitio en sus condiciones reales. Una imagen principal, un formulario y una aplicación con tablas tienen recorridos diferentes. La revisión debe identificar qué elemento explica cada problema y si la medición corresponde a la página que estás analizando o a una agrupación más amplia.
| Métrica | Pregunta práctica | Referencia de calidad |
|---|---|---|
| LCP | ¿Aparece pronto el contenido principal? | Hasta 2,5 segundos |
| INP | ¿Responde con agilidad a una interacción? | Hasta 200 milisegundos |
| CLS | ¿Se mantiene estable la composición? | Hasta 0,1 |
Distingue los datos reales de una prueba de laboratorio
Los datos de campo representan experiencias de usuarios en condiciones diferentes. Las pruebas de laboratorio permiten reproducir un escenario y buscar causas con herramientas de desarrollo. web.dev distingue ambos enfoques. Un informe puede mostrar que no hay suficientes datos de campo para una dirección; eso no significa que la página sea rápida o lenta, sino que falta esa evidencia.
Usa las pruebas de laboratorio para comparar cambios con condiciones similares. Si modificas a la vez la red, el dispositivo y el contenido, será difícil atribuir una diferencia. Para los datos de campo, observa tendencias con suficiente contexto. Un promedio aislado puede ocultar que un grupo de visitantes tiene problemas en determinados equipos o conexiones.
La imagen principal suele merecer atención primero
La guía de optimización de LCP de web.dev propone examinar el tiempo de respuesta, el descubrimiento y la descarga del recurso principal, además de su presentación. En una portada, revisa si el navegador puede descubrir pronto la imagen y si su tamaño corresponde a la pantalla. Aplicar carga diferida indiscriminadamente al contenido principal puede retrasar lo que se quiere mostrar primero.
Una solución visual atractiva puede usar fotografía con una selección cuidadosa de encuadres y tamaños. El archivo pensado para una pantalla amplia no tiene por qué ser el que descargue un teléfono. Reserva también el espacio de la imagen antes de que llegue. El trabajo de diseño y el tratamiento de los recursos deben coordinarse para que la composición conserve su presencia sin imponer una descarga innecesaria.
Revisa qué ocurre después de pulsar
INP considera la latencia de interacciones como clics, toques y teclado durante la visita. La documentación de web.dev explica que el trabajo prolongado en el hilo principal puede retrasar la respuesta visual. Un filtro que reorganiza muchos elementos o un código de terceros que ocupa el navegador merece una revisión específica cuando la interfaz parece quedarse detenida.
No todas las interacciones necesitan una animación compleja. Primero muestra una respuesta clara al usuario y separa las tareas que pueden esperar. Un formulario puede indicar que está procesando mientras el servidor responde. Evita activar varias bibliotecas para un comportamiento sencillo y revisa si los componentes que nadie usa se cargan de todos modos. El diagnóstico debe basarse en el recorrido real.
La estabilidad también se diseña
Las imágenes sin espacio reservado, los bloques insertados tarde y ciertos cambios de tipografía pueden desplazar el contenido. Una revisión de CLS ayuda a identificar desplazamientos inesperados; luego hay que comprender qué los causa. Un botón que cambia de lugar durante el contacto no es solo una irregularidad visual: afecta la acción que intenta realizar la persona.
Define proporciones para los recursos y estados de carga para los componentes dinámicos. Si un bloque puede crecer, decide dónde aparecerá sin interrumpir la lectura existente. Revisa también avisos y banners en pantallas pequeñas. Es útil grabar un recorrido desde la primera carga hasta el uso del menú y del formulario, porque una captura estática no muestra estos problemas.
La caché necesita reglas acordes al contenido
La documentación de MDN explica cómo el almacenamiento en caché reutiliza respuestas y reduce transferencias, según las directivas aplicadas. Los archivos estáticos versionados y una respuesta con datos personales no deben tratarse igual. Antes de activar una optimización general, distingue recursos públicos, páginas que cambian y contenido de sesión.
Después de actualizar un sitio, verifica que la nueva versión aparece y que los recursos antiguos no generan una mezcla de estilos o comportamientos. La caché es parte del despliegue, además de una herramienta de rendimiento. Conviene acordar cómo se invalidan recursos, qué puede conservar el navegador y qué controles se aplican en el servidor o en una red de distribución.
Conserva una rutina técnica después de publicar
Un sitio cambia cuando se incorporan fotografías, herramientas de medición, formularios o nuevos servicios. Cada incorporación puede afectar la carga y la interacción. Define una revisión periódica de las páginas importantes y repítela tras cambios significativos. No hace falta ejecutar todas las pruebas cada día: sí hace falta saber qué indicadores y funciones deben mantenerse.
El mantenimiento debería incluir actualización de dependencias cuando correspondan, respaldo, prueba de recuperación y comprobación de contacto. Conserva un registro de cambios para relacionar un problema con una modificación concreta. En OMNITEK abordamos el rendimiento como una condición del proyecto que se comprueba y se cuida. Una web conserva mejor su calidad cuando existe un responsable de su continuidad.
Fuentes y lecturas recomendadas
Documentación de referencia para profundizar. Las capacidades de cada producto pueden evolucionar.
Mantenimiento, mejora y soporte web
Correcciones, actualizaciones, rendimiento y evolución de sitios, tiendas y aplicaciones web existentes.
Conocer la solución
