El contenido fallback mientras la isla se resuelve
Entre que la página estática se pinta y que la server island llega desde el servidor hay un instante en el que el hueco necesita algo que mostrar. El slot=fallback define ese marcador provisional: un esqueleto, un valor por defecto plausible o una red de seguridad que sobrevive incluso sin JavaScript. Diseñar bien esa espera es diseñar una página coherente en sus dos fases.
El hueco necesita algo mientras tanto
Recuerda la secuencia del apartado anterior: el navegador recibe el HTML estático, lo pinta, y solo entonces pide la isla al servidor. Ese segundo viaje toma tiempo —una ida y vuelta de red, más lo que tarde el servidor en renderizar—. Durante esos milisegundos, ¿qué ocupa el lugar de la isla?
Si no dices nada, el lugar queda vacío: un salto visible cuando el fragmento real irrumpe y desplaza lo que había debajo. Ese salto es exactamente el CLS que los niveles de rendimiento te enseñaron a temer.
El fallback existe para evitarlo: es el contenido que viaja dentro del HTML estático, se pinta al instante junto al resto de la página y se mantiene en su sitio hasta que la isla llega y lo sustituye.
Piensa en la magnitud del intervalo. En una red rápida, el fallback vive unas pocas decenas de milisegundos y casi no se percibe; en una conexión móvil pobre o con un servidor de borde en arranque en frío, puede durar cientos.
El fallback no es, por tanto, un adorno para el caso ideal: es lo que gobierna la experiencia en el caso real, el del usuario con mala cobertura, que es precisamente a quien más le importa que la página no dé bandazos.
slot=“fallback”: el marcador visible
El mecanismo reutiliza los slots con nombre del nivel 5. Cualquier elemento que pongas como hijo del componente diferido con el atributo slot="fallback" se convierte en el marcador que se muestra mientras la isla se resuelve.
---import CarritoResumen from '../components/CarritoResumen.astro';---<CarritoResumen server:defer> <span slot="fallback" class="carrito-esqueleto">Carrito</span></CarritoResumen>Cuando el fragmento real del servidor llega, Astro reemplaza el nodo del fallback por el HTML de la isla. Todo lo que no lleve slot="fallback" se trata como contenido normal de la isla y se renderiza en el servidor, no en la fase estática.
La separación es limpia: slot="fallback" es lo provisional e inmediato; lo demás es lo definitivo y diferido.
Diseñar la espera: esqueleto, defecto plausible o nada
Hay tres estrategias, y elegir bien es una decisión de diseño, no de programación.
La regla de oro es minimizar la distancia perceptual entre las dos fases. Un esqueleto que ocupa el mismo tamaño que el contenido real evita el salto de layout.
Un defecto plausible —el Iniciar sesión que se convierte en tu avatar— evita incluso la sensación de carga, porque la página ya era coherente antes de que la isla llegara. Lo peor es un fallback que difiere en tamaño o significado de lo que lo sustituye: ahí la transición se siente como un parpadeo o un tirón.
<MenuUsuario server:defer> <!-- Defecto plausible: la pagina ya tiene sentido asi --> <a slot="fallback" href="/login">Iniciar sesión</a></MenuUsuario>Hay un matiz de honestidad en el defecto plausible. No debe mentir sobre el estado final: si a menudo el resultado contradice de plano al fallback —un “carrito vacío” que casi siempre se vuelve “3 artículos”—, el parpadeo semántico molesta más que un esqueleto neutro.
La elección entre esqueleto y defecto plausible depende, entonces, de cuánta certeza tienes sobre el resultado: si el estado más probable es predecible, anticípalo; si es imprevisible, no prometas nada y limítate a reservar el espacio.
Un esqueleto que reserva el mismo espacio que el contenido real es la forma más fiable de que el swap no salte:
<Producto server:defer> <!-- Esqueleto con las dimensiones del contenido real --> <div slot="fallback" class="tarjeta" aria-hidden="true"> <div class="linea-titulo"></div> <div class="linea-precio"></div> </div></Producto>El fallback como red de seguridad
Hay una propiedad del fallback que va más allá de la estética de carga. Como forma parte del HTML estático, sigue ahí aunque la isla nunca llegue: si el JavaScript falla, si la red del segundo viaje se cae, si un lector automático no ejecuta la petición diferida, lo que queda en pantalla es el fallback.
Eso convierte la elección del fallback en una decisión de resiliencia: es el estado terminal de la página cuando lo dinámico no se materializa.
De ahí que un buen fallback deba ser aceptable por sí mismo, no solo como paso intermedio. Un Iniciar sesión es un estado terminal digno: si la isla del menú de usuario nunca resuelve, el visitante ve una página perfectamente usable. Un esqueleto gris permanente, en cambio, es un estado terminal roto.
Diseña el fallback pensando “¿y si esto es lo único que se ve?”, no solo “¿y si esto se ve un instante?”.
Esta doble lectura conecta con la mejora progresiva que recorre toda la web bien construida: la capa base debe funcionar sola, y las capas superiores solo la refinan. El fallback es tu capa base.
Un rastreador que no ejecuta la segunda petición indexará el fallback; un navegador con JavaScript desactivado mostrará el fallback; una función serverless que agota su tiempo dejará el fallback.
En los tres casos, la pregunta es la misma: ¿es ese estado suficientemente bueno? Si la respuesta es sí, tu isla es robusta; si es no, has escondido contenido esencial detrás de un viaje que no siempre ocurre.
Los estados en los que el fallback es lo único que hay:
- El rastreador que no sigue la segunda petición: indexa el fallback.
- El navegador sin JavaScript: se queda en el fallback.
- La función que agota su tiempo o falla: deja el fallback como desenlace.
- La red que se corta a mitad del segundo viaje: el fallback permanece.