Cómo optimizar una web para conseguir 100 en Lighthouse en 2026 (y por qué 100 no debería ser tu objetivo)

Conseguir un 100/100 en Lighthouse tiene algo de adictivo.

Optimizas una imagen.

96.

Eliminas un script.

98.

Ajustas una fuente.

99.

Encuentras 40 KB de JavaScript que ni siquiera necesitabas.

100.

Y sí: ver ese número tiene su gracia.

Pero hay un problema.

Una web puede sacar 100 en Lighthouse y seguir ofreciendo una experiencia mediocre a parte de sus usuarios.

También puede tener un 90 y ser perfectamente rápida para sus visitantes.

Por eso, en 2026, optimizar rendimiento web no consiste en perseguir una cifra verde. Consiste en entender qué está experimentando realmente el usuario, qué recursos están bloqueando la página y qué trabajo está haciendo el navegador.

En esta guía vamos a recorrer el proceso completo: Lighthouse, Core Web Vitals, CrUX, LCP, INP, CLS, JavaScript, imágenes, fuentes, scripts de terceros, Speculation Rules y RUM.

Y, sobre todo, vamos a separar las optimizaciones que realmente importan de los trucos que quedan muy bien en una captura de PageSpeed.

1. Primero: ¿qué significa realmente "100 en Lighthouse"?

Lighthouse es una herramienta de auditoría que analiza una página bajo unas condiciones controladas y genera diferentes categorías, entre ellas Performance, Accessibility, Best Practices y SEO.

La puntuación de Performance, de 0 a 100, se calcula a partir de diferentes métricas de laboratorio.

Por eso Lighthouse no está diciendo que el 100 % de tus usuarios experimente esa velocidad.

Las condiciones de la prueba importan: CPU, red, dispositivo, caché y otros factores pueden cambiar considerablemente los resultados.

Esto obliga a separar dos preguntas:

> ¿Qué tan bien funciona esta página en una prueba controlada?

y:

> ¿Qué experiencia están teniendo realmente mis usuarios?

La primera se responde con herramientas de laboratorio como Lighthouse y Chrome DevTools.

La segunda requiere datos de campo como CrUX o RUM.

Y aquí está una de las ideas más importantes de todo este artículo:

100/100 es un objetivo de laboratorio. Las Core Web Vitals de usuarios reales son un objetivo de producto.

2. Las Core Web Vitals que importan en 2026

Las tres Core Web Vitals principales son:

• LCP (Largest Contentful Paint) → rendimiento de carga percibido.
• INP (Interaction to Next Paint) → capacidad de respuesta.
• CLS (Cumulative Layout Shift) → estabilidad visual.

Los umbrales oficiales de Google para considerar una experiencia "Good" son:

Para las Core Web Vitals, Google utiliza principalmente el percentil 75 (p75) de los datos de usuarios reales.

Eso cambia bastante la forma de pensar sobre rendimiento.

No necesitas que absolutamente todas las visitas tengan un LCP de un segundo.

Necesitas que una proporción suficientemente grande de usuarios tenga una experiencia rápida, estable y con buena capacidad de respuesta.

¿Y por qué no apuntar a valores todavía mejores?

Puedes hacerlo.

De hecho, cuanto mejores sean tus métricas, mejor.

Pero no confundas:

"excelente"

con:

"umbral oficial de Google".

LCP inferior a 1,2 segundos o INP inferior a 100 ms pueden ser objetivos internos muy ambiciosos, pero no son los límites oficiales de "Good" de Core Web Vitals.

El objetivo de 2,5 s para LCP, 200 ms para INP y 0,1 para CLS es el que debemos utilizar como referencia oficial.

3. LCP: el elemento que decide cuándo parece que tu página ha cargado

LCP mide cuánto tarda en renderizarse el elemento de contenido más grande visible dentro del viewport.

En muchas páginas suele ser:

• una imagen Hero;
• un banner;
• un bloque de texto grande;
• un título;
• un elemento visual principal.

Por eso una página puede tener un servidor rápido y aun así presentar un LCP mediocre.

Imagina este recorrido:

HTML recibido
      ↓
CSS descargado
      ↓
Recursos descubiertos
      ↓
Recurso LCP descargado
      ↓
Recurso decodificado
      ↓
Elemento renderizado
      ↓
LCP

El objetivo no es simplemente "tener una imagen pequeña".

El objetivo es conseguir que el recurso que determina el LCP sea descubierto, descargado y renderizado lo antes posible.

4. El error clásico: optimizar la imagen pero no su descubrimiento

Supongamos que tienes:

<img
  src="/hero.webp"
  width="1920"
  height="1080"
  alt="Nuestra plataforma"
/>

Has convertido un JPEG de 900 KB en un WebP de 120 KB.

Perfecto.

Pero si el navegador descubre esa imagen tarde porque está escondida detrás de JavaScript o de una cadena de recursos bloqueantes, todavía puedes tener un LCP mediocre.

Aquí entra en juego Fetch Priority.

Para una imagen que realmente sea el elemento LCP:

<img
  src="/hero.webp"
  width="1920"
  height="1080"
  alt="Nuestra plataforma"
  fetchpriority="high"
/>

fetchpriority="high" es una pista para que el navegador dé mayor prioridad al recurso. No es una orden absoluta, pero puede ayudar cuando la prioridad automática del navegador no coincide con lo que realmente importa para la experiencia.

No pongas fetchpriority="high" a todas las imágenes.

Si todo es prioritario, nada es prioritario.

La idea es identificar cuál es realmente el recurso crítico.

5. Imágenes: menos bytes, pero también mejores dimensiones

Un error frecuente es servir una imagen enorme y confiar únicamente en WebP o AVIF.

Una imagen de:

3840 × 2160

puede seguir siendo innecesariamente pesada aunque esté comprimida.

Para una imagen que se muestra aproximadamente a:

800 × 450

no tiene sentido descargar sistemáticamente una versión 4K.

Utiliza imágenes responsivas:

<img
  src="/images/hero-800.webp"
  srcset="
    /images/hero-480.webp 480w,
    /images/hero-800.webp 800w,
    /images/hero-1200.webp 1200w
  "
  sizes="100vw"
  width="1200"
  height="675"
  alt="Descripción de la imagen"
/>

Y recuerda:

• imágenes críticas → cargar pronto;
• imágenes fuera del viewport → lazy loading;
• dimensiones explícitas → evitar CLS;
• formatos modernos → reducir transferencia;
• resolución adecuada → no enviar píxeles innecesarios.

La optimización real consiste en enviar exactamente lo que el usuario necesita, cuando lo necesita.

6. CLS: cuando la web "baila" delante del usuario

Seguro que has visto este problema.

Abres una página.

Empiezas a leer.

Y de repente aparece una imagen, un banner o un componente y todo el contenido se desplaza.

Eso es exactamente el tipo de experiencia que CLS intenta medir.

El error típico es:

<img src="/producto.webp" alt="Producto" />

sin reservar espacio para la imagen.

Mejor:

<img
  src="/producto.webp"
  width="1200"
  height="800"
  alt="Producto"
/>

o utilizar un contenedor con una relación de aspecto conocida:

.product-image {
  aspect-ratio: 3 / 2;
}

También debes prestar atención a:

• imágenes;
• vídeos;
• iframes;
• banners;
• anuncios;
• contenido insertado dinámicamente;
• fuentes web;
• componentes que cambian de tamaño después de cargar.

¿El objetivo es CLS = 0?

No necesitas obsesionarte con eso.

El umbral oficial de "Good" es ≤ 0,1.

Evidentemente, si puedes acercarte a 0 sin sacrificar funcionalidad, mejor.

Pero un CLS de 0,02 no es malo simplemente porque no sea exactamente 0.

7. INP: la métrica que obliga a tomarse JavaScript en serio

INP mide cómo responde la página a las interacciones del usuario durante su ciclo de vida.

Por ejemplo:

• abrir un menú;
• pulsar un botón;
• escribir en un formulario;
• añadir un producto al carrito;
• abrir un modal;
• cambiar filtros;
• interactuar con una aplicación React.

Una página puede cargar rapidísimo y, sin embargo, sentirse lenta cuando el usuario empieza a utilizarla.

Ese es el territorio de INP.

El objetivo oficial de "Good" es:

≤ 200 ms.

8. El enemigo de INP: el trabajo excesivo en el hilo principal

El navegador tiene que hacer muchas cosas en el main thread:

JavaScript
↓
Style
↓
Layout
↓
Paint
↓
Composite

Si JavaScript ocupa el hilo principal durante demasiado tiempo, el navegador no puede responder inmediatamente a las interacciones.

Una tarea de JavaScript que tarda más de 50 ms se considera una Long Task.

Pero hay un matiz importante:

50 ms no es el umbral de "Good" para INP.

Es un concepto útil para diagnosticar trabajo que puede bloquear el hilo principal.

Por ejemplo:

Usuario pulsa botón
       ↓
JS pesado ejecutándose
       ↓
70 ms
       ↓
el navegador puede continuar
       ↓
se pinta el resultado

Ese retraso puede terminar afectando a INP.

Por eso, cuando tengas un INP malo, no empieces automáticamente a tocar CSS.

Abre Chrome DevTools → Performance.

Graba la interacción.

Busca:

• Long Tasks;
• event handlers pesados;
• recálculos de estilo;
• layouts costosos;
• renders innecesarios;
• grandes cantidades de JavaScript;
• tareas de terceros.

9. Next.js y Astro: menos JavaScript también es una estrategia de rendimiento

Aquí es donde la arquitectura importa.

En Next.js, no todo necesita convertirse en un Client Component.

Si un componente puede renderizarse en el servidor, mantenerlo fuera del bundle del cliente puede reducir JavaScript que el navegador tiene que descargar, parsear y ejecutar.

En Astro, la arquitectura de islas permite llevar todavía más lejos esta idea:

<Header />

<ProductGrid />

<Search client:load />

<Cart client:load />

La página puede entregar HTML directamente y añadir JavaScript únicamente donde existe una necesidad real de interactividad.

Esto no significa:

> "Astro siempre es más rápido que Next.js."

Ni:

> "Next.js es lento."

Significa algo mucho más útil:

la cantidad de JavaScript que envías al navegador debe corresponder con la interacción que realmente necesita el usuario.

Y esto es especialmente relevante en 2026: Astro 7 incorpora un nuevo compilador de .astro escrito en Rust y utiliza Vite 8, cuyo bundler Rolldown está escrito en Rust. El equipo de Astro publica mejoras importantes de tiempo de build en sus benchmarks, aunque esos números no deben interpretarse como una garantía de rendimiento en cada proyecto.

10. Scripts de terceros: el invitado que llega con una maleta de 40 MB

Analytics.

Tag Manager.

Chat.

Heatmaps.

Publicidad.

A/B testing.

Vídeos.

Pixels.

Widgets.

Cada herramienta puede parecer pequeña.

El problema aparece cuando juntas diez.

Los scripts de terceros pueden añadir:

• descargas adicionales;
• conexiones a otros dominios;
• ejecución de JavaScript;
• tareas largas;
• acceso al DOM;
• consumo de CPU;
• trabajo durante la carga;
• complejidad de mantenimiento.

Por eso, una de las optimizaciones más efectivas es brutalmente sencilla:

elimina lo que no necesitas.

Antes de pensar en async, defer, Web Workers o Partytown, pregunta:

> ¿Este script aporta suficiente valor como para justificar su coste?

Si la respuesta es no:

delete script;

Probablemente sea la optimización más rápida de toda la guía.

11. Carga los terceros después del contenido crítico

Si un script no es necesario para renderizar la interfaz inicial, evita convertirlo en parte de la ruta crítica.

Dependiendo del caso puedes utilizar:

<script async src="https://example.com/analytics.js"></script>

o:

<script defer src="/scripts/non-critical.js"></script>

También puedes retrasar determinados scripts hasta que:

• la página haya terminado de cargar;
• el usuario haya interactuado;
• el componente sea visible;
• realmente exista una necesidad de ejecutar ese código.

La estrategia correcta depende del script.

Un sistema de analytics crítico para determinadas mediciones no tiene exactamente las mismas necesidades que un widget de chat que nadie abre.

12. ¿Y Partytown?

Partytown es una herramienta interesante porque permite ejecutar determinados scripts de terceros dentro de un Web Worker en lugar del hilo principal.

Conceptualmente:

ANTES

Main Thread
├── Tu aplicación
├── React
├── Analytics
├── Ads
└── Tracker


DESPUÉS

Main Thread
├── Tu aplicación
└── UI

Web Worker
├── Analytics
├── Tracker
└── Third-party scripts

Esto puede ser útil cuando un tercero consume mucho tiempo de CPU.

Pero aquí hay una advertencia importante:

Partytown no es una bala de plata.

Los Web Workers no tienen acceso directo al DOM, y Partytown tiene que proporcionar mecanismos de comunicación entre el worker y el hilo principal.

Algunos scripts funcionan muy bien.

Otros dependen demasiado del DOM o de APIs del navegador y pueden presentar incompatibilidades o costes adicionales.

Por eso el proceso correcto es:

medir
  ↓
identificar el script problemático
  ↓
probar Partytown
  ↓
comprobar funcionalidad
  ↓
medir de nuevo

Nunca:

INP malo → instalar Partytown → problema solucionado

13. Fuentes: el pequeño archivo que puede convertirse en una gran cadena crítica

Las fuentes también forman parte de la experiencia de carga.

Una mala estrategia puede generar:

HTML
 ↓
CSS
 ↓
fuente
 ↓
texto

y aumentar el tiempo necesario para mostrar correctamente el contenido.

Buenas prácticas:

• utilizar WOFF2;
• eliminar pesos que realmente no utilizas;
• hacer subsetting cuando sea apropiado;
• evitar cargar cinco variantes de una fuente para utilizar únicamente dos;
• utilizar font-display de forma consciente;
• precargar únicamente fuentes críticas;
• evitar precargar fuentes que nunca aparecen en el viewport inicial.

Font subsetting

Si solamente necesitas caracteres latinos, no tiene demasiado sentido enviar una fuente gigantesca con glifos que jamás aparecerán en tu web.

Pero cuidado:

subsetting no significa eliminar caracteres a ciegas.

Si tu web soporta español, asegúrate de conservar caracteres como:

á é í ó ú ü ñ

Una fuente de 20 KB que rompe una palabra en producción no es una optimización.

Es un bug.

14. Speculation Rules: navegación que puede sentirse instantánea

La Speculation Rules API permite indicar al navegador qué páginas podría visitar el usuario próximamente.

Por ejemplo:

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/logout" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

Con moderate, el navegador puede iniciar la especulación cuando detecta una intención más clara del usuario.

Esto puede hacer que determinadas navegaciones se sientan prácticamente instantáneas.

Pero aquí hay otra trampa:

no prerenderices absolutamente todo sin pensar.

Prerenderizar páginas tiene un coste de:

• CPU;
• memoria;
• ancho de banda;
• ejecución potencial de recursos;
• trabajo del servidor.

Además, páginas con acciones con efectos secundarios necesitan un tratamiento especialmente cuidadoso.

La recomendación práctica es empezar de forma conservadora, medir y aumentar progresivamente la agresividad cuando exista una buena señal de que el usuario realmente va a visitar la página.

15. No confundas prefetch con prerender

Son conceptos diferentes.

Prefetch

El navegador puede empezar a descargar recursos de una futura navegación.

Prerender

El navegador puede llegar mucho más lejos y preparar la página futura como si estuviera abierta en segundo plano.

Por eso prerender puede producir ganancias mucho mayores.

Pero también tiene un coste mayor.

La regla de oro es:

> Cuanto más agresiva sea tu especulación, más importante es que tengas buenas señales sobre cuál será la siguiente navegación.

No prometas "0 ms".

Una navegación prerenderizada puede sentirse prácticamente instantánea, pero el resultado depende de si la especulación se produjo, cuánto se completó antes del clic y qué trabajo requiere la página al activarse.

16. scheduler.yield(): cede el hilo cuando tienes trabajo pesado

Cuando tienes una tarea JavaScript grande, dividirla puede permitir que el navegador atienda otras tareas antes de continuar.

En navegadores compatibles, scheduler.yield() ofrece una API específica para ceder el control al hilo principal:

async function processLargeDataset(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);

    if (
      i % 100 === 0 &&
      globalThis.scheduler?.yield
    ) {
      await scheduler.yield();
    }
  }
}

La idea es sencilla:

Trabajo
 ↓
ceder
 ↓
el navegador puede responder
 ↓
continuar trabajo
 ↓
ceder
 ↓
...

Pero no conviertas cada bucle en una llamada a scheduler.yield().

Primero mide.

Además, no todos los navegadores ofrecen exactamente el mismo soporte, por lo que conviene utilizar una estrategia de mejora progresiva o un fallback cuando sea necesario.

17. Network Information: cuidado con optimizar a ciegas

Las APIs relacionadas con información de red pueden proporcionar señales sobre la conexión y determinadas preferencias del usuario.

Por ejemplo:

const connection = navigator.connection;

if (connection?.saveData) {
  // Evitar recursos no esenciales
}

Esto puede ser útil para:

• vídeos de fondo;
• animaciones pesadas;
• recursos secundarios;
• contenido que no sea necesario inmediatamente.

Pero no construyas toda tu estrategia de rendimiento basándote en:

"WiFi = rápido"
"5G = rápido"
"4G = lento"

La realidad es mucho más compleja.

Una conexión 5G con mala cobertura puede ser peor que una conexión Wi-Fi estable.

Por eso las señales de red deben complementar, no sustituir, una estrategia de carga eficiente.

18. El gran error: optimizar solo para Lighthouse

Supongamos:

Lighthouse: 100

Fantástico.

Ahora un usuario entra desde:

• un móvil de gama baja;
• una red congestionada;
• una CPU lenta;
• una conexión con alta latencia.

Y obtiene:

LCP: 4,1 s
INP: 380 ms
CLS: 0,18

¿Tu web es rápida?

Para ese usuario, no.

Aquí entra CrUX (Chrome UX Report).

CrUX utiliza datos agregados de usuarios reales de Chrome y proporciona métricas de experiencia real. Herramientas como PageSpeed Insights pueden mostrar datos de CrUX junto con los resultados de Lighthouse.

Los datos de campo no son una instantánea de "lo que ocurre ahora mismo": se agregan durante ventanas de datos, por lo que debes interpretar las tendencias con contexto.

19. Laboratorio vs campo: qué herramienta usar para cada problema

Piensa en dos cajas.

🧪 Laboratorio

Lighthouse / DevTools

Sirve para:

• desarrollar;
• reproducir problemas;
• encontrar oportunidades;
• comparar cambios;
• analizar waterfalls;
• inspeccionar JavaScript;
• estudiar Long Tasks.

🌍 Campo

CrUX / RUM / Search Console

Sirve para:

• conocer la experiencia real;
• detectar dispositivos lentos;
• observar tendencias;
• segmentar usuarios;
• medir regresiones después de desplegar.

La combinación es mucho más potente:

Lighthouse
    +
DevTools
    +
CrUX
    +
RUM
    =
visión real del rendimiento

20. RUM: deja de adivinar qué sienten tus usuarios

Si tienes tráfico suficiente, medir Core Web Vitals directamente en producción puede darte información que una prueba de laboratorio nunca tendrá.

La librería web-vitals permite capturar métricas como:

import { onCLS, onINP, onLCP } from "web-vitals";

function sendToAnalytics(metric) {
  navigator.sendBeacon(
    "/analytics",
    JSON.stringify(metric)
  );
}

onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);

La clave no es almacenar únicamente una media.

Para Core Web Vitals interesa observar la distribución, especialmente el p75.

Por ejemplo:

LCP p75: 1,8 s     → Good
INP p75: 145 ms    → Good
CLS p75: 0,04      → Good

Esto es muchísimo más útil que decir:

"Mi LCP medio es 1,1 s."

Una media puede ocultar una cantidad importante de usuarios con una experiencia mucho peor.

21. El p75 importa más que tu mejor usuario

Imagina que tienes:

100 usuarios

80 → LCP 1,2 s
20 → LCP 4,5 s

Tu web puede parecer espectacular en muchos dispositivos.

Pero existe un grupo considerable de usuarios que está esperando muchísimo más.

Por eso el percentil 75 resulta tan útil.

Google utiliza el p75 para evaluar las Core Web Vitals.

Y si quieres ir un paso más allá, también puedes monitorizar p90 o p95 internamente para descubrir problemas que afectan a usuarios con dispositivos o conexiones especialmente desfavorables.

22. Google no te va a regalar la primera posición por sacar 100

Este punto merece una sección propia porque existe mucha confusión.

Core Web Vitals forman parte de las señales utilizadas por los sistemas de posicionamiento de Google.

Pero:

100 Lighthouse
≠
#1 en Google

Y tampoco:

Core Web Vitals Good
=
#1 en Google

Google deja claro que la experiencia de página es solo una parte de un sistema de ranking mucho más amplio.

La relevancia del contenido, la calidad, la intención de búsqueda, la autoridad, la utilidad y muchos otros factores siguen importando.

Por eso una página con contenido excelente y un rendimiento de 94 puede superar perfectamente a otra con 100 y contenido mediocre.

No optimices para el número. Optimiza para el usuario.

23. Entonces, ¿cómo intentamos conseguir un 100?

Ahora sí.

Si quieres perseguir ese 100 porque estás construyendo una web extremadamente optimizada, este sería nuestro orden de ataque.

1. Reduce el trabajo crítico

Pregúntate:

> ¿Qué necesita realmente el usuario para ver y utilizar la primera pantalla?

Todo lo demás puede esperar.

2. Optimiza el LCP

Identifica exactamente cuál es el elemento LCP.

Después analiza:

• TTFB;
• descubrimiento del recurso;
• prioridad;
• tamaño;
• formato;
• compresión;
• caché;
• renderizado.

3. Elimina JavaScript innecesario

Especialmente:

• librerías que apenas utilizas;
• componentes hidratados sin necesidad;
• dependencias duplicadas;
• polyfills innecesarios;
• scripts de terceros.

4. Protege el main thread

Busca Long Tasks.

Divide trabajo pesado.

Evita renders innecesarios.

Reduce JavaScript.

5. Elimina CLS

Reserva espacio para:

• imágenes;
• vídeos;
• embeds;
• anuncios;
• contenido dinámico.

6. Optimiza fuentes

Utiliza WOFF2.

Reduce pesos.

Haz subsetting.

Preload solo cuando realmente aporte.

7. Audita terceros

Haz una lista de cada:

analytics
chat
pixel
heatmap
A/B testing
ads
widget
embed

y pregunta:

> ¿Lo necesitamos?

8. Mide en producción

No cierres el proyecto después de conseguir 100 en Lighthouse.

Despliega.

Mide CrUX/RUM.

Observa los p75.

Y vuelve a optimizar.

24. Una metodología que funciona de verdad

Cuando optimizamos una web, no hacemos veinte cambios a la vez.

Utilizamos un ciclo:

MEDIR
  ↓
IDENTIFICAR
  ↓
CAMBIAR
  ↓
MEDIR
  ↓
COMPARAR
  ↓
CONSERVAR O REVERTIR

Por ejemplo:

Problema

LCP = 3,2 s.

Investigación

El elemento LCP es la imagen Hero.

Waterfall

La imagen se descubre 1,1 s después de comenzar la navegación.

Cambio

• optimizar imagen;
• mejorar descubrimiento;
• fetchpriority="high";
• eliminar recurso que bloqueaba la carga.

Resultado

LCP = 2,0 s.

Eso es una optimización.

No:

> "Hemos añadido preload porque lo recomienda un tutorial."

La diferencia es enorme.

Una optimización debe resolver un cuello de botella medido.

25. Performance Budget: evita volver a romper lo que ya arreglaste

Una web optimizada puede degradarse rápidamente.

Un desarrollador añade:

• una librería;
• un widget;
• un vídeo;
• una fuente;
• un tracker.

Y seis meses después:

100 → 96 → 91 → 87

Por eso conviene establecer presupuestos de rendimiento.

Por ejemplo:

JavaScript inicial: < X KB
CSS inicial: < X KB
Imagen LCP: < X KB
Número de terceros: < X
LCP laboratorio: < X s
INP laboratorio: < X ms
CLS: < X

No son valores universales.

Cada proyecto debe establecer sus propios límites.

Lo importante es que una regresión sea visible antes de llegar a producción.

26. La arquitectura también es una optimización

Es fácil pensar que rendimiento significa:

comprimir imagen

Pero la arquitectura puede tener un impacto muchísimo mayor.

Una página que entrega HTML útil desde el servidor puede evitar trabajo que una aplicación completamente client-side tendría que realizar en el navegador.

Una arquitectura con:

• renderizado en servidor;
• caching;
• CDN;
• imágenes optimizadas;
• JavaScript mínimo;
• streaming cuando corresponda;
• componentes interactivos aislados;

puede reducir muchísimo el trabajo inicial.

Por eso la pregunta correcta no es:

> "¿Cómo hago que este JavaScript sea 10 % más rápido?"

A veces es:

> "¿Por qué estamos enviando este JavaScript al navegador?"

27. Astro 7 en 2026: el rendimiento no termina en el navegador

Si tu proyecto utiliza Astro, hay una razón adicional para prestar atención a la arquitectura de build.

Astro 7, lanzado en junio de 2026, introdujo un compilador de .astro reescrito en Rust, un pipeline Rust para Markdown/MDX, un motor de renderizado basado en colas y Vite 8 con Rolldown.

Además, Astro 7.1, publicado en julio de 2026, añadió mejoras como mayor control sobre CSP, personalización de URLs de paginación, posibilidad de ejecutar varios servidores de desarrollo y mejoras de memoria para grandes colecciones de contenido.

Esto importa porque una buena estrategia de rendimiento tiene dos caras:

BUILD TIME
    +
RUNTIME PERFORMANCE
    =
DEVELOPER + USER EXPERIENCE

Un build más rápido no hace automáticamente que una página tenga mejor LCP.

Y una página con excelente LCP no significa que tu pipeline de CI sea eficiente.

Son problemas distintos.

28. ¿Astro o Next.js para rendimiento?

No existe un ganador universal.

Astro destaca especialmente cuando una gran parte del sitio puede ser HTML y solo algunas zonas necesitan interactividad.

Next.js ofrece una arquitectura muy potente para aplicaciones React, especialmente cuando necesitas interacción compleja, Server Components, streaming y un ecosistema React completo.

La pregunta importante es:

> ¿Qué trabajo necesita hacer el navegador para esta página concreta?

Si una landing necesita 15 KB de JavaScript, no necesitas enviar 500 KB porque "la aplicación utiliza React".

Si una aplicación tiene interacción compleja, tampoco deberías sacrificar arquitectura únicamente para conseguir una captura de Lighthouse bonita.

El rendimiento es una propiedad del sistema completo.

29. Las cinco optimizaciones que más veces merece la pena investigar

Si tuviera que abrir un proyecto desconocido y buscar problemas de rendimiento, empezaría aquí:

🥇 1. Elemento LCP

¿Qué es?

¿Cómo se descubre?

¿Cuánto pesa?

¿Se carga demasiado tarde?

🥈 2. JavaScript

¿Cuánto se descarga?

¿Cuánto se ejecuta?

¿Qué parte es realmente necesaria?

🥉 3. Terceros

¿Cuántos scripts hay?

¿Cuánto trabajo generan?

¿Son realmente necesarios?

4. Imágenes

¿Están correctamente dimensionadas?

¿Se sirven en formatos adecuados?

¿Se están cargando imágenes fuera del viewport demasiado pronto?

5. Layout

¿La interfaz cambia de tamaño después de cargar?

¿Hay imágenes, fuentes o componentes que no reservan espacio?

30. Checklist de rendimiento para 2026

Antes de considerar una web realmente optimizada:

LCP

• [ ] Identificar el elemento LCP real.
• [ ] Reducir TTFB cuando sea un cuello de botella.
• [ ] Optimizar la imagen o contenido LCP.
• [ ] Mejorar su descubrimiento.
• [ ] Utilizar Fetch Priority cuando aporte valor.
• [ ] Evitar recursos críticos innecesarios.

INP

• [ ] Medir interacciones reales.
• [ ] Buscar Long Tasks.
• [ ] Reducir JavaScript.
• [ ] Dividir trabajo pesado.
• [ ] Evitar renders innecesarios.
• [ ] Auditar scripts de terceros.

CLS

• [ ] Dimensiones explícitas para imágenes.
• [ ] Espacio reservado para embeds.
• [ ] Evitar insertar contenido inesperadamente.
• [ ] Revisar fuentes.
• [ ] Revisar componentes dinámicos.

Recursos

• [ ] Imágenes optimizadas.
• [ ] Imágenes responsivas.
• [ ] WOFF2.
• [ ] Fuentes subseteadas cuando corresponda.
• [ ] CSS inicial razonable.
• [ ] JavaScript mínimo.

Terceros

• [ ] Eliminar herramientas innecesarias.
• [ ] Cargar scripts de forma no bloqueante.
• [ ] Retrasar lo no esencial.
• [ ] Medir antes y después.
• [ ] Evaluar Web Workers/Partytown solo cuando tengan sentido.

Navegación

• [ ] Evaluar Speculation Rules.
• [ ] Utilizar reglas conservadoras cuando sea apropiado.
• [ ] Evitar prerenderizar páginas con efectos secundarios.
• [ ] Medir consumo de recursos.
• [ ] Empezar por prefetch cuando la incertidumbre sea alta.

Monitorización

• [ ] Lighthouse.
• [ ] Chrome DevTools.
• [ ] PageSpeed Insights.
• [ ] Search Console.
• [ ] CrUX.
• [ ] RUM cuando exista suficiente tráfico.

31. El objetivo final no es 100

Después de todo esto, volvemos al principio.

El 100 de Lighthouse mola.

Mucho.

Pero una web realmente buena es aquella que:

• aparece rápido;
• muestra su contenido principal sin esperar eternamente;
• responde cuando pulsas;
• no mueve los elementos mientras lees;
• no descarga medio Internet para mostrar un botón;
• funciona bien en un móvil normal;
• sigue funcionando bien cuando aumenta el tráfico;
• y mantiene ese rendimiento después de meses de cambios.

Puedes tener:

Lighthouse: 100

y una mala experiencia real.

También puedes tener:

Lighthouse: 96
Core Web Vitals: Good

y una web excelente.

La puntuación es un instrumento.

La experiencia del usuario es el objetivo.

Y esa diferencia es precisamente la que separa una web que simplemente pasa una auditoría de una web que está realmente bien construida.

Conclusión

Optimizar Core Web Vitals en 2026 ya no consiste en memorizar una lista de trucos.

Consiste en entender el navegador.

Entender qué recursos son críticos.

Entender qué trabajo ocurre en el main thread.

Entender qué parte de la página necesita JavaScript.

Entender qué hacen tus terceros.

Y, sobre todo, medir la experiencia real en producción.

Si utilizas Astro o Next.js, el framework puede ayudarte mucho, pero ninguna arquitectura compensa una página que envía imágenes gigantes, ejecuta cientos de kilobytes de JavaScript innecesario y carga diez scripts de terceros antes de que el usuario pueda hacer nada.

Por eso nuestro enfoque es sencillo:

medir → encontrar el cuello de botella → optimizar → volver a medir.

No perseguimos un 100 porque una herramienta nos lo pida.

Lo perseguimos cuando tiene sentido.

Y cuando no lo tiene, nos quedamos con algo mucho más importante:

una web que se siente rápida.

Si tu proyecto tiene problemas de rendimiento, en nuestra sección de optimización web y SEO técnico explicamos cómo analizamos y corregimos problemas de rendimiento, Core Web Vitals y experiencia de usuario.