Cómo redujimos el tiempo de carga de un site a menos de un segundo
La velocidad no es una métrica de vanidad: influye en los rankings y en los ingresos. Este es el trabajo de rendimiento exacto que ejecutamos en cada build, en el orden de mayor importancia.
La mayoría de los sitios web lentos no lo son por razones misteriosas. Son lentos debido a un puñado de problemas predecibles apilados unos sobre otros, y se solucionan en un orden predecible. Cuando un cliente acude a nosotros con un tiempo de carga de tres segundos, rara vez necesitamos trucos exóticos. Necesitamos disciplina.
Esta es la misma lista de verificación que ejecutamos en cada proyecto de rendimiento, aproximadamente en orden de prioridad. Cada paso es económico en relación con su impacto, y la mayoría de los sites se sienten drásticamente más rápidos después de los tres primeros.
Mide antes de tocar nada
No puedes mejorar lo que no mides, y definitivamente no puedes demostrar una mejora sin una línea de base. Comenzamos cada proyecto con datos de campo, no solo con puntuaciones de laboratorio.
- Laboratorio — Lighthouse y WebPageTest para una captura controlada y repetible.
- Campo — métricas de usuarios reales (CrUX / RUM) para lo que la gente realmente experimenta.
- Presupuesto — un límite estricto por ruta, para que las regresiones se detecten en CI, no en producción.
Una puntuación de laboratorio de 100 no significa nada si tus usuarios reales utilizan teléfonos de gama media y redes inestables. Optimiza para el campo.
Elimina los recursos que bloquean el renderizado
La mayor victoria en la mayoría de los sites es sacar CSS y JavaScript de la ruta crítica. El navegador no puede renderizar hasta que haya terminado de analizar los recursos que bloquean el renderizado; por lo tanto, cuantos menos haya, más rápido aparecerá algo.
// defer everything that isn't critical
const load = () => import('./analytics.js');
if ('requestIdleCallback' in window)
requestIdleCallback(load);
else setTimeout(load, 2000);Incrusta la pequeña cantidad de CSS necesaria para el primer viewport, luego carga el resto de forma asíncrona. Pospón los scripts no críticos. El objetivo es un primer renderizado que no espere a nada que no sea absolutamente necesario.
Trata las imágenes como un presupuesto
Las imágenes suelen ser lo más pesado de una página y lo más fácil de hacer mal. Tres reglas cubren el noventa por ciento de los casos:
- Sirve formatos modernos — AVIF o WebP — con un fallback.
- Ajusta el tamaño de las imágenes a sus dimensiones de renderizado; nunca envíes una imagen hero de 3000px a un espacio de 600px.
- Aplica lazy-load a todo lo que esté debajo del pliegue y reserva espacio para evitar el desplazamiento de diseño (layout shift).
Almacena en caché en el edge
Una vez que la página es ligera, la siguiente pregunta es qué tan rápido llegan los bytes al usuario. Un CDN con cabeceras de caché sensatas convierte un viaje de 600 ms al origen en una respuesta de 30 ms desde el edge. Para el contenido dinámico, stale-while-revalidate ofrece respuestas instantáneas mientras se actualiza en segundo plano.
El rendimiento es una característica. Lo presupuestamos de la misma manera que presupuestamos cualquier otra parte de la build.
El resultado
En el proyecto que motivó este artículo, la página de inicio pasó de un largest contentful paint de 3.1s a 0.9s, y las conversiones orgánicas aumentaron de manera medible en un mes. Nada de esto fue magia: solo la lista de verificación anterior, aplicada en orden.
Si tu site se siente lento y no estás seguro de por dónde empezar, ponte en contacto: una auditoría breve suele mostrar los dos o tres cambios que más importan.