Allá por el año 2005, uno de mis profes de informática nos dijo que la mayoría de los estudiantes abandonan una página si demoraba más de 12 segundos en cargarse. Esto se quedó conmigo por mucho tiempo, pero le empecé a prestar más atención en los últimos 2 años, desde que di la charla de Web Vitals en la WebConf.

Hoy en día, las personas tienen una capacidad de atención extremadamente corta donde necesitamos el acceso a contenido de forma rápida y constante. No solo por la cantidad de contenido sino también por cómo avanzó la tecnología. Debido a esto, los desarrolladores web deben obsesionarse con el rendimiento de la carga inicial de la página. Porque, spoiler alert: cuando tu sitio es lento, tus usuarios se van.

Repasemos un cachito antes de seguir, por si no fueron a la WebConf:
Google usa las métricas de Core Web Vitals para determinar el ranking de tu sitio.

¿Qué son los Core Web Vitals?

Son métricas que miden la experiencia del usuario en términos de velocidad, interactividad y estabilidad visual. Por ejemplo:

• LCP (Largest Contentful Paint): Mide cuánto tarda en aparecer lo más importante de la página (como una imagen grande o un título).
• FID (First Input Delay): Mide cuánto tarda la página en responder al primer clic o interacción del usuario.
• CLS (Cumulative Layout Shift): Mide si los elementos de la página se mueven inesperadamente mientras carga.

Por qué importa el rendimiento

Ahora, ¿por qué debería importarte el rendimiento en el frontend? Bueno, te doy algunas razones rápidas:

1. Los usuarios odian esperar. Si tu página tarda más de 3 segundos en cargar, más del 50% de las personas se van.

2. Google también odia la lentitud. Las métricas de Web Vitals son clave para el SEO.

3. Afecta tu negocio. Un retraso en la carga de la app puede reducir las ventas.

¿Te convencí? Bien. Sigamos.

Optimización de recursos

El primer paso es reducir el tiempo de carga de los recursos.

Imágenes

¿Sabías que las imágenes suelen ser el recurso más pesado en una página? Usa formatos modernos como WebP para ahorrar espacio sin perder calidad, y no cargues todas las imágenes de golpe: aplica lazy loading para que se descarguen solo cuando el usuario las necesita.

Fuentes

¿Te encantan las fuentes personalizadas? A mí también. Pero pueden ser un problema. Limita la cantidad de fuentes que usas, precarga las esenciales, y considera usar fuentes del sistema si es posible.

Videos

Si tienes videos en tu sitio, asegúrate de optimizarlos. Usa placeholders en lugar de cargarlos inmediatamente y, si se puede, mejor incrustarlos desde servicios externos como YouTube.

Técnicas de carga eficiente

Aquí es donde las cosas se ponen interesantes. Hay un montón de formas de mejorar cómo y cuándo se cargan los recursos de tu página.

Supongamos que tenemos el siguiente ejemplo que queremos optimizar:

• Code Splitting: divide tu JavaScript en partes más pequeñas y carga solo lo necesario. Por ejemplo, usa un loader que importe los componentes de forma asincrónica, permitiendo que se carguen solo cuando se accede a la ruta.

• Lazy Loading: aplica esta técnica a todo lo que puedas: imágenes, scripts, componentes.

• Prefetching: carga recursos que el usuario podría necesitar más adelante, antes de que los pida.

Reducción de JavaScript

JavaScript es genial, pero demasiado puede ser un problema. Tree Shaking elimina del código final las partes que no se usan, como funciones o módulos. Utiliza herramientas como Webpack o Rollup para analizar el código y detectar automáticamente lo que realmente se necesita, haciendo que las aplicaciones sean más ligeras y rápidas.
Puede que tu framework ya esté haciendo esto por ti si usas Next o Angular Universal.

Supongamos que tenemos este archivo products.js en la carpeta Utils

Pero en el archivo cart.js solo llamamos dos funciones del archivo products.js

Lo que se buildeara sera solo el codigo utilizado, descartando las funciones que no estamos llamando en cart.js

Caché

Usar el caché del navegador es como darle al usuario un atajo. Configura tus recursos estáticos para que no se descarguen cada vez que alguien visite tu página. Puedes usar el almacenamiento local del navegador (localStorage) o el almacenamiento en memoria para guardar datos como productos, detalles del carrito o páginas cargadas previamente.

SSR, SSG y CSR

Mientras buscamos diversas formas de optimizar el rendimiento, debemos contemplar también tres estrategias: SSR (Server-Side Rendering), SSG (Static Site Generation) y CSR (Client-Side Rendering).

• SSR: el servidor genera el HTML completo en el momento en que el usuario visita la página.
  Es como un chef que cocina todo a último momento. Si hay muchas órdenes, se puede saturar.

• SSG: genera las páginas de HTML durante el tiempo de compilación.
  Es como si preparara todo por adelantado para tenerlo listo en cuanto se lo pidan.

• CSR: el servidor envía un documento HTML vacío (o casi vacío) al navegador, junto con un montón de JavaScript, que construye la interfaz completa directamente en el navegador.
  Es como si te dieran los ingredientes y una receta, y te dijeran: "cocínalo tú mismo".

¿Cuándo usar cada uno?

SSR:

• Cuando necesitas datos dinámicos que cambian por usuario (carritos de compra, dashboards, resultados de búsqueda).
• Cuando el SEO es fundamental para contenido cambiante.

SSG:

• Para sitios con contenido que cambia poco o de forma predecible (blogs, landing pages, documentación), aprovechando la caché para entregar contenido extremadamente rápido.

CSR:

• Cuando necesitas una experiencia interactiva, como en dashboards o aplicaciones complejas.
• Nota: puede necesitar complementos para mejorar el SEO o reducir el tiempo de carga inicial.

Optimizando llamadas a la API

No solo mejoramos el rendimiento y la interacción desde el front, también debemos prestar atención a cómo nos comunicamos con el back. Optimizar la forma en la que hacemos requests es esencial para mejorar la performance, ya que podemos crear cuellos de botella, incrementar la demora de respuesta y sobrecargar el servidor.

Qué podemos hacer:

• Batching: combinar varias solicitudes en una sola. En vez de mandar múltiples requests, agrúpalas en una sola llamada.

Desde el front podemos hacer:

Y desde el back si tenemos acceso y podemos modificarlo:

• Caching: guardar datos comunes en memoria/local (como mencionamos antes, pero en este caso cacheamos data en vez de assets).

• Lazy loading: cargar datos solo cuando son necesarios, igual que con las imágenes.

Herramientas para medir y mejorar

Ahora que ya sabes qué hacer, necesitas herramientas para saber si estás haciendo las cosas bien. Mis favoritas:

• Chrome DevTools: una herramienta esencial para identificar cuellos de botella en el rendimiento de tu sitio. Con su pestaña Performance, puedes analizar qué tareas están tardando más de lo necesario, como la ejecución de scripts o el renderizado de elementos.
  Además, Throttling te permite simular condiciones reales como conexiones lentas o dispositivos menos potentes, ideal para diagnosticar problemas en escenarios del mundo real.
  Finalmente, Lighthouse no solo te da un puntaje de rendimiento, sino que también ofrece recomendaciones claras y accionables para mejorar métricas clave como LCP, FID y CLS.

• WebPageTest: para analizar el tiempo de carga desde diferentes ubicaciones.

• UnLighthouse: una herramienta de código abierto que ejecuta informes de Lighthouse en todas las páginas de tu sitio web de manera paralela.

Conclusión

El rendimiento en el frontend no es solo un tema técnico. Si tu sitio no es rápido, pierdes usuarios, dinero y oportunidades. Pero lo bueno es que con pequeños cambios puedes marcar una gran diferencia.

Mi consejo final: no intentes hacer todo a la vez. Empieza con un cambio. Optimiza esas imágenes pesadas o elimina scripts innecesarios.