Velocidad de página

La velocidad de página es uno de esos temas donde el consejo popular — “hazla más rápida” — es técnicamente correcto y operativamente inútil. Lo que importa es saber de dónde salen realmente las pérdidas de velocidad, cuánto cuesta cada compuerta del pipeline de carga, y qué arreglos rinden de verdad y cuáles son puro teatro.

Este artículo cubre el panorama amplio de la velocidad de página: qué miden TTFB, FCP, LCP, INP y CLS, dónde suelen fallar y la secuencia de arreglos que mueve de forma consistente rankings y conversión. El artículo previo (Core Web Vitals) entra a fondo en las tres métricas de ranking de Google; este abre el plano para ver el pipeline completo.

“El arreglo que entrega ROI rara vez es el más vistoso para presentar. La mayoría de las victorias de velocidad vienen de quitar cosas — scripts de terceros, imágenes sobredimensionadas, JavaScript que bloquea — no de agregar trucos de optimización ingeniosos.”

Las cinco compuertas de la velocidad de página

Cada carga de página pasa por cinco compuertas de rendimiento. Una página rápida lo es en las cinco; una página lenta normalmente falla feo en una sola y las demás enmascaran el problema.

Compuerta 1: Respuesta del servidor (TTFB)

Time to First Byte es todo lo que ocurre antes de que el navegador tenga el primer byte de HTML para renderizar. Es el cimiento: un TTFB lento le pone techo a cada métrica río abajo, porque el reloj del LCP no puede arrancar hasta que la pintura pueda empezar.

Qué suele hacer lento al TTFB

• Servidor de origen lento. Hosting compartido barato, VPS subdimensionado, origen de una sola región sirviendo a usuarios globales.
• Sin CDN. Cada request cruza el planeta hasta tu origen en lugar de resolverse en un nodo del edge.
• Server-side rendering con cachés frías. Cada request reconstruye la página desde cero.
• Consultas pesadas a la base de datos en cada carga: lookups de producto sin caché, búsquedas sin índice, patrones N+1 de ORM.
• APIs de terceros lentas en la ruta de render: llamar a un servicio remoto de forma síncrona antes de responderle al usuario.

Qué arregla el TTFB más rápido

• Pon el sitio detrás de un CDN global con caché en el edge (Cloudflare, Fastly, Vercel, Netlify).
• Cachea con agresividad en el CDN: TTL largo en estático, stale-while-revalidate en dinámico.
• Saca los cómputos caros de la ruta crítica de render; precómputalos o pásalos a procesos en background.
• Agrega caché e índices a las consultas de base de datos que se disparan en cada carga.
• Usa HTTP/2 o HTTP/3 y activa compresión (Brotli o gzip).

Compuerta 2: Primera pintura (FCP)

FCP es el momento en que el navegador pinta cualquier cosa visible: texto, imagen, SVG, incluso un color de fondo. Es la primera señal al usuario de que la página está viva.

Qué suele hacer lento al FCP

• CSS que bloquea el render. El navegador parsea el HTML, se topa con un link de stylesheet y deja de pintar hasta que el CSS se descarga y se parsea.
• JavaScript que bloquea el render en el head sin async ni defer.
• Scripts de terceros síncronos (el infractor más habitual: analítica, A/B testing, gestión de consentimiento).
• Frameworks de CSS pesados que envían estilos sin usar a cada página.
• Fuentes críticas con font-display: block: el texto queda invisible hasta que llega la fuente.

Qué arregla el FCP más rápido

• Inyecta CSS crítico inline para el contenido arriba del fold; carga el resto de forma asíncrona.
• Mete async o defer en cada script del head.
• Audita los tags de terceros sin piedad: en casi cualquier sitio se puede quitar la mitad sin que nadie lo note.
• Usa font-display: swap con un fallback del sistema para que el texto se pinte de inmediato.
• Haz preconnect a los orígenes externos necesarios para que el DNS y el TLS no bloqueen.

Compuerta 3: Contenido principal (LCP)

LCP es el momento en que termina de renderizarse el elemento más grande arriba del fold. En la mayoría de las páginas es la imagen del hero; en páginas con mucho texto puede ser el H1 o un bloque grande de párrafo. La lista completa de arreglos de LCP vive en el artículo de Core Web Vitals; la versión corta es: optimiza la imagen del hero (formato correcto, tamaño correcto, con preload, sin lazy-loading) y desbloquea la ruta de render.

Compuerta 4: Interactividad (INP)

INP mide, a lo largo de toda la sesión, la peor latencia entre cualquier acción del usuario y la siguiente pintura visible. Una página puede tener un LCP excelente y aun así sentirse rota si cada clic tarda 600 ms en responder. Sustituye a la antigua FID, que solo medía la primera interacción.

Qué suele hacer lento al INP

• Tareas largas que bloquean el hilo principal: el handler de JavaScript no puede correr hasta que termine la tarea actual.
• Hidratación grande de framework en el cliente: React/Vue/Angular siguen hidratando cuando el usuario hace clic.
• Llamadas de red síncronas al hacer clic: el handler espera al fetch antes de pintar feedback.
• Jank en animaciones sobre propiedades que disparan layout.
• Scripts de terceros que corren en cada interacción (analítica en clic, widget de chat, herramientas de session replay).

Qué arregla el INP más rápido

• Audita las tareas largas en la pestaña Performance de DevTools y trocea cualquier cosa por encima de 50 ms.
• Aplica code splitting a las rutas y haz lazy-load de los componentes que no se necesitan en la primera pintura.
• Muestra UI optimista al hacer clic (skeleton, estado de botón presionado) para que el feedback se pinte antes de cualquier llamada de red.
• Usa requestIdleCallback o startTransition de React para diferir el trabajo no urgente.
• Recorta los scripts de terceros en las superficies de interacción: la analítica que se dispara en cada scroll es veneno para INP.

Compuerta 5: Estabilidad visual (CLS)

CLS mide cuánto se mueve el layout mientras la página carga o mientras el usuario interactúa. La lista detallada de arreglos vive en el artículo de Core Web Vitals. La regla del 90%: pon width y height en cada imagen e iframe, reserva contenedores de tamaño fijo para anuncios y embeds que se cargan dinámicamente e inyecta los banners por debajo del contenido existente, nunca por encima.

La secuencia de arreglos de velocidad de página (orden de prioridad)

Cuando heredas un sitio lento, trabaja en este orden — cada paso compone con el anterior:

• 1. Imagen del hero y elemento LCP. Formato correcto (WebP/AVIF), dimensiones explícitas, con preload, sin lazy-loading. El arreglo de mayor apalancamiento en la mayoría de los sitios.
• 2. Auditoría de scripts de terceros. Lista cada tag de script, consigue el caso de negocio de cada uno y elimina los que no tienen dueño claro. Las etiquetas de marketing se acumulan con los años; borrar la mitad casi siempre mejora LCP e INP a la vez.
• 3. CDN + caché en el edge. Si el sitio no está en un CDN global, ese es el arreglo de TTFB más fácil disponible. Gratis o de bajo costo en Cloudflare para la mayoría de los sitios.
• 4. Optimización de imágenes en todo el sitio. Migra todas las imágenes a WebP/AVIF, sirve tamaños responsivos vía srcset y aplica lazy-load por debajo del fold.
• 5. Optimización de CSS y fuentes. CSS crítico inline y el resto asíncrono; font-display: swap; hacer subset de las fuentes a los glyphs necesarios.
• 6. Tamaño de bundle y code splitting. El arreglo de INP: suele ser un proyecto de ingeniería de 2 a 4 semanas, no un arreglo de contenido.
• 7. Monta RUM (monitoreo real de usuario) vía el paquete npm web-vitals para cazar las regresiones antes del retraso de 28 días de Search Console.

Errores comunes en velocidad de página

• Optimizar para Lighthouse en vez de para usuarios reales. Lighthouse corre en un entorno controlado; no es como tus usuarios viven la página. Cree primero a los datos reales de usuario de Search Console y deja los puntajes de Lighthouse en segundo plano.
• Aplicar lazy-load a la imagen del hero. El lazy-loading es excelente para contenido por debajo del fold; en el elemento LCP impide activamente un buen puntaje.
• Considerar los scripts de terceros como intocables. Cada script en el sitio tiene un dueño que puede defender su existencia; pero la mayoría no podrá hacerlo.
• Saltarse el CDN porque “el sitio es rápido en local”. Lo de local da igual. Los usuarios reales están en redes inestables repartidas en varios continentes.
• Adelantar trucos de optimización (preload, prefetch, prerender) sin arreglar el cuello de botella real. Precargar un script que deberías borrar es puro teatro.
• Lanzar el arreglo y no medir la regresión. Sin RUM, el siguiente deploy puede romper en silencio lo que ya habías arreglado.

El veredicto

La velocidad de página en 2026 son cinco compuertas: respuesta del servidor, primera pintura, contenido principal, interactividad y estabilidad visual. Una página rápida lo es en las cinco. La secuencia de arreglos — imagen del hero → scripts de terceros → CDN → imágenes en todo el sitio → CSS/fuentes → bundles → RUM — mueve a la vez los Core Web Vitals y la conversión. La velocidad es un factor de ranking directo pequeño; es un factor de conversión mucho más grande; y la matemática de la conversión suele justificar la inversión en ingeniería antes que la del ranking.