POR QUÉ TU PÁGINA WEB VA LENTA
Las pocas causas que se esconden detrás de casi todos los sitios web lentos, cómo averiguar cuál es la tuya y el orden en el que realmente se procesan los datos de campo.
← Todas las guías Todas las guías de este tema
Mide antes de adivinar
Si abres DevTools, modificas tres complementos y vuelves a implementar sin fijarte en los datos de campo, estás actuando a ciegas y dando pasos innecesarios. La lentitud afecta a la experiencia del visitante. Demuéstralo con cifras de usuarios reales antes de tocar el código.
Empieza con los datos de campo del Informe de experiencia de usuario de Chrome (Chrome UX Report) en PageSpeed Insights o en Core Web Vitals de Search Console. Lo que te interesa es el percentil 75 para «Largest Contentful Paint», «Interaction to Next Paint» y «Cumulative Layout Shift» en dispositivos móviles. Las puntuaciones de laboratorio de Lighthouse son útiles para depurar la carga de una sola página. No son la métrica que utiliza Google para el posicionamiento ni la que perciben tus clientes cuando utilizan la conexión Wi-Fi del tren.
Qué hay que captar en los primeros diez minutos
URL de la página lenta. Clase de dispositivo (prioridad al móvil). Si el problema se produce en la primera visita o en una visita posterior. Si las páginas a las que se accede tras iniciar sesión difieren de la página de inicio pública. El TTFB, si lo puedes ver. El nombre del elemento LCP que aparece en el panel de diagnóstico. Esa breve lista suele indicar el camino correcto antes de que nadie empiece a debatir sobre los marcos de trabajo.
Conclusión clave: Los datos de campo determinan si la página web es lenta. Los datos de laboratorio te ayudan a encontrar la solución. Nunca inviertas ese orden.
¿Front-end o servidor?
Si la página tarda en cargarse antes de que aparezca ningún contenido, suele ser culpa del servidor: un tiempo de respuesta demasiado largo hasta el primer byte, una consulta a la base de datos sin almacenar en caché, la generación de contenido con PHP o Node en cada solicitud, o un servidor con recursos insuficientes. Si el contenido aparece pero luego se entrecorta, se cuelga o se desplaza, el problema está en el front-end: imágenes, scripts, fuentes y maquetación.
Una distinción útil: un TTFB inferior a unos 0,8 segundos significa que el origen queda, en su mayor parte, fuera de la ruta crítica. Si supera los 1,2 segundos en una página de marketing, soluciona los problemas de alojamiento, caché o tiempo de renderizado del servidor antes de obsesionarte con los códecs de imagen. Para sitios web de gran tamaño, el diagnóstico cuenta con su propio manual en la lista de comprobación de Core Web Vitals y en la guía de corrección de LCP, INP y CLS de este sitio web.
| Síntoma | Carril probable | Primera comprobación |
|---|---|---|
| Pantalla en blanco, y luego todo | Servidor / TTFB | Servidor, tasa de aciertos en la caché, coste de SSR |
| Hero llega tarde, el resto está bien | LCP del front-end | Tamaño de imagen hero, preload, CDN |
| Los grifos se notan pegajosos | INP de interfaz de usuario | Peso del JS, tareas largas, terceros |
| La página salta mientras se carga | CLS de interfaz de usuario | Dimensiones de las imágenes, cambio de fuente, anuncios |
Conclusión clave: Define primero el ámbito de trabajo. El trabajo en el servidor y el trabajo en el front-end requieren personas y herramientas diferentes.
Los seis sospechosos habituales
Por orden de frecuencia con la que suponen un verdadero problema en las páginas web comerciales que veo:
1. Imágenes de gran tamaño
Un archivo PNG de 2 MB o una imagen sin recortar subida al CMS como elemento LCP. Solución: ajustar el tamaño, utilizar un formato moderno (WebP o AVIF), incluir los atributos de anchura y altura, precargar la URL real del LCP y servirla desde una CDN. Una buena solución integral suele ser más eficaz que diez pequeños ajustes.
2. Código JavaScript que no es necesario en la primera visualización
Gestores de etiquetas, widgets de chat, herramientas A/B, integración de marcos de trabajo en desuso y componentes de cliente «por si acaso». Solución: aplazar o eliminar los elementos de terceros, enviar menos código JS en las rutas de marketing y mantener pequeñas las «islas» de interactividad.
3. Alojamiento y fallos de caché
Servidores compartidos, WordPress «en frío» sin caché de páginas, SSR de Next.js en cada URL pública o patrones ISR que reconstruyen todo el contenido en cada implementación. Solución: alojamiento gestionado o caché de borde para WordPress; contenido estático o ISR con una política de revalidación razonable para los marcos de aplicaciones.
4. Fuentes y CSS que impiden la visualización
Cinco pesos de una fuente de pantalla, importados desde un archivo CSS de terceros, bloquean el texto. Solución: subset, self-host, font-display swap u optional, CSS crítico para la parte visible de la página.
5. Terceros sin restricciones
Píxeles que generan más píxeles. Solución: cargarlos tras una interacción o en momentos de inactividad; eliminar todo aquello que no se gane su lugar en una prueba de conversión.
6. Cambios en la maquetación debidos a contenidos añadidos posteriormente
Anuncios, elementos incrustados e imágenes sin espacio reservado. Solución: recuadros con relación de aspecto, espacios reservados; evitar insertar elementos de la interfaz de usuario por encima del contenido existente.
Conclusión clave: La mayoría de las quejas del tipo «el framework es lento» se reducen a una de estas seis razones, disfrazadas de problema del framework.
Resuelve primero lo más importante
No optimices todo a la vez. Abre la entrada de LCP en tu diagnóstico de campo o de laboratorio, busca el elemento que constituye el LCP (normalmente la imagen principal o el titular) y haz que ese elemento sea rápido: con el tamaño adecuado, precargado y servido desde una CDN. Vuelve a medir. A continuación, elimina el código JavaScript que se ejecuta en la ruta crítica. Vuelve a medir de nuevo.
Un orden práctico para una web de marketing: elemento LCP, luego JS de terceros, luego carga de fuentes, luego caché y TTFB, luego corrección del CLS y, por último, microoptimizaciones. Si nos detenemos tras los dos primeros pasos, una web comercial suele situarse en una banda de CWV aceptable.
Nota sobre WordPress: una «dieta» de plugins y un almacenamiento en caché de páginas real en un alojamiento gestionado suelen dar mejores resultados que reescribir el tema, más a menudo de lo que las agencias admiten. Nota sobre Next.js y Astro: no utilices SSR para el sitio web de presentación. Utiliza HTML estático o en caché para las páginas públicas; reserva la carga del servidor para las interfaces de productos que requieran autenticación. Encontrarás más detalles en la guía «Next.js vs Astro vs WordPress».
Conclusión clave: Una mejora bien meditada en el LCP vale más que una semana de refactorizaciones especulativas.
Modos de fallo específicos de la pila
WordPress
Los creadores de páginas envían el CSS de todos los widgets a cada página. Plantillas de WooCommerce sin almacenar en caché. Consultas pesadas de entradas relacionadas. Tablas de opciones cargadas automáticamente que han ido creciendo a lo largo de los años. Solución: almacenar en caché el HTML en el borde, eliminar plugins, aplicar carga diferida a las secciones del creador situadas por debajo del pliegue y solucionar la sobrecarga de la carga automática de la base de datos.
Next.js
Componentes de cliente que envuelven páginas completas. Cascadas de esperas secuenciales. Imágenes cargadas a través del cargador incorrecto. ISR o SSR en páginas que nunca se personalizan. Solución: componentes de servidor por defecto, estáticos siempre que sea posible, y revisión del paquete de JS por ruta.
Astro y otras pilas estáticas
Normalmente es rápido, a menos que vuelvas a introducir una «isla» SPA del tamaño de una aplicación de producto o que enlaces directamente a archivos multimedia gigantes de un CMS. Solución: mantén las «islas» muy pequeñas, procesa las imágenes en la cadena de procesamiento y no apliques los hábitos de WordPress a un sitio web estático.
Conclusión clave: adapta la solución a la pila tecnológica. El cambio de plataforma rara vez es la primera medida que se toma para mejorar el rendimiento.
Cómo es lo bueno
Objetivos, medidos en visitantes reales en el percentil 75 en dispositivos móviles: «Largest Contentful Paint» por debajo de 2,5 segundos, «Interaction to Next Paint» por debajo de 200 milisegundos y «Cumulative Layout Shift» por debajo de 0,1. Mantener el tiempo hasta el primer byte por debajo de unos 0,8 segundos para que el servidor no forme parte de la ruta crítica.
Si cumples con estos requisitos, la web no será lenta en ningún aspecto que pueda penalizar ni a los visitantes ni a Google, independientemente de lo que indique una puntuación de vanidad sintética. Cualquier cosa más rápida es un simple toque de acabado. Lanza el producto en lugar de perseguir puntuaciones de 100.
Si quieres consultar este trabajo en formato de lista de comprobación, utiliza la lista de comprobación de Core Web Vitals. Si necesitas intervenciones específicas para cada métrica, utiliza la guía de corrección LCP, INP y CLS. Si el caso de negocio consiste en una reconstrucción, empieza por el pilar del rendimiento en lugar de por una presentación de rediseño.
Conclusión clave: Superar el CWV de campo es la meta a la que hay que llegar para responder a la pregunta «¿es lento?», no una captura de pantalla perfecta de Lighthouse.
Cuándo dejar de hacerlo uno mismo y pedir ayuda
El «hazlo tú mismo» es suficiente cuando el elemento LCP es evidente, hay pocos terceros implicados y tú controlas el alojamiento. Recurre a ayuda cuando los datos de campo sigan en rojo tras dos ciclos de correcciones serias, cuando la pila sea híbrida y nadie del equipo se haga responsable de ella, o cuando las páginas que generan ingresos no puedan soportar otra semana de cambios especulativos.
Una guía útil para alguien que no esté familiarizado con el tema: las tres URL importantes, las capturas de pantalla de los campos, los nombres de los elementos LCP, el servidor y la CDN, y la lista de etiquetas que no se pueden eliminar. Ese paquete convierte un vago «la web va lenta» en una tarea que se puede resolver en un solo sprint.
Si la conversación deriva hacia un rediseño completo, haz una pausa. Las tareas de optimización del rendimiento y de rediseño no se compaginan bien, a menos que el rediseño cuente con un presupuesto explícito para el CWV. Arregla primero las plantillas actuales, ya que el negocio sigue dependiendo de ellas.
Conclusión clave: Dos ciclos de corrección fallidos o la falta de un responsable claro marcan la diferencia entre hacerlo uno mismo y contratar un servicio de optimización de pago.