Skip to main content
Volver al centro de aprendizaje

¿Por qué las cosas en mi página aparecen más tarde?

La carga diferida es una técnica usada por desarrolladores web para retrasar la carga de cosas no importantes en la página. Cosas como imágenes, videos y contenido incrustado generalmente se cargan al final, o hasta que realmente se necesitan en la página.

Oct 20, 2025
¿Por qué las cosas en mi página aparecen más tarde?

Resumen: retraso de renderizado

  • El retraso de renderizado es el hueco entre que el navegador recibe el HTML y el usuario ve la página terminada. En casi todos los sitios modernos lo domina la ejecución de JavaScript, no el tránsito de red.
  • El mayor culpable son los scripts de terceros síncronos cargados en el head: tag manager, analítica y widgets de chat que bloquean el commit del árbol de renderizado.
  • Las métricas de Web Vitals (LCP, FID, INP) miden los síntomas observables, pero no te dicen qué script específico está retrasando tu página. El monitoreo en sesión del timing de ejecución de scripts sí.

Si alguna vez has visitado cualquier página web moderna, notarás que a veces las cosas en pantalla (como imágenes, elementos de entrada, etc.) se cargarán antes que otras partes del sitio. Las páginas web a menudo se cargarán en etapas, con algunas cosas apareciendo solo después de un retraso inicial. Este escalonamiento puede ser intencional para mejorar el rendimiento del sitio, pero también podría ser solo un efecto secundario de cómo tu navegador está procesando la página.

Si la parte lenta es la descarga en sí, revisa la unidad antes de comparar números. Un navegador que muestra MB/s y un plan de internet vendido en Mbps usan unidades distintas; Mbps, Mb/s y MB/s necesitan una conversión de 8 a 1.

Carga diferida

La carga diferida es una técnica usada por desarrolladores web para retrasar la carga de cosas no importantes en la página. Cosas como imágenes, videos y contenido incrustado generalmente se cargan al final, o hasta que realmente se necesitan en la página. En lugar de cargar ansiosamente todo de una vez (lo que puede saturar tu navegador con un montón de solicitudes), tu navegador esperará para cargar el contenido fuera de pantalla hasta que el usuario se desplace cerca de él. Al no cargar todo este contenido cada vez, la carga inicial de la página es mucho más rápida y se siente más ligera.

Por ejemplo, esta publicación de blog podría cargar nuestro banner superior e ícono de autor primero, pero retrasar la carga de las imágenes cerca del pie de página del sitio hasta que te desplaces a él. Esto acelera la carga inicial, ya que solo la primera imagen se está cargando.

Desde el lado de la experiencia del usuario, la carga diferida es claramente beneficiosa: ves las cosas importantes más rápido, y tu ancho de banda no se desperdicia en imágenes y videos que el usuario puede que nunca llegue a ver. Esto mejora el First Contentful Paint de la página, que es una métrica del navegador usada para cronometrar qué tan rápido aparece el primer elemento en pantalla.

Puede haber implementaciones negativas de la carga diferida, y en última instancia depende del desarrollador de la página asegurarse de que se use correctamente. Por ejemplo, cualquier contenido por encima del pliegue (es decir, cualquier contenido visible sin desplazarse hacia abajo en la página) no debería cargarse de forma diferida. Otra preocupación es el desplazamiento de diseño (layout shifting), que ocurre cuando el espacio de una imagen no está reservado en la página y esta se carga más tarde, empujando todo el contenido hacia abajo.

Renderizado del lado del cliente e hidratación

Las aplicaciones web modernas hoy en día son principalmente JavaScript, lo que significa que el contenido a menudo se renderiza y luego se muestra al usuario. En los frameworks de renderizado del lado del cliente (CSR) como React, Angular y Vue, el servidor envía una página HTML muy básica, y luego espera hasta que el navegador genere el contenido. Esto significa que, en la primera carga de una página, podrías ver solo una pantalla en blanco o un indicador de carga mientras el navegador está descargando y generando el contenido.

Esta implementación a menudo puede llevar a una percepción negativa del rendimiento de tu sitio, ya que los usuarios podrían pensar que nada se está cargando o que está tardando demasiado en cargar. La métrica First Contentful Paint de la que hablamos antes puede retrasarse significativamente en una situación de CSR puro, porque nada significativo aparece en la página hasta mucho, mucho más tarde.

Resolviendo esto con renderizado del lado del servidor

Para mitigar algunos de los retrasos de espera del renderizado del lado del cliente, muchos frameworks web usan el renderizado del lado del servidor (SSR). Esto significa que un servidor enviará una página web ya completamente desarrollada a tu navegador (así verás contenido de inmediato), y luego la hidratará más tarde con elementos más interactivos.

La hidratación sigue requiriendo generar ese contenido del navegador en el lado del cliente, pero simplemente significa que tus usuarios no se quedan mirando una pantalla en blanco mientras tanto. A su vez, mejora el rendimiento percibido de tu página y hace que la gente piense menos en “¿por qué esta página es tan lenta?”.

Dicho esto, el SSR y la hidratación aún pueden introducir problemas en un sitio si no se implementan correctamente. El problema del parpadeo de contenido ocurre cuando el servidor no conoce al usuario ni el contexto que ya tiene (por ejemplo, si el usuario ya ha iniciado sesión o no), y como resultado le ofrece una versión genérica del sitio. Una vez que el sitio se hidrata y se da cuenta de que el usuario ha iniciado sesión, podría reemplazar partes de la interfaz con contenido personalizado o actualizado. Aunque no es tan malo como una página completamente en blanco, estos cambios de contenido a mitad de camino pueden distraer y confundir momentáneamente al usuario.

Desde el punto de vista de la experiencia del usuario, el objetivo es minimizar el retraso antes de que los usuarios vean contenido útil. Si usas CSR, mantén tu JavaScript ligero e incluye un indicador de carga bien diseñado o un esqueleto para que tus usuarios sepan que hay contenido en camino. Aún mejor: usar SSR para la vista inicial asegura que los usuarios vean algo primero, y obtengan su contenido después.

Míralo en tu propio sitio

El retraso de renderizado suele culparse a la latencia de red, pero la causa real en los sitios modernos es el JavaScript de terceros no auditado que bloquea el proceso de renderizado. cside muestra exactamente qué scripts están retrasando tu página en cada sesión real de usuario. Nivel gratuito disponible.

Recursos que bloquean los renderizados

No todos los retrasos se deben a scripts; también pueden deberse a cómo tu navegador maneja recursos críticos como el CSS y las fuentes. Los navegadores no saben priorizar estos recursos de forma inherente, o podrían no darse cuenta de que el contenido está estilizado hasta más tarde, lo que provoca que el contenido parpadee en tu página con la fuente o el estilo incorrecto.

El CSS es el clásico por excelencia entre los problemas de bloqueo de renderizado. Por lo general, los navegadores retrasan el renderizado del contenido de la página hasta que el CSS se descarga y procesa, pero si tu archivo CSS es demasiado grande o demasiado complejo, cualquier elemento que dependa de ese archivo CSS aparecerá tarde, hasta que se cargue. Mantener tu CSS optimizado y el estilo de diseño básico en su sitio hace que el contenido aparezca antes y mejora el tiempo de carga percibido por el usuario.

La fuente de un sitio también puede retrasar la aparición del texto, aunque a menudo de formas más sutiles. Cuando un sitio usa una fuente personalizada (mediante @font-face, o algo como Google Fonts), los navegadores la gestionan con cuidado para evitar que aparezca una fuente de reserva. Los navegadores implementaron “el parpadeo de texto invisible”, lo que significa que el texto está oculto hasta que se carga el archivo de la fuente. El texto en esencia ya está ahí, en la página, simplemente no puedes verlo. Y si tu fuente tarda demasiado en cargarse, el usuario no verá ninguna palabra.

Equilibrar rendimiento con experiencia

Los desarrolladores web deberían aspirar a ofrecer la página más rápida posible sin sorprender al usuario con contenido sin estilo, texto que falta o tiempos de carga largos. Cada elemento retrasado en una página debería tener una buena razón para estarlo, y el retraso debería gestionarse en la interfaz mediante indicadores de carga y marcadores de posición.

Simon Wijckmans
Founder & CEO

Founder and CEO of cside. Previously a product manager on Cloudflare Page Shield (now Cloudflare Client-Side Security). Co-chair of the W3C Anti-Fraud Community Group and a Forbes 30 Under 30 honoree. Building accessible security against client-side attacks, web security is not an enterprise-only problem.

Monitoriza y protege tus scripts de terceros

Obtén visibilidad y control completos sobre cada script que se entrega a tus usuarios, para mejorar la seguridad y el rendimiento del sitio.

Empieza gratis o prueba Business con una versión de prueba de 14 días.

Interfaz del panel de cside que muestra la monitorización de scripts y el análisis de seguridad
Reservar una demo

¿Quieres verlo en detalle con un ingeniero?

Treinta minutos, sobre tu propio sitio. Nada de diapositivas.

Te enseñaremos:

Qué scripts de terceros se están ejecutando ahora mismo en tu sitio
En qué punto estás con los requisitos 6.4.3 y 11.6.1 de PCI DSS
Qué parte de tu tráfico son bots y agentes de IA

¿Prefieres mandarnos una pregunta?

Buscando huecos libres…

Solo humanos de verdad. Nos daríamos cuenta.

¿Problemas para reservar? Abrir el calendario en una pestaña nueva

¿Qué quieres resolver?

Cuéntanoslo en una línea y te responderemos con algo útil, no con un discurso genérico.

Solemos ayudar con:

Ver qué scripts de terceros se ejecutan en tu sitio
Evidencias para PCI DSS 6.4.3 y 11.6.1
Bots, agentes de IA y robo de cuentas

¿Prefieres reservar una hora? Elegir un hueco