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

Para hacer tu web más rápida, mídela primero con PageSpeed Insights y luego corrige la causa principal que te señale —normalmente, imágenes sobredimensionadas, demasiado JavaScript, fuentes pesadas o scripts de terceros—. Apunta a los objetivos «buenos» de Core Web Vitals de Google: el contenido principal visible en 2,5 segundos, respuesta a los toques en 200 milisegundos y casi ningún salto de diseño. La mayoría de las webs llegan ahí con unos pocos cambios, no con una reescritura.

Mide antes de cambiar nada

Adivinar hace perder tiempo. Dos herramientas gratuitas cubren a casi todos:

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

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

INP sustituyó en 2024 a la antigua métrica First Input Delay. Si una herramienta todavía informa de FID, está desactualizada.

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

Dónde se va el tiempo: opciones y compromisos

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.

Imágenes

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

• Sirve las imágenes al tamaño con que se muestran, con tamaños srcset responsivos para teléfonos 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. Solo esto corrige la mayor parte del desplazamiento de diseño.
• Carga en diferido las imágenes bajo el pliegue con loading="lazy".
• Nunca cargues en diferido la imagen principal de la parte superior de la página. La guía de LCP de Google es tajante: cargar en diferido la imagen LCP siempre la retrasa. Dale fetchpriority="high" en su lugar.

JavaScript

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

1. Elimina lo que no usas. Pide una lista de dependencias y elimina las bibliotecas que se añadieron una vez y se olvidaron: una librería de fechas para una sola fecha, un paquete entero de iconos para cinco iconos.
2. Divide por ruta. Carga el código del panel de administración solo cuando alguien lo abra, no en la página de inicio.
3. Prerenderiza las páginas públicas. Una página de marketing que se sirve 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 una tabla entera cuando cambia una celda. El panel de rendimiento de las herramientas de desarrollo de Chrome muestra cuál es.

Fuentes

Cada familia y grosor de fuente es otro archivo. Dos familias y tres o cuatro grosores suelen bastar. Precarga la fuente que se usa por encima del pliegue, usa font-display: swap para que el texto se muestre de inmediato y aloja las fuentes tú mismo si el servicio externo de fuentes 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 embebidos y los feeds de redes sociales cargan código desde otros servidores. Cada uno parece pequeño; juntos, a menudo son la parte más lenta de la página. Mantén los que realmente consultas. 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) —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 un servidor genera 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.

Prompts 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 informa de 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 responsivos, define width y height, dale fetchpriority="high" y asegúrate de que no se carga en diferido. Carga en diferido 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 añade aproximadamente al paquete. Elimina los que no se usan y separa las rutas /admin y /settings en fragmentos que solo se cargan al visitarlas.

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

Paso a paso

1. Prueba la página en vivo en PageSpeed Insights en móvil. Anota LCP, INP y CLS, y los tres problemas principales que aparecen.
2. Arregla primero las imágenes: tamaños, formatos, dimensiones, carga en diferido bajo el pliegue, prioridad para la destacada.
3. Elimina los scripts de terceros que no uses, y aplaza el resto.
4. Recorta las fuentes a lo que necesita el diseño.
5. Reduce el JavaScript: elimina paquetes sin uso, divide por ruta.
6. Prerenderiza las páginas públicas si todavía se renderizan en el cliente y el LCP sigue lento.
7. Revisa el servidor: caché, índices de base de datos, alojamiento estático para contenido que cambia poco.
8. Vuelve a publicar y vuelve a medir. Los datos de campo de PageSpeed Insights se actualizan durante las semanas siguientes conforme llegan visitas reales, así que juzga los primeros resultados por los datos de laboratorio.

Errores comunes

• Probar solo en un portátil rápido. Tus visitantes usan teléfonos 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 en diferido, incluida la imagen destacada. Eso empeora el LCP.
• Añadir un plugin o una biblioteca de velocidad encima. 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 después de 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 en diferido; las imágenes bajo el pliegue sí
• Sin bibliotecas de JavaScript sin uso; 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 prerenderizadas o estáticas siempre que sea posible
• Vuelta a medir en la URL en vivo después de publicar

La velocidad y el diseño móvil van de la mano; consulta cómo hacer tu web adaptable al móvil. 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 (webs estáticas), lo que encaja con las páginas de contenido. Las apps con servidor escalan a cero: se duermen cuando están inactivas y despiertan con la siguiente visita, así que la primera petición tras un periodo tranquilo es más lenta, y una base de datos adjunta se duerme tras 5 minutos inactivos (límites de alojamiento). Si una página pública solo va 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 con forzado de caché.

Preguntas