POR QUÉ TU SITIO ES LENTO
Los pocos orígenes detrás de casi todo sitio lento, cómo probar cuál tienes, y el orden que realmente mueve datos de campo.
← Guides All guides in this topic
Mide antes de adivinar
Si abres DevTools, cambias tres plugins, y redeploy sin mirar datos de campo, estás adivinando con pasos extra. Lentitud es una experiencia del visitante. Pruébalo con números de usuarios reales antes de tocar código.
Comienza con datos de campo de Chrome UX Report en PageSpeed Insights o Search Console Core Web Vitals. Quieres el percentil 75 para Largest Contentful Paint, Interaction to Next Paint, y Cumulative Layout Shift en mobile. Las puntuaciones de laboratorio de Lighthouse son útiles para debuggear una carga de página única. No son la métrica que Google usa para ranking ni la métrica que tus compradores sienten en una conexión Wi-Fi de tren.
Qué capturar en los primeros diez minutos
URL de la página lenta. Clase de dispositivo (mobile primero). Si el problema es primera visita o visita repetida. Si las páginas autenticadas difieren de la homepage pública. TTFB si puedes verlo. El nombre del elemento LCP del panel de diagnósticos. Esa lista corta generalmente apunta al carril correcto antes de que alguien debata frameworks.
Conclusión clave: Los datos de campo deciden si el sitio es lento. Los datos de laboratorio te ayudan a encontrar la palanca. Nunca inviertas ese orden.
¿Front end o servidor?
Si la página es lenta antes de que aparezca contenido, usualmente es el servidor: time to first byte alto, una consulta de base de datos sin cachear, PHP o Node renderizando en cada request, u un host que simplemente es insuficiente. Si el contenido aparece luego se mueve bruscamente, se queda parado, o se desplaza, es el front-end: imágenes, scripts, fonts, y layout.
Una división útil: TTFB bajo aproximadamente 0.8 segundos significa que el origen está mayormente fuera del critical path. Por encima de 1.2 segundos en una página publicitada, arregla hosting, cache, o el costo de server render antes de obsesionarte con codecs de imagen. Para sitios grandes el diagnóstico tiene su propio playbook en el checklist de Core Web Vitals y la guía de arreglos de LCP, INP, CLS en este sitio.
| Symptom | Likely lane | First check |
|---|---|---|
| Blank screen, then everything | Server / TTFB | Host, cache hit rate, SSR cost |
| Hero late, rest fine | Front-end LCP | Hero image size, preload, CDN |
| Taps feel sticky | Front-end INP | JS weight, long tasks, third parties |
| Page jumps while loading | Front-end CLS | Image dimensions, font swap, ads |
Conclusión clave: Nombra el carril primero. El trabajo de servidor y el trabajo de front-end necesitan personas diferentes y herramientas diferentes.
Los seis sospechosos de siempre
En orden de cuán frecuentemente son el problema real en los sitios comerciales que veo:
1. Media de hero oversized
Un PNG de 2MB o una carga sin recortar del CMS como elemento LCP. Solución: redimensionar correctamente, formato moderno (WebP o AVIF), atributos width y height, precargar la URL de LCP real, servir desde un CDN. Una buena corrección de hero frecuentemente supera diez micro-ajustes.
2. JavaScript que no necesitas en el primer renderizado
Tag managers, chat widgets, herramientas de A/B testing, hidratación de framework innecesaria, y componentes cliente "por si acaso". Solución: diferir o remover terceros, enviar menos JS en rutas de marketing, mantener islas de interactividad pequeñas.
3. Hosting y errores de caché
Hosts compartidos, WordPress frío sin caché de página, Next.js SSR en cada URL pública, o patrones ISR que reconstruyen el mundo en cada deploy. Solución: hosting administrado o caché edge para WordPress, estático o ISR con una política de revalidación sensata para app frameworks.
4. Fuentes y CSS que bloquean el renderizado
Cinco pesos de una fuente display, importados desde un archivo CSS de terceros, bloqueando texto. Solución: hacer subset, auto-alojar, font-display swap u optional, CSS crítico para above-the-fold.
5. Terceros sin límites
Píxeles que inyectan más píxeles. Solución: cargar después de la interacción o en tiempo de inactividad, eliminar cualquier cosa que no justifique su lugar en una prueba de conversión.
6. Cambio de diseño por contenido tardío
Anuncios, incrustaciones e imágenes sin espacio reservado. Solución: cajas con relación de aspecto, espacios reservados, evitar inyectar UI sobre contenido existente.
Punto clave: La mayoría de las quejas "el framework es lento" son una de estas seis con disfraz de framework.
Arregla primero lo más importante
No optimices todo a la vez. Abre la entrada de LCP en tus diagnósticos de campo o laboratorio, encuentra el elemento que es el LCP (generalmente la imagen hero o el titular), y haz eso una cosa rápida: dimensionada correctamente, precargada, servida desde un CDN. Remide. Luego elimina JavaScript que se ejecuta en la ruta crítica. Remide de nuevo.
Un orden práctico para un sitio de marketing: elemento LCP, luego JS de terceros, luego carga de fuentes, luego caché y TTFB, luego limpieza de CLS, luego microoptimizaciones. Detenerse después de los dos primeros a menudo coloca un sitio comercial en una banda CWV aprobatoria.
Nota de WordPress: una dieta de plugins y un caché de página real en hosting administrado superan una reescritura de tema más a menudo de lo que las agencias admiten. Nota de Next.js y Astro: no hagas SSR del folleto. HTML estático o en caché para páginas públicas; reserva el trabajo del servidor para superficies de producto autenticadas. Los detalles están en la guía Next.js vs Astro vs WordPress.
Punto clave: Una mejora de LCP medida supera una semana de refactores especulativos.
Modos de falla específicos del stack
WordPress
Constructores de páginas enviando todo el CSS de widgets en cada página. Plantillas de WooCommerce sin caché. Consultas pesadas de posts relacionados. Tablas de opciones autocargadas que crecieron durante años. Camino a la solución: cachear HTML en el edge, reducir plugins, lazy-load de secciones del constructor debajo del pliegue, corregir el hinchazón de autocarga de la base de datos.
Next.js
Componentes cliente envolviendo páginas completas. Cascadas de awaits secuenciales. Imágenes a través del cargador incorrecto. ISR o SSR en páginas que nunca se personalizan. Camino a la solución: Server Components por defecto, estático donde sea posible, auditar el bundle de JS por ruta.
Astro y otros stacks estáticos
Usualmente rápido a menos que reintroduzcas una isla SPA del tamaño de una app de productos, o enlaces directos a medios gigantes del CMS. Camino a la solución: mantén las islas pequeñas, procesa imágenes en el pipeline, no pegues hábitos de WordPress en un sitio estático.
Conclusión clave: Adapta la solución a tu stack. Replantear la plataforma rara vez es el primer paso en performance.
Qué se ve bien
Objetivos, medidos en visitantes reales en el percentil 75 en móvil: Largest Contentful Paint menor a 2.5 segundos, Interaction to Next Paint menor a 200 milisegundos, Cumulative Layout Shift menor a 0.1. Mantén el tiempo al primer byte por debajo de aproximadamente 0.8 segundos para que el servidor no esté en la ruta crítica.
Logra esto y el sitio no será lento de ninguna manera que un visitante o Google castiguen, sin importar lo que diga una puntuación de vanidad sintética. Cualquier cosa más rápida es pulimento. Envía el producto en lugar de perseguir 100s.
Si quieres la forma de checklist de este trabajo, usa el checklist de Core Web Vitals. Si necesitas cirugía por métrica, usa la guía de fixes para LCP, INP y CLS. Si el caso de negocio es una reconstrucción, comienza desde el pilar de performance en lugar de una presentación de rediseño.
Conclusión clave: Pasar el CWV de campo es la meta para "¿es lento?", no una captura de pantalla perfecta de Lighthouse.
Cuándo dejar el DIY y pedir ayuda
El DIY es suficiente cuando el elemento LCP es obvio, hay pocas librerías de terceros y controlas el hosting. Trae ayuda cuando los datos de campo siguen en rojo después de dos ciclos honestos de corrección, cuando el stack es un híbrido que nadie en el equipo domina, o cuando las páginas de ingresos no pueden esperar otra semana de cambios especulativos.
Un brief útil para un outsider: las tres URLs que importan, las capturas de pantalla de campo, los nombres de elementos LCP, el host y CDN, y la lista de tags que no puedes remover. Ese paquete convierte un vago "el sitio es lento" en un trabajo de un sprint.
Si la conversación se convierte en un rediseño completo, pausa. El trabajo de performance y el trabajo de rediseño se mezclan mal a menos que el rediseño tenga un presupuesto CWV explícito. Arregla las templates actuales primero cuando el negocio todavía depende de ellas.
Punto clave: Dos ciclos de corrección fallidos o ningún dueño claro es la línea entre DIY y un performance pass pagado.