Abre tu web ahora mismo desde el móvil, con datos y no con el wifi de casa. Cuenta los segundos hasta que puedes leer algo. Si pasas de tres, tienes un problema, y no es de diseño.

Más de la mitad de la gente se va de una página que tarda más de tres segundos en abrir. Se van antes de ver lo que vendes, antes del teléfono, antes de todo. Y encima Google lo sabe: mide la velocidad real de tu web con datos de usuarios de verdad y la usa para decidir si te pone por delante o por detrás de tu competencia.

Lo bueno es que casi siempre se arregla, y no hace falta rehacer la web entera. Aquí te contamos por qué pasa, cómo se mide de verdad y qué hacemos nosotros para dejarla rápida. Hay una parte técnica, avisamos: si te interesa el resultado y no el cómo, quédate con el primer bloque y con el último.

Antes de nada: laboratorio no es realidad

Es la confusión más habitual y conviene aclararla desde el principio.

PageSpeed Insights te da dos cosas distintas. Arriba, si tu web tiene tráfico suficiente, aparecen los datos de usuarios reales (CrUX): lo que de verdad experimenta la gente, y lo que Google usa como señal de ranking. Abajo aparece la prueba de Lighthouse: una simulación en condiciones controladas, en ese instante.

La consecuencia práctica: el 100 de Lighthouse es la condición necesaria, no el resultado. Los datos de usuarios reales tardan semanas en reflejar tus cambios porque se calculan sobre una ventana de 28 días. Así que llegar a 100 hoy y ver la mejora en Search Console dentro de un mes es el comportamiento normal, no un fallo.

Segunda consecuencia: nunca midas contra el servidor de desarrollo. En modo desarrollo, Next.js desactiva buena parte de las optimizaciones. Un npm run dev puntúa fatal y no significa nada. Mide siempre contra npm run build + npm run start, o directamente contra producción.

Las cuatro categorías, y cuál importa de verdad

Lighthouse puntúa cuatro cosas. No pesan igual para tu negocio:

Categoría	Qué mide	Impacto SEO
Rendimiento	Core Web Vitals y tiempos de carga	Directo: factor de ranking
Accesibilidad	Contraste, etiquetas, semántica, navegación con teclado	Indirecto, pero legalmente relevante
Buenas prácticas	HTTPS, errores de consola, imágenes correctas	Bajo, pero barato de arreglar
SEO	Metadatos, indexabilidad, enlaces rastreables	Directo, y muy fácil de subir a 100

El orden inteligente de trabajo es el inverso al que la gente hace por instinto: SEO y accesibilidad primero (arreglos rápidos, de bajo riesgo, que suben mucho el marcador con poco esfuerzo), rendimiento después (es el que necesita varias vueltas), y buenas prácticas al final, porque normalmente ya queda resuelto de rebote.

Core Web Vitals: las tres métricas que cuentan

LCP — Largest Contentful Paint

Cuánto tarda en pintarse el elemento más grande de la pantalla inicial. Casi siempre es la imagen del hero o el titular grande. Objetivo: por debajo de 2,5 segundos.

En Next.js, las causas y sus arreglos:

—Imagen del hero sin optimizar. Usa next/image con priority en la imagen del hero, y solo en esa. Marcar diez imágenes como prioritarias es lo mismo que no marcar ninguna.
—Fuentes que bloquean. Carga las tipografías con next/font en lugar de un enlace a Google Fonts. Se auto-alojan en el build, eliminan la petición externa y aplican font-display: swap por defecto.
—Tiempo de respuesta del servidor alto. Si el HTML tarda en llegar, nada de lo demás importa. Prerrenderiza lo que puedas: las páginas estáticas se sirven desde el CDN y salen prácticamente instantáneas.
—Componente cliente envolviendo la mitad de la página. Un "use client" en un componente muy alto del árbol arrastra todo lo de dentro al bundle del navegador. Baja el "use client" lo más cerca posible de donde de verdad hace falta interactividad.

CLS — Cumulative Layout Shift

Cuánto se mueve el contenido mientras carga. Es la métrica que más molesta al usuario (vas a pulsar un botón y se desplaza) y la más fácil de arreglar. Objetivo: por debajo de 0,1.

—Toda imagen con ancho y alto declarados, o con fill dentro de un contenedor con dimensiones. Sin eso, el navegador no reserva el espacio.
—Fuentes con fallback ajustado. next/font ya lo gestiona; si cargas la tipografía a mano, el cambio de fuente provoca un salto de texto.
—Nada que se inyecte por encima del contenido después de cargar: banners, avisos de cookies, barras promocionales. Reserva su altura desde el principio o superpónlos en lugar de empujar el layout.

INP — Interaction to Next Paint

Cuánto tarda la página en responder cuando el usuario toca algo. Sustituyó a FID en 2024. Objetivo: por debajo de 200 ms.

—Menos JavaScript. Es la respuesta al 90% de los problemas de INP. Revisa qué componentes son cliente sin necesitarlo.
—Carga diferida de lo pesado. Un mapa, un carrusel, un chat: next/dynamic con ssr: false y que se cargue cuando entre en pantalla o cuando el usuario lo pida.
—Scripts de terceros con next/script y la estrategia correcta: afterInteractive para analítica, lazyOnload para chats y píxeles.

Los arreglos que más puntos dan, en orden

Después de bastantes auditorías, el reparto de puntos es sorprendentemente repetible. Este es el orden por rentabilidad:

—Imágenes fuera de next/image. Un <img> suelto en un componente compartido está penalizando todas las páginas a la vez. Convertirlo es el arreglo más rentable que existe.
—Fuentes externas sin next/font. Una petición menos a otro dominio y un salto de texto menos.
—Metadatos que faltan. Cada página con su title y su description en el objeto metadata. Sube la categoría SEO a 100 casi sola.
—Textos alternativos faltantes. Accesibilidad y SEO a la vez, y es puro rellenar atributos.
—Scripts de terceros en el head sin async/defer. Bloquean el pintado inicial. Pásalos a next/script.
—Bundle de JavaScript hinchado. Aquí es donde hay que pensar: qué es cliente y no debería serlo, qué librería pesa 200 kB para hacer algo que resuelven veinte líneas.
—Contraste de color insuficiente. Es el único arreglo que puede cambiar el aspecto de la web, así que se decide con el cliente, no por tu cuenta.

Nota sobre el punto 7: si un color de marca no llega al mínimo de WCAG, la solución no es cambiar la identidad visual, es proponer el tono más cercano que sí cumpla y decidirlo conscientemente. Nadie debería descubrir que le han cambiado el color corporativo por un punto de Lighthouse.

El ciclo de trabajo: medir, arreglar, volver a medir

Optimizar a ciegas es tirar horas. El ciclo es siempre el mismo:

—Línea base contra producción. Mide la home y las tres o cuatro páginas que más importan al negocio (contacto, el servicio estrella, la landing con más tráfico), en móvil y en escritorio. Guarda los números.
—Localiza el problema en el código. Lighthouse te dice qué falla; el código te dice dónde. Busca los patrones concretos: <img sin next/image, fonts.googleapis.com, <script en el layout, "use client" en componentes que no lo necesitan.
—Arregla por bloques, no todo a la vez. Y comprueba que nada se ha roto funcionalmente después de cada bloque: un 100 en Lighthouse con el formulario de contacto roto no es un éxito, es un problema nuevo.
—Build de producción y vuelve a medir en local. Compara contra la línea base.
—Itera solo sobre lo que sigue fallando. No repitas el trabajo ya hecho.

Cuándo parar. Cuando llegues al objetivo, o cuando dos iteraciones seguidas mejoren menos de un punto en total. Eso último significa que lo que queda es estructural — el tiempo de respuesta del hosting, un widget de terceros que el negocio necesita — y seguir apretando empieza a hacer más daño que bien.

Una excepción que conviene decir en voz alta: los widgets que el negocio necesita no se borran por rendimiento. El chat, el mapa, el píxel de conversión: se retrasan, se cargan bajo demanda, se sirven cuando el usuario los pide. Pero no se eliminan para ganar cinco puntos.

Por qué en Next.js sale mejor que en otras plataformas

Casi todo lo anterior es una decisión de arquitectura, no un truco. Next.js pone las optimizaciones en el camino por defecto: renderizado en servidor, prerrenderizado estático, división automática del código, imágenes optimizadas y fuentes auto-alojadas vienen de serie.

En una instalación con muchos plugins, cada uno añade su propio CSS y su propio JavaScript a todas las páginas, y el trabajo consiste en pelear contra esa acumulación en lugar de partir de cero. Es la diferencia entre optimizar y desoptimizar menos. Lo comparamos en detalle en Next.js vs WordPress para SEO local.

Preguntas frecuentes

¿Google penaliza de verdad una web lenta? Penalizar no es exactamente la palabra. Los Core Web Vitals son un factor de ranking real, pero de desempate: si tu contenido es claramente el mejor para una búsqueda, no vas a caer al puesto 40 por un LCP de 3 segundos. Donde se nota es en búsquedas competidas — y las búsquedas locales lo son casi todas. Entre dos negocios equivalentes en la misma ciudad, la web rápida gana.

¿Necesito el 100 exacto? No. El 100 es el ideal; el objetivo razonable es 95 o más de media en las cuatro categorías, en móvil y en escritorio. Del 95 al 100 suele haber más trabajo que del 60 al 95, y el retorno es mucho menor.

¿Por qué mi puntuación cambia cada vez que mido? Porque Lighthouse simula red y CPU, y hay variabilidad natural. Cinco puntos de diferencia entre dos medidas es normal. Fíjate en la tendencia y en los avisos concretos, no en el número exacto.

¿Móvil o escritorio? Móvil. La indexación de Google es mobile-first y la puntuación móvil siempre es más baja porque simula un dispositivo modesto con red lenta. Si arreglas móvil, escritorio viene de regalo.

Ya está rápido en mi ordenador, ¿por qué puntúa mal? Porque tú la abres con fibra, un portátil potente y la caché caliente. La medida se hace con un móvil medio y sin caché. Ese es el escenario de tu cliente potencial, no el tuyo.

Conclusión

Llegar a 100 en PageSpeed no es cuestión de trucos, es cuestión de método: medir en producción, encontrar el patrón concreto en el código, arreglarlo sin tocar el diseño y volver a medir hasta que la curva se aplane.

Y como el rendimiento es solo uno de los cuatro bloques que Google valora, tiene poco sentido optimizarlo en una web cuyo SEO técnico está roto. Si no sabes en qué estado está el resto, empieza por el checklist de auditoría SEO local.

Si quieres los números de tu web antes de decidir nada, te los damos: medimos tus Core Web Vitals reales en móvil y escritorio y te decimos qué está costando puntos y cuánto trabajo lleva arreglarlo.

Solicitar auditoría de rendimiento · Ver servicio de diseño web

¿Quieres que tu negocio aparezca en Google?

Hablamos de tu negocio, tu competencia y lo que realmente necesitas. Sin compromiso. Te respondemos en menos de 48 horas con orientación clara y un presupuesto cerrado.

Agendar Consulta Gratuita