Logos<Logos/>

Por qué tu sitio tarda 8 segundos en cargar (y cómo arreglarlo)

Back to blog

January 8, 2026

performancecore-web-vitalsnext-jsseo

El tiempo de carga no es un detalle técnico

Es la primera impresión que da tu negocio.

Según datos de Google, el 53% de los usuarios abandona un sitio móvil si tarda más de 3 segundos en cargar. No importa cuán buena sea tu oferta o cuán bien esté diseñada tu página: si el usuario se fue antes de verla, no existe.

Y el problema es doble: la velocidad afecta no solo la experiencia del usuario, sino también el SEO. Google usa las métricas de Core Web Vitals como señal de ranking. Un sitio lento baja en los resultados de búsqueda, lo que se traduce en menos tráfico orgánico.

Qué miden los Core Web Vitals

Google consolidó tres métricas clave para medir la experiencia real del usuario:

| Métrica | Qué mide | Objetivo | | ----------------------------------- | ----------------------------------------------------- | -------- | | LCP — Largest Contentful Paint | Cuánto tarda el elemento principal en renderizarse | < 2.5 s | | CLS — Cumulative Layout Shift | Cuánto se mueve el contenido mientras carga | < 0.1 | | INP — Interaction to Next Paint | Cuánto tarda la página en responder a una interacción | < 200 ms |

Un sitio puede verse hermoso en Figma y aun así destrozar los Core Web Vitals si el código detrás no está optimizado.

Las 4 causas más comunes de lentitud

1. Imágenes sin optimizar

Es el culpable número uno. Una foto de producto de 4 MB en formato JPEG que se muestra en un card de 300px de ancho es un desperdicio monumental de ancho de banda.

La solución: usar formatos modernos como WebP o AVIF, y componentes que sirvan el tamaño correcto según el dispositivo.

En Next.js, el componente <Image> hace esto automáticamente:

import Image from "next/image";

// ✅ Optimizado: Next.js genera WebP, dimensiona según viewport,
// y carga de forma lazy por defecto
<Image
  src="/hero.jpg"
  alt="Descripción del negocio"
  width={1200}
  height={600}
  sizes="(max-width: 768px) 100vw, 50vw"
  priority // solo para imágenes above the fold
/>;

// ❌ Sin optimizar: carga el archivo original, en cualquier tamaño
<img src="/hero.jpg" alt="..." />

La diferencia en payload puede ser de 10x o más.

2. JavaScript bloqueante

Cada kilobyte de JavaScript que cargás en el head del documento bloquea el renderizado. El navegador no puede mostrar nada hasta que descarga, parsea y ejecuta ese script.

El error más común es cargar librerías enteras cuando solo se usa una función:

// ❌ Importa toda la librería (cientos de KB)
import _ from "lodash";
const sorted = _.sortBy(items, "name");

// ✅ Solo la función que necesitás
import sortBy from "lodash/sortBy";
const sorted = sortBy(items, "name");

En React, los Server Components de Next.js eliminan este problema de raíz: el código del servidor nunca viaja al navegador. Solo llega HTML listo para renderizar.

// Este componente NO agrega JS al bundle del cliente
// El fetch, la lógica y el render ocurren en el servidor
export default async function ProductList() {
  const products = await fetchProducts(); // server-only
  return (
    <ul>
      {products.map((p) => (
        <li key={p.id}>{p.name}</li>
      ))}
    </ul>
  );
}

3. Fuentes web cargadas de forma ingenua

Las fuentes pueden bloquear el renderizado si se cargan de forma sincrónica. El FOUT (Flash of Unstyled Text) o el FOIT (Flash of Invisible Text) son síntomas de este problema.

/* ❌ Bloqueante: el navegador espera antes de mostrar texto */
@import url("https://fonts.googleapis.com/css2?family=Inter");

<!-- ✅ No bloqueante: preconnect + display=swap -->
<link rel="preconnect" href="https://fonts.googleapis.com" />
<link
  href="https://fonts.googleapis.com/css2?family=Inter&display=swap"
  rel="stylesheet"
/>

Mejor aún: en Next.js, next/font optimiza las fuentes automáticamente, las sirve desde el mismo dominio y elimina el layout shift:

import { Inter } from "next/font/google";

const inter = Inter({
  subsets: ["latin"],
  display: "swap",
  variable: "--font-inter",
});

4. Recursos de terceros sin control

Google Tag Manager, chatbots, píxeles de Facebook, widgets de reviews: cada script de terceros que agregás es una dependencia que no podés controlar. Uno solo puede agregar 500ms de latencia.

Buenas prácticas:

  • Cargar scripts de terceros con strategy="lazyOnload" o strategy="afterInteractive" en Next.js
  • Revisar periódicamente qué scripts están activos y si realmente se usan
  • Nunca poner scripts de analytics en el <head> bloqueante
import Script from "next/script";

// ✅ Carga después de que la página es interactiva
<Script
  src="https://www.googletagmanager.com/gtag/js"
  strategy="afterInteractive"
/>;

Cómo medir antes de optimizar

No optimices a ciegas. Medí primero:

  • PageSpeed Insights — análisis real con datos de usuarios de Chrome, gratis
  • Lighthouse (DevTools → pestaña Lighthouse) — auditoría completa con recomendaciones
  • WebPageTest — análisis detallado con filmstrip visual de la carga
  • Chrome DevTools → Network — filtrá por tipo de recurso y ordená por tamaño

Primero medí, después optimizá. Sin datos, solo estás adivinando.

El impacto en números

Para ponerlo en perspectiva: Walmart descubrió que por cada segundo de mejora en tiempo de carga, las conversiones aumentaban un 2%. Amazon calculó que 100ms adicionales de latencia les costaba el 1% de las ventas.

Para un negocio pequeño, estas cifras se traducen en algo más simple: un sitio rápido genera más confianza, más consultas y más ventas. Uno lento los manda directo a la competencia.

Si querés saber cómo está rindiendo tu sitio actual, estamos a un mensaje de distancia.