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 de verdad las pérdidas de velocidad, cuánto cuesta cada compuerta del pipeline de carga y qué arreglos rinden en serio frente a 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 fallan normalmente y la secuencia de arreglos que sube rankings y conversión de forma consistente. El artículo anterior (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 meter 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 suele fallar feo en una sola y las demás disimulan el problema.

Compuerta 1: Respuesta del servidor (TTFB)

Time to First Byte es todo lo que pasa 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 que viene después, porque el reloj del LCP no arranca hasta que la pintura puede empezar.

Qué hace lento al TTFB normalmente

• Servidor de origen lento. Hosting compartido barato, VPS sin recursos suficientes, origen en una sola región atendiendo a usuarios de todo el mundo.
• Sin CDN. Cada request cruza el planeta hasta tu origen en vez 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: búsquedas de producto sin caché, queries 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 de forma agresiva 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.
• Mete caché e índices a las queries 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é hace lento al FCP normalmente

• 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 común: analítica, A/B testing, gestión de consentimiento).
• Frameworks de CSS pesados que mandan 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

• Mete el CSS crítico inline para el contenido arriba del fold y carga el resto en asíncrono.
• Pon async o defer en cada script del head.
• Audita los tags de terceros sin piedad: en casi cualquier sitio puedes 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 DNS y 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 está 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. Reemplaza a la vieja FID, que solo medía la primera interacción.

Qué hace lento al INP normalmente

• Tareas largas que bloquean el hilo principal: el handler de JavaScript no puede correr hasta que termine la tarea actual.
• Hidratación pesada 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 parte en pedazos 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 que no es urgente.
• Recorta los scripts de terceros en las superficies de interacción: la analítica que se dispara en cada scroll es veneno para el 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 está 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 los anuncios y embeds que cargan en dinámico e inyecta los banners debajo del contenido existente, nunca arriba.

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

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

• 1. Imagen del hero y elemento LCP. Formato correcto (WebP/AVIF), dimensiones explícitas, con preload, sin lazy-loading. El arreglo que más rinde en la mayoría de los sitios.
• 2. Auditoría de scripts de terceros. Lista cada tag de script, pídele a alguien 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, es el arreglo de TTFB más fácil que existe. 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 debajo del fold.
• 5. Optimización de CSS y fuentes. CSS crítico inline y el resto en asíncrono; font-display: swap; subset de las fuentes a los glyphs que de verdad usas.
• 6. Tamaño de bundle y code splitting. El arreglo de INP: normalmente es un proyecto de ingeniería de 2 a 4 semanas, no un arreglo de contenido.
• 7. Monta RUM (monitoreo real de usuario) con 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. Hazle caso primero a los datos reales de usuario de Search Console y deja los puntajes de Lighthouse en segundo plano.
• Aplicarle lazy-load a la imagen del hero. El lazy-loading es excelente para contenido debajo del fold; en el elemento LCP te bloquea cualquier buen puntaje.
• Tratar los scripts de terceros como intocables. Cada script del sitio tiene un dueño que en teoría puede defenderlo; la mayoría, en la práctica, no puede.
• Omitir 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 — sube 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 los números de la conversión casi siempre justifican la inversión en ingeniería antes que los del ranking.