Tu web tarda 5 segundos en cargar. Ya perdiste al usuario.

Core Web Vitals son las métricas que Google usa para rankear y que determinan si tu sitio se siente rápido o lento:

LCP (Largest Contentful Paint): tiempo hasta que el elemento más grande de la pantalla se renderiza. Meta: bajo 2.5 segundos.

INP (Interaction to Next Paint): tiempo de respuesta a interacciones del usuario. Reemplazó a FID en 2024. Meta: bajo 200ms.

CLS (Cumulative Layout Shift): cuánto se mueve el layout mientras carga. Un botón que se desplaza cuando vas a clickearlo es CLS alto. Meta: bajo 0.1.

Medís estos números con PageSpeed Insights (gratuito, directo de Google) o con la integración de Chrome DevTools en la pestaña Performance.

Las imágenes representan entre el 60% y el 80% del peso total de una página promedio. La mayoría de los sitios las sirven sin comprimir, en formato JPEG o PNG, al tamaño original.

El stack correcto:

• Formato WebP o AVIF: 30-50% más liviano que JPEG con la misma calidad visual
• Compresión con Squoosh, ImageOptim o integrado en el pipeline de build
• loading="lazy" en todas las imágenes que no están above the fold
• width y height explícitos para evitar CLS mientras cargan
• srcset para servir tamaños distintos según la pantalla del dispositivo

Una imagen de hero de 2MB convertida a WebP suele quedar en 180-250KB. Esa diferencia en una conexión 4G son 3 segundos de diferencia.

El browser descarga el JS, lo parsea, lo compila y lo ejecuta. Cada KB de JavaScript tiene un costo mayor que el mismo KB de imagen porque requiere procesamiento de CPU.

Técnicas para reducir el bundle:

Tree shaking: el bundler elimina código que importás pero no usás. Requiere ES modules (import/export), no CommonJS (require).

Code splitting: dividir el bundle en chunks y cargar solo lo necesario por ruta. En React: React.lazy(() => import('./Component'))

Dynamic imports: cargar módulos pesados solo cuando se necesitan: const chart = await import('chart.js') — se carga solo cuando el usuario abre el panel de analytics.

Análisis del bundle: webpack-bundle-analyzer o el panel de Vite muestra exactamente qué está ocupando espacio. Muchas veces hay dependencias de 200KB que se pueden reemplazar por 2KB de código propio.

El caché evita que el browser descargue el mismo archivo dos veces. Sin caché configurado, cada visita descarga todo desde cero.

HTTP Cache headers:

• Assets con hash en el nombre (ej. main.a3f2b1.js): Cache-Control: public, max-age=31536000, immutable — el browser lo guarda 1 año
• HTML: Cache-Control: no-cache — siempre verifica si cambió, pero usa versión cacheada si no cambió
• API responses que no cambian frecuentemente: Cache-Control: public, max-age=300, stale-while-revalidate=60

Stale-while-revalidate: sirve la versión cacheada inmediatamente y actualiza en segundo plano. El usuario ve contenido al instante, la actualización llega en el próximo request.

Nginx, Cloudflare y la mayoría de los CDN configuran estos headers con pocas líneas de configuración.

Un servidor en Buenos Aires que recibe un request desde España tiene una latencia base de 200-250ms solo por la distancia física. Un CDN resuelve esto replicando tu contenido en edge nodes distribuidos globalmente.

Cómo funciona: Cloudflare, AWS CloudFront o Vercel tienen servidores en decenas de ciudades. El primer request va a tu servidor origen, que responde y le pasa la respuesta al edge. Todos los requests siguientes los sirve el edge desde su caché, a 10-30ms de latencia.

Qué poner en el CDN:

• Imágenes y videos (siempre)
• JS y CSS del frontend
• Assets estáticos en general
• Respuestas de API que son iguales para todos los usuarios (ej. listado de productos)

Qué NO poner en el CDN sin configuración adicional:

• Respuestas con datos del usuario
• Endpoints que escriben en la DB
• Requests que requieren autenticación

Si renderizás 10.000 filas en una tabla o 5.000 cards en un listado, el DOM tiene 10.000 nodos activos. Eso colapsa el browser: scroll lento, memoria alta, CPU al 100%.

Virtual scroll (o windowing) renderiza solo los elementos visibles en pantalla más un buffer. Si el usuario puede ver 20 filas, en el DOM hay 40. Los demás existen solo en memoria como datos.

Librerías:

• react-window o react-virtual para React
• @tanstack/virtual (agnóstico, 5KB gzipped)
• cdk/scrolling en Angular

Cuándo usarlo: listas de más de 500 elementos que no se paginan. Tablas de datos analíticos. Feeds infinitos.

El resultado: un feed de 50.000 items con virtual scroll usa la misma memoria que uno de 50. El scroll es fluido a 60fps independientemente del tamaño del dataset.