6 errores de frontend que hunden tu puntuación de Lighthouse en 2026

Una puntuación de Lighthouse de 98 en tu portátil y de 41 en un teléfono real no es un error de medición. Es la distancia entre una prueba de laboratorio y el campo, y casi ningún equipo ve el segundo número hasta que un cliente le reenvía un informe de PageSpeed. Lighthouse es una auditoría sintética: carga la página una vez, en un dispositivo de gama media simulado y una red ralentizada, y le pone nota. Google se basa en otra cosa, los Core Web Vitals recogidos de usuarios reales de Chrome. Cuando ambos no coinciden, la producción es la que sienten tus usuarios.

Estos son los seis errores que vemos con más frecuencia cuando una app Next.js o React puntúa bien en desarrollo y mal en producción. Cada uno corresponde a una métrica concreta y a un peso concreto, así que corregir primero el correcto es la mayor parte del trabajo.

Cómo puntúa Lighthouse el rendimiento en realidad

La puntuación es una media ponderada de cinco métricas de laboratorio. En Lighthouse 12 el modelo actual asigna:

• Total Blocking Time (TBT): 30%, la métrica que más pesa
• Largest Contentful Paint (LCP): 25%
• Cumulative Layout Shift (CLS): 25%
• First Contentful Paint (FCP): 10%
• Speed Index: 10%

TBT y LCP juntos son el 55% del número. Mejorar una métrica que pesa el 30% mueve la puntuación tres veces más que mejorar una que pesa el 10%, y por eso "le quitamos 200ms al First Contentful Paint" a menudo no cambia nada visible en la nota. Una métrica falta en esa lista a propósito. Interaction to Next Paint (INP) sustituyó a First Input Delay como Core Web Vital el 12 de marzo de 2024, pero INP es una métrica de campo. En la puntuación de laboratorio de Lighthouse no aparece en absoluto. Puedes sacar 100 en laboratorio y aun así fallar el INP para cada usuario real.

Error 1: leer la puntuación de laboratorio como si fuera la de campo

El número verde de tu terminal es una única ejecución sintética. La señal de ranking de Google, y la evaluación en Search Console, vienen del Chrome User Experience Report, agregado en el percentil 75 de las visitas reales. Una página aprueba los Core Web Vitals solo cuando el 75% de las visitas se mantienen por debajo de 2,5s de LCP, por debajo de 200ms de INP y por debajo de 0,1 de CLS. Una puntuación de laboratorio de 95 con datos de campo en rojo es frecuente, y es el campo el que posiciona. Trata la puntuación de laboratorio como una herramienta de depuración que te dice dónde mirar, no como el resultado. El resultado está en los datos de campo.

Error 2: una head que bloquea el renderizado

Cada <script> síncrono y cada hoja de estilos en la head del documento impide al navegador pintar. Las etiquetas de terceros son el sospechoso habitual: analítica, banners de consentimiento, herramientas de A/B testing, widgets de chat, gestores de etiquetas, casi todos cargados de forma síncrona por defecto. Retrasan FCP y LCP, y su trabajo en el hilo principal infla el TBT. El arreglo es mecánico. Pon defer o async en cada script no crítico, carga las etiquetas de terceros después de la interacción o fuera del hilo principal, e incorpora inline solo el CSS crítico que necesita la primera pantalla. Las solicitudes que bloquean el renderizado son uno de los motivos más comunes por los que una página falla el LCP incluso después de optimizar las imágenes.

Error 3: el lazy-load en la imagen LCP

La regresión de LCP más común que encontramos es loading="lazy" en la imagen del hero. El lazy-load es correcto para todo lo que está bajo el pliegue y erróneo para el único elemento que define el LCP, porque el navegador retrasa justo la solicitud que la métrica está cronometrando. Los frameworks que hacen lazy-load por defecto lo esconden dentro de un componente, así que es fácil publicarlo sin darse cuenta. Marca la imagen LCP como eager, añade fetchpriority="high" y haz su preload. Luego confirma que está de verdad optimizada: un hero de 2MB servido en PNG fallará el LCP en una conexión lenta por mucha prioridad que le des a la solicitud.

Error 4: hidratar la página entera

El JavaScript es lo que mata las métricas. Cada kilobyte que envías se lee, se compila y se ejecuta en el hilo principal, y en un teléfono de gama media ese hilo va unas cuatro veces más lento que tu portátil. Enviar una página renderizada por completo en el cliente, o hidratar contenido estático que nunca necesitó interactividad, dispara el TBT (el 30% de la puntuación) y degrada el INP de campo en cada toque. Aquí es donde los Server Components, la hidratación parcial y una auditoría despiadada del bundle se pagan solos. Las librerías más pesadas las tratamos en el stack de la web inmersiva: la mayoría no pinta nada en una página de marketing.

Error 5: un layout que se mueve bajo el usuario

El CLS es el 25% de la puntuación y el más fácil de pasar por alto en desarrollo, porque los saltos de layout solo aparecen cuando los recursos cargan despacio. Tres culpables se repiten: imágenes y vídeo sin width y height explícitos (o una caja con aspect-ratio), web fonts que hacen swap y reflujo del texto, y contenido inyectado encima de contenido ya presente como banners, anuncios y embeds tardíos. Reserva espacio para todo lo que carga tarde. Configura font-display con criterio y haz el preload de los archivos de fuente. Un contenedor vacío con dimensiones fijas es mejor que un layout que salta tras el primer paint.

Error 6: probar en tu propia máquina

Lighthouse mobile simula un dispositivo de gama media en una red ralentizada. Tu máquina de desarrollo es un portátil M-series sobre la fibra de la oficina. Ambos pueden diferir en 50 puntos o más, y el campo está más cerca de la prueba ralentizada. Auditar en tu navegador de todos los días, con sesión iniciada y con extensiones activas, lo empeora: las extensiones inyectan scripts que cuentan contra la puntuación. Prueba como mínimo en una ventana de incógnito, o ejecuta Lighthouse en CI sobre un perfil de dispositivo fijo, para que el número sea comparable entre un commit y otro en vez de entre una máquina y otra.

Cómo evitar que las regresiones vuelvan

Los arreglos puntuales se degradan. Una página que hoy saca 95 vuelve al rojo a medida que salen funciones, se añaden scripts y crecen las imágenes. El arreglo que dura es un presupuesto impuesto en CI. Ejecuta Lighthouse CI en cada pull request con un presupuesto de rendimiento, una puntuación mínima o topes rígidos para TBT y LCP, y haz fallar la build cuando un cambio lo cruza. Acompaña ese control de laboratorio con monitorización de campo desde el Chrome User Experience Report o tus propios datos de usuarios reales: el laboratorio caza las regresiones antes del lanzamiento, el campo te dice lo que obtienen de verdad los usuarios. Para la versión procedimental, salir en verde desde el principio, mira cómo llevamos los Core Web Vitals al verde en Next.js.