Un sitio que antes cargaba bien ahora se siente lento. La primera pantalla tarda unos segundos y los clics responden con retraso.

«De repente» significa que algo cambió hace poco: normalmente se agregó una imagen grande, se acumularon datos, un proyecto en plan gratuito se durmió o se le acopló un script de terceros. Abajo tienes un checklist causa por causa.

> No existe una solución mágica única. El motivo varía de un sitio a otro. Esta guía te ayuda a acotar al culpable. Mide primero (Paso 0) y corrige solo la causa que coincida.

Paso 0. Diagnostica en 30 segundos — encuentra dónde está la lentitud

Mide antes de adivinar.

  1. Entra en https://pagespeed.web.dev/, pega la URL de tu sitio y haz clic en Analyze.
  2. Fíjate en el LCP (Largest Contentful Paint): 2,5 s o menos es bueno, más de 4,0 s es malo (umbrales de web.dev).
  3. La lista de Opportunities / Diagnostics nombra problemas concretos: "properly size images", "reduce unused JavaScript". Esos son tus sospechosos.

¿Tienes Chrome? F12 → pestaña Lighthouse → Analyze page load te da el mismo informe. Sin instalar nada.

Causa 1. Las imágenes son demasiado grandes (lo más común)

Subes tal cual una foto del móvil de 4 MB y esa sola imagen arrastra toda la página. Si el Paso 0 marcó las imágenes, empieza por aquí.

En un sitio Next.js, con solo cambiar <img> por el Image de next/image se optimizan automáticamente el tamaño, la calidad y el formato (WebP/AVIF). Las imágenes fuera de pantalla se cargan de forma diferida (lazy-load) por defecto, y añadir width/height reserva el espacio para que el diseño no dé saltos.

jsx

import Image from 'next/image'

<Image src="/hero.png" width={1200} height={630} alt="Hero image" priority />
  • Añade priority solo a la imagen hero de arriba para que cargue primero (renombrado a preload en Next.js 16).
  • Todas las demás imágenes se cargan de forma diferida automáticamente, sin opciones extra.

¿Usas una herramienta de IA para programar (Cursor, Lovable, v0)? Dile: «Reemplaza cada etiqueta <img> por el componente Image de next/image, y añade priority solo a la imagen hero de arriba.»

¿No usas Next.js? El principio es el mismo: comprime las imágenes (por ejemplo con squoosh.app) y conviértelas a WebP antes de subirlas.

Causa 2. Se acumularon datos y la BD escanea toda la tabla

Si al principio iba rápido pero se volvió lento cuando las publicaciones/usuarios/pedidos crecieron a miles, lo más probable es que la culpa sea de consultas sin índice. Sin un índice, la base de datos lee la tabla de arriba abajo en cada petición (un escaneo completo).

Solución en Supabase (Postgres):

  1. Panel de Supabase → Advisors → Query Performance (o Reports → Query Performance) para ver las consultas lentas y las columnas por las que filtran.
  2. Agrega un índice a las columnas por las que filtras u ordenas con frecuencia. En el SQL Editor:
sql

create index idx_posts_user_id on posts (user_id);
  1. Si la tabla ya es grande en producción, añade concurrently para que no bloquee la tabla para escrituras:
sql

create index concurrently idx_posts_created_at on posts (created_at);

Supabase también tiene un Index Advisor que recomienda qué índices agregar (Query Performance → elige una consulta → pestaña Indexes). Lee la sugerencia y luego ejecuta tú mismo el SQL de arriba.

Causa 3. Un proyecto en plan gratuito se durmió (solo la primera petición es lenta)

«Solo la primera carga tras un rato es lenta, luego va bien» → eso es una señal de sueño / arranque en frío (cold start).

  • El plan Free de Supabase puede pausar un proyecto tras unos 7 días de poca actividad. Una vez pausado, la primera petición que lo despierta es lenta o falla; restaura (Restore) el proyecto desde el panel para recuperarlo.
  • Las funciones serverless (Vercel, etc.) también arrancan en frío lentamente cuando llevan un rato sin recibir llamadas.

Qué hacer: para un servicio con poco tráfico, accede a él periódicamente para mantenerlo despierto, o pásate a un plan de pago siempre activo si tienes tráfico real. Saber que «la primera petición lenta de vez en cuando» es el sueño normal del plan gratuito —y no un error— te ahorra perseguir fantasmas.

Causa 4. Un script pesado o un widget de terceros bloquea el renderizado

Si hace poco añadiste un widget de chat, anuncios, analítica, fuentes web o un embed de YouTube, puede estar bloqueando tu primer renderizado. web.dev señala que los scripts síncronos y el CSS que bloquea el render en el <head> retrasan el renderizado.

  • Aplaza los scripts externos no esenciales con async/defer, o cárgalos al final de la página.
  • Los scripts que aparecen en "Reduce the impact of third-party code" de PageSpeed son sospechosos claros. Quítalos de uno en uno para dar con el culpable.

¿Sigues atascado?

  • Pega los 3 principales hallazgos de tu informe de PageSpeed del Paso 0 directamente en tu herramienta de IA y pídele que los solucione. Los hallazgos de Lighthouse son lo bastante concretos como para servir de instrucciones listas para usar.
  • Recuerda cuándo se volvió lento y qué cambiaste entonces: revertir el deploy/commit reciente suele ser el camino más rápido.

De nuevo: esto es un checklist para acotar al culpable, no un arreglo de una línea. Trabájalo en orden — mide (Paso 0) y aplica solo la causa que coincida.