Cómo hacer tu web más rápida: una lista de comprobación práctica

Para hacer una web más rápida, mídela primero con PageSpeed Insights y luego corrige la causa principal que te señale, que suele ser un exceso de tamaño en las imágenes, demasiado JavaScript, fuentes pesadas o scripts de terceros. Apunta a los objetivos "buenos" de los Core Web Vitals de Google: el contenido principal visible en 2,5 segundos, respuestas a los toques en 200 milisegundos y casi ningún salto del diseño. La mayoría de webs lo consiguen con un puñado de cambios, no con una reescritura.

Mide antes de cambiar nada

Adivinar hace perder tiempo. Dos herramientas gratuitas cubren a casi todo el mundo:

PageSpeed Insights (pagespeed.web.dev): pega una URL en vivo. Muestra datos de campo de usuarios reales de Chrome (si tu web tiene suficiente tráfico) y datos de laboratorio de una carga simulada, además de una lista de problemas concretos.
Lighthouse en las DevTools de Chrome: la misma prueba de laboratorio, ejecutada en cualquier página que puedas abrir, incluida una vista previa. Prueba en modo móvil; los problemas se notan en teléfonos con redes más lentas.

Las cifras que importan son los Core Web Vitals de Google. A septiembre de 2026, la documentación de Google en web.dev establece estos umbrales "buenos", medidos en el percentil 75 de las cargas de página:

Métrica	Qué mide	Bueno
Largest Contentful Paint (LCP)	Lo pronto que aparece el contenido principal (imagen destacada, titular)	2,5 s o menos
Interaction to Next Paint (INP)	Lo rápido que reacciona la página a clics, toques y escritura	200 ms o menos
Cumulative Layout Shift (CLS)	Cuánto salta el diseño mientras carga	0,1 o menos

INP sustituyó en 2024 a la antigua métrica First Input Delay. Si alguna herramienta sigue informando de FID, está desactualizada.

Anota tus cifras iniciales. Después de cada corrección, vuelve a medir para saber qué ayudó.

Dónde se va el tiempo: opciones y compensaciones

Cada causa habitual tiene una solución, y cada solución tiene un coste. Empieza por las de arriba: son las más baratas y las más comunes.

Causa	Solución típica	Contrapartida
Imágenes grandes	Redimensionar al tamaño mostrado, comprimir, usar WebP o AVIF	Ligera pérdida de calidad si se comprime en exceso
Imágenes que cargan en el orden equivocado	Carga diferida de las imágenes bajo el pliegue; dar prioridad alta a la imagen destacada	Ninguna, siempre que la imagen destacada no se cargue de forma diferida
Demasiado JavaScript	Dividir el código por página, eliminar las bibliotecas no usadas	Algo de refactorización
Renderizado solo en el cliente	Prerrenderizar o renderizar en el servidor las páginas públicas	Más configuración de compilación o de servidor
Fuentes web	Menos familias y grosores, precargar la principal, `font-display: swap`	Menos variedad tipográfica
Scripts de terceros	Eliminar los que no usas, cargar el resto tras la página	Perder un widget o un rastreador
Respuesta lenta del servidor	Caché, una CDN, alojamiento estático para las páginas de contenido	Hay que pensar en la invalidación de caché

Imágenes

Las imágenes son el problema más habitual y el más fácil de arreglar. Una foto de 4.000 píxeles mostrada a 800 píxeles de ancho obliga a cada visitante a descargar cinco veces más de lo que ve.

Sirve las imágenes con el tamaño con el que se muestran, con tamaños srcset adaptables para móviles y escritorio.
Usa formatos modernos (WebP o AVIF) y una compresión sensata.
Define width y height en cada imagen para que el navegador reserve el espacio. Esto solo ya corrige la mayor parte del desplazamiento del diseño.
Carga de forma diferida las imágenes bajo el pliegue con loading="lazy".
Nunca cargues de forma diferida la imagen principal de la parte superior de la página. La guía de LCP de Google es tajante: cargar de forma diferida la imagen LCP siempre la retrasa. Dale fetchpriority="high" en su lugar.

JavaScript

Muchas webs creadas con IA son aplicaciones de una sola página (SPA): el navegador descarga un paquete de JavaScript y luego dibuja la página. Cuanto mayor es el paquete, más tarda la pantalla en blanco. Las soluciones, por orden de esfuerzo:

Elimina lo que no usas. Pide una lista de dependencias y quita bibliotecas que se añadieron una vez y se olvidaron: una biblioteca de fechas para una sola fecha, un paquete completo de iconos para cinco iconos.
Divide por ruta. Carga el código del panel de administración solo cuando alguien lo abre, no en la página de inicio.
Prerrenderiza las páginas públicas. Una página de marketing que se entrega como HTML real aparece antes de que se ejecute cualquier JavaScript. Esto también ayuda a los buscadores; consulta SEO para webs creadas con IA.

Un INP lento suele significar una tarea larga que bloquea la página: filtrar una lista enorme en cada pulsación de tecla, o volver a renderizar toda una tabla cuando cambia una celda. El panel Performance de las DevTools de Chrome muestra cuál.

Fuentes

Cada familia y grosor de fuente es otro archivo. Dos familias y entre tres y cuatro grosores suelen bastar. Precarga la fuente que se usa en la parte visible sin desplazarse, usa font-display: swap para que el texto se muestre de inmediato y aloja tú las fuentes si el servicio externo es lento para tus visitantes.

Scripts de terceros

Los widgets de chat, la analítica, los mapas de calor, los píxeles publicitarios, los vídeos incrustados y los feeds de redes sociales cargan código desde otros servidores. Cada uno parece pequeño; juntos suelen ser la parte más lenta de la página. Conserva solo los que realmente miras. Carga el resto cuando la página ya sea interactiva, y sustituye los embebidos pesados (un reproductor de YouTube, un mapa) por una vista previa ligera que cargue el contenido real al hacer clic.

Respuesta del servidor

El tiempo hasta el primer byte (TTFB), es decir, cuánto tarda el servidor en empezar a responder, está debajo de todas las demás métricas. Las páginas estáticas servidas desde una CDN (una red de servidores cerca de tus visitantes; consulta qué es una CDN) son rápidas casi en todas partes. Las páginas que genera un servidor en cada petición dependen de ese servidor y de su base de datos. Almacenar en caché el trabajo repetido y añadir índices a la base de datos para las consultas lentas son las soluciones habituales.

Instrucciones que funcionan

Sé concreto: nombra la página, la métrica y la restricción. Pega los hallazgos de PageSpeed Insights si los tienes.

PageSpeed Insights indica un LCP de 4,8 s en móvil para la página de inicio, y el elemento LCP es la imagen destacada. Redimensiona y convierte la imagen destacada a WebP, sirve tamaños adaptables, define width y height, ponle fetchpriority="high" y asegúrate de que no se carga de forma diferida. Carga de forma diferida todas las imágenes bajo el pliegue. No cambies el diseño.

Audita las dependencias de esta app. Enumera cada paquete, qué lo usa y cuánto aproximadamente añade al paquete. Elimina los que no se usen y divide las rutas /admin y /settings en fragmentos separados que solo se carguen al visitarlas.

El cuadro de búsqueda de /products va con retraso. Aplica un debounce al filtro, evita volver a renderizar toda la lista en cada pulsación y pagina o virtualiza la lista si tiene más de 200 elementos.

Paso a paso

Prueba la página en vivo en PageSpeed Insights en móvil. Anota LCP, INP, CLS y los tres problemas principales que aparezcan.
Arregla primero las imágenes: tamaños, formatos, dimensiones, carga diferida bajo el pliegue, prioridad para la imagen destacada.
Recorta los scripts de terceros que no uses y aplaza el resto.
Reduce las fuentes a lo que necesita el diseño.
Adelgaza el JavaScript: elimina paquetes no usados, divide por ruta.
Prerrenderiza las páginas públicas si siguen renderizándose en el cliente y el LCP sigue siendo lento.
Revisa el servidor: caché, índices de la base de datos, alojamiento estático para el contenido que cambia poco.
Vuelve a publicar y vuelve a medir. Los datos de campo de PageSpeed Insights se actualizan durante las semanas siguientes a medida que llegan visitas reales, así que juzga los resultados iniciales por los datos de laboratorio.

Errores comunes

Probar solo en un portátil rápido. Tus visitantes usan móviles de gama media y datos móviles irregulares. Prueba en modo móvil.
Perseguir un 100 perfecto. La puntuación de laboratorio es una guía. Cuando los Core Web Vitals están en el rango bueno, el contenido y la usabilidad importan más que los últimos puntos.
Cargar todo de forma diferida, incluida la imagen destacada. Eso empeora el LCP.
Añadir encima un plugin o una biblioteca de velocidad. Quitar peso casi siempre gana a añadir código para gestionarlo.
Optimizar la vista previa, no la web en vivo. Las vistas previas de desarrollo ejecutan compilaciones sin optimizar. Mide la URL publicada.
Arreglar la velocidad una sola vez. Cada nuevo widget, imagen o función añade peso. Vuelve a medir tras los cambios grandes.

Lista de comprobación de velocidad

LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 en móvil
Imágenes redimensionadas, comprimidas, en formato moderno, con width y height
La imagen destacada no se carga de forma diferida; las imágenes bajo el pliegue sí
Sin bibliotecas de JavaScript sin usar; rutas pesadas separadas
Dos familias de fuentes o menos, fuente principal precargada
Solo los scripts de terceros que realmente usas, cargados tarde
Páginas públicas prerrenderizadas o estáticas siempre que sea posible
Vuelta a medir en la URL en vivo tras publicar

La velocidad y el diseño móvil van de la mano; consulta cómo hacer una web adaptable para móviles. Para una revisión completa antes del lanzamiento, cómo llevar un prototipo de IA a producción cubre el resto.

Velocidad en Mythex

En Mythex haces estos cambios pidiéndolos en el chat, o en el editor de código en Pro. Comprueba la URL publicada, no la vista previa, ya que la vista previa ejecuta un servidor de desarrollo. Los frontends estáticos se despliegan como sitios estáticos al publicar (sitios web estáticos), lo que encaja con las páginas de contenido. Las apps con servidor se escalan a cero: se duermen cuando están inactivas y se despiertan en la siguiente visita, así que la primera petición tras un periodo de calma es más lenta, y una base de datos conectada se duerme tras 5 minutos inactiva (límites de alojamiento). Si una página pública solo es lenta en la primera visita, esa es la causa probable. Mantener las páginas de marketing estáticas ayuda. Tras los cambios, vuelve a publicar y recarga forzando la caché.

Preguntas

¿Cuál es un buen tiempo de carga de una página?

Los Core Web Vitals de Google ofrecen los objetivos más claros: el contenido principal debería aparecer en 2,5 segundos (LCP), la página debería responder a la interacción en 200 milisegundos (INP) y el desplazamiento del diseño debería quedarse en 0,1 o menos (CLS), medido en el percentil 75 de visitas reales.

¿La velocidad de la web afecta al SEO?

Sí, pero poco. Google usa señales de experiencia de página, incluidos los Core Web Vitals, pero el contenido relevante importa mucho más. La velocidad afecta más a los visitantes, que abandonan las páginas lentas antes de leer nada.

¿Por qué la puntuación de PageSpeed Insights cambia cada vez?

La puntuación de laboratorio sale de una única carga simulada, así que los tiempos de red y del servidor varían entre pruebas. Ejecútalo varias veces, fíjate en la tendencia y da más peso a la sección de datos de campo, que procede de usuarios reales de Chrome.

¿Qué ralentiza más la mayoría de las webs?

Normalmente, imágenes demasiado grandes, demasiado JavaScript, fuentes web y scripts de terceros como los widgets de chat, los píxeles publicitarios y los embebidos. Una respuesta lenta del servidor o un backend que arranca en frío suma a todo lo anterior.