Un sitio puede marcar 100 en Lighthouse y seguir sintiéndose lento. También puede obtener un puntaje mediocre en una prueba aislada y funcionar bien para la mayoría de sus usuarios. La diferencia está en qué mide cada herramienta y bajo qué condiciones. Lighthouse sirve para encontrar problemas. Los datos reales sirven para saber cuáles importan.
Lighthouse mide una situación controlada
Cuando ejecutamos Lighthouse, la prueba ocurre bajo condiciones definidas. Un dispositivo emulado. Una velocidad de red simulada. Una carga concreta de la página.
Eso es útil porque permite comparar cambios en un entorno relativamente estable. Pero un usuario real puede estar entrando desde otro teléfono, con otra conexión, desde otra ubicación y con extensiones, cookies, caché y recursos cargados de una sesión anterior. La experiencia real nunca es una sola.
Los Core Web Vitals miran otra cosa
Los Core Web Vitals intentan medir cómo se comporta el sitio para usuarios reales. Los tres indicadores principales son: LCP — cuánto tarda en aparecer el contenido principal. INP — cuánto tarda el sitio en responder cuando el usuario interactúa.
CLS — cuánto se mueve la interfaz mientras carga. No alcanzan para describir toda la experiencia de un sitio, pero sirven para detectar problemas que suelen afectar directamente la percepción de velocidad. Y lo importante es que Google puede evaluar estos datos a partir de uso real, no solamente de una prueba sintética.
Un LCP alto no siempre se arregla comprimiendo imágenes
La imagen principal suele ser el primer sospechoso. A veces lo es. Pero también puede haber un servidor tardando demasiado en generar la página, una fuente bloqueando el renderizado, CSS crítico llegando tarde o JavaScript retrasando la aparición del contenido. Optimizar solamente el peso de la imagen puede mejorar algunos milisegundos y dejar intacto el problema principal.
Conviene mirar toda la cadena: servidor → HTML → CSS → fuente → imagen → renderizado. La métrica muestra el síntoma. El trabajo es encontrar dónde empieza.
INP suele revelar deuda que no se ve al cargar
Un sitio puede abrir rápido y sentirse pesado apenas intentamos usarlo. Menús que responden tarde. Filtros que congelan la interfaz. Campos que tardan en reaccionar.
Botones que disparan demasiado JavaScript. INP expone bastante bien ese tipo de problema. Y muchas veces el culpable no es nuestro código principal. Puede ser un script de analítica, un widget externo, un chat, una herramienta de marketing o varios plugins ejecutando trabajo en el mismo hilo.
Cada dependencia parece pequeña por separado. Juntas pueden convertir una interacción simple en una espera visible.
CLS suele ser una suma de pequeñas decisiones
Una imagen sin dimensiones reservadas. Una fuente que cambia el ancho del texto al cargar. Un banner que aparece después del contenido. Un componente que inyecta espacio cuando termina de inicializarse.
Nada de eso parece grave de forma aislada. Pero si la interfaz se mueve mientras el usuario intenta leer o hacer clic, la experiencia se siente inestable. La solución no suele requerir una técnica sofisticada. Muchas veces alcanza con reservar espacio correctamente y evitar que elementos tardíos reorganicen toda la página.
Los scripts de terceros merecen sospecha
Una web puede estar muy bien desarrollada y aun así cargar: analítica, píxeles publicitarios, mapas, reproductores, chats, formularios embebidos y herramientas de seguimiento. Todo eso compite por los mismos recursos. Por eso una auditoría de performance que solamente mira nuestro bundle se queda corta.
También hay que preguntar:
¿Qué estamos cargando que realmente necesita ejecutarse en este momento?
Algunas cosas pueden retrasarse. Otras pueden cargarse después de una interacción. Y algunas probablemente no deberían estar ahí.
No optimizar para el número
Perseguir un 100 puede llevar a dedicar horas a mejoras que ningún usuario va a percibir. La prioridad debería estar en los problemas que afectan una cantidad significativa de visitas. Si el sitio tiene un LCP malo para usuarios móviles reales, eso importa.
Si Lighthouse baja dos puntos porque detecta una recomendación menor en una página interna casi sin tráfico, probablemente no sea urgente. Performance también es priorización.
Medir antes y después
Una optimización sin medición termina siendo una opinión. Antes de tocar algo conviene tener una referencia. Después del cambio hay que comprobar si realmente mejoró. Y cuando hablamos de datos de campo, hay que recordar que los resultados no necesariamente aparecen de inmediato. Hace falta acumular nuevas visitas para que la tendencia cambie.
La secuencia debería ser simple: medir → identificar → cambiar → volver a medir. No instalar cinco plugins de optimización y esperar lo mejor.
En WordPress, la causa puede estar bastante lejos del frontend
En WordPress es fácil concentrarse solamente en CSS y JavaScript. Pero un LCP pobre también puede empezar con un TTFB alto. Consultas lentas. Plugins ejecutando trabajo innecesario.
También puede haber APIs externas bloqueando PHP, un autoload inflado, caché mal configurada o recursos generados dinámicamente que podrían servirse de forma directa. Si el servidor tarda demasiado en entregar el primer byte, el navegador ya empieza la carrera desde atrás. La optimización tiene que cubrir toda la ruta.
El objetivo es que el sitio se sienta rápido
Core Web Vitals, Lighthouse y PageSpeed Insights son instrumentos, no el producto. Sirven para encontrar dónde mirar y para comprobar si un cambio tuvo efecto. Pero el resultado que importa sigue siendo bastante simple: la página aparece rápido, no salta mientras carga y responde cuando alguien intenta usarla.
El puntaje orienta el diagnóstico. La validación termina cuando el cambio mejora la experiencia real y los datos de campo lo confirman.