Casi todos los diagnósticos de velocidad empiezan igual: abres la web en el portátil de la oficina, con fibra y una pantalla grande, y va como un tiro. El informe de Lighthouse sale en verde. Entonces llega la analítica y dice que la gente se va antes de leer nada.
No hay contradicción. Hay dos datos distintos midiendo dos cosas distintas.
Laboratorio y campo no son el mismo número
Lighthouse es una prueba controlada: un dispositivo simulado, una red simulada y una página sin cookies de terceros. Sirve para reproducir problemas y comparar versiones, y es la herramienta que usamos cuando tocamos código. Pero no es lo que ve tu cliente.
Los Core Web Vitals que Google tiene en cuenta salen del Chrome User Experience Report: datos reales de usuarios de Chrome que han aceptado compartir su telemetría. Redes móviles a media cobertura, móviles de gama media, extensiones, banners de cookies, todo eso entra en la medida. Y es la métrica que aparece en el informe de Core Web Vitals de Search Console.
La consecuencia práctica es sencilla: cuando un dato de laboratorio y uno de campo se contradicen, manda el de campo. Es el que ven los clientes y el que ve Google.
El percentil 75 es el que decide
Hay tres umbrales que conviene tener a mano:
- LCP (Largest Contentful Paint), el elemento principal de la página: por debajo de 2,5 s.
- INP (Interaction to Next Paint), la respuesta a la primera interacción del usuario: por debajo de 200 ms. Sustituyó a First Input Delay en marzo de 2024 y es más exigente, porque mide toda la interacción y no solo el retardo de entrada.
- CLS (Cumulative Layout Shift), el baile de la página al cargar: por debajo de 0,1.
Lo importante no es el umbral, es cómo se agrega. Google evalúa esos números en el percentil 75: el valor por debajo del cual se queda el 75% de las visitas. Si tu media es de 2 s pero el cuarto de usuarios más lento vive en 4,5 s, estás fuera. Y ese cuarto suele ser el que compra desde el móvil.
Lo que de verdad trae resultados
Por orden de impacto real, después de mirar muchos proyectos:
- Imágenes. Casi siempre son el elemento LCP. Formatos modernos, tamaños correctos,
srcsetcon anchos de verdad y la imagen principal cargando antes que las de abajo. Un hero de 2 MB servido a un móvil de 400 px de ancho es el problema más común y el más barato de resolver. - Terceros. Un chat, un píxel, dos etiquetas y un tag manager pueden costar más que toda tu aplicación. Si no sabes qué hace un script, quítalo o cárgalo después de la interacción.
- Lo que se ejecuta antes de pintar. Traducción: fuentes que bloquean, CSS enorme, frameworks enteros para una página estática. Cada milisegundo de JavaScript en el hilo principal es un milisegundo que no responde a un toque.
Nada de esto es exótico. La diferencia está en medir con datos de campo, aceptar que el percentil 75 no perdona y tratar el rendimiento como parte del diseño y no como una revisión de última hora antes de publicar.