pub enum SsrMode {
OutOfOrder,
PartiallyBlocked,
InOrder,
Async,
Static(StaticRoute),
}Expand description
Indicates which rendering mode should be used for this route during server-side rendering.
Leptos supports the following ways of rendering HTML that contains async data loaded
under <Suspense/>.
- Synchronous (use any mode except
Async, don’t depend on any resource): Serve an HTML shell that includesfallbackfor anySuspense. Load data on the client (usingcreate_local_resource), replacingfallbackonce they’re loaded.- Pros: App shell appears very quickly: great TTFB (time to first byte).
- Cons: Resources load relatively slowly; you need to wait for JS + Wasm to load before even making a request.
- Out-of-order streaming (
OutOfOrder, the default): Serve an HTML shell that includesfallbackfor anySuspense. Load data on the server, streaming it down to the client as it resolves, and streaming down HTML forSuspensenodes.- Pros: Combines the best of synchronous and
Async, with a very fast shell and resources that begin loading on the server. - Cons: Requires JS for suspended fragments to appear in correct order. Weaker meta tag support when it depends on data that’s under suspense (has already streamed down
<head>)
- Pros: Combines the best of synchronous and
- Partially-blocked out-of-order streaming (
PartiallyBlocked): Usingcreate_blocking_resourcewith out-of-order streaming still sends fallbacks and relies on JavaScript to fill them in with the fragments. Partially-blocked streaming does this replacement on the server, making for a slower response but requiring no JavaScript to show blocking resources.- Pros: Works better if JS is disabled.
- Cons: Slower initial response because of additional string manipulation on server.
- In-order streaming (
InOrder): Walk through the tree, returning HTML synchronously as in synchronous rendering and out-of-order streaming until you hit aSuspense. At that point, wait for all its data to load, then render it, then the rest of the tree.- Pros: Does not require JS for HTML to appear in correct order.
- Cons: Loads the shell more slowly than out-of-order streaming or synchronous rendering because it needs to pause at every
Suspense. Cannot begin hydration until the entire page has loaded, so earlier pieces of the page will not be interactive until the suspended chunks have loaded.
Async: Load all resources on the server. Wait until all data are loaded, and render HTML in one sweep.- Pros: Better handling for meta tags (because you know async data even before you render the
<head>). Faster complete load than synchronous because async resources begin loading on server. - Cons: Slower load time/TTFB: you need to wait for all async resources to load before displaying anything on the client.
- Pros: Better handling for meta tags (because you know async data even before you render the
Static: Renders the page when the server starts up, or incrementally, using the configuration provided by aStaticRoute.
The mode defaults to out-of-order streaming. For a path that includes multiple nested routes, the most
restrictive mode will be used: i.e., if even a single nested route asks for Async rendering, the whole initial
request will be rendered Async. (Async is the most restricted requirement, followed by InOrder, PartiallyBlocked, and OutOfOrder.)
Variants§
OutOfOrder
Out-of-order streaming (OutOfOrder, the default): Serve an HTML shell that includes fallback for any Suspense. Load data on the server, streaming it down to the client as it resolves, and streaming down HTML for Suspense nodes.
- Pros: Combines the best of synchronous and Async, with a very fast shell and resources that begin loading on the server.
- Cons: Requires JS for suspended fragments to appear in correct order. Weaker meta tag support when it depends on data that’s under suspense (has already streamed down <head>)
PartiallyBlocked
Partially-blocked out-of-order streaming (PartiallyBlocked): Using create_blocking_resource with out-of-order streaming still sends fallbacks and relies on JavaScript to fill them in with the fragments. Partially-blocked streaming does this replacement on the server, making for a slower response but requiring no JavaScript to show blocking resources.
- Pros: Works better if JS is disabled.
- Cons: Slower initial response because of additional string manipulation on server.
InOrder
In-order streaming (InOrder): Walk through the tree, returning HTML synchronously as in synchronous rendering and out-of-order streaming until you hit a Suspense. At that point, wait for all its data to load, then render it, then the rest of the tree.
- Pros: Does not require JS for HTML to appear in correct order.
- Cons: Loads the shell more slowly than out-of-order streaming or synchronous rendering because it needs to pause at every Suspense. Cannot begin hydration until the entire page has loaded, so earlier pieces
of the page will not be interactive until the suspended chunks have loaded.
Async
Async: Load all resources on the server. Wait until all data are loaded, and render HTML in one sweep.
- Pros: Better handling for meta tags (because you know async data even before you render the
<head>). Faster complete load than synchronous because async resources begin loading on server. - Cons: Slower load time/TTFB: you need to wait for all async resources to load before displaying anything on the client.
Static(StaticRoute)
Static: Renders the page when the server starts up, or incrementally, using the
configuration provided by a StaticRoute.
Trait Implementations§
Source§impl Ord for SsrMode
impl Ord for SsrMode
Source§impl PartialOrd for SsrMode
impl PartialOrd for SsrMode
impl Eq for SsrMode
impl StructuralPartialEq for SsrMode
Auto Trait Implementations§
impl Freeze for SsrMode
impl !RefUnwindSafe for SsrMode
impl Send for SsrMode
impl Sync for SsrMode
impl Unpin for SsrMode
impl UnsafeUnpin for SsrMode
impl !UnwindSafe for SsrMode
Blanket Implementations§
Source§impl<T> BorrowMut<T> for Twhere
T: ?Sized,
impl<T> BorrowMut<T> for Twhere
T: ?Sized,
Source§fn borrow_mut(&mut self) -> &mut T
fn borrow_mut(&mut self) -> &mut T
Source§impl<T> CloneToUninit for Twhere
T: Clone,
impl<T> CloneToUninit for Twhere
T: Clone,
Source§impl<Q, K> Comparable<K> for Q
impl<Q, K> Comparable<K> for Q
Source§impl<Q, K> Equivalent<K> for Q
impl<Q, K> Equivalent<K> for Q
Source§impl<Q, K> Equivalent<K> for Q
impl<Q, K> Equivalent<K> for Q
Source§fn equivalent(&self, key: &K) -> bool
fn equivalent(&self, key: &K) -> bool
key and return true if they are equal.Source§impl<T> Instrument for T
impl<T> Instrument for T
Source§fn instrument(self, span: Span) -> Instrumented<Self>
fn instrument(self, span: Span) -> Instrumented<Self>
Source§fn in_current_span(self) -> Instrumented<Self>
fn in_current_span(self) -> Instrumented<Self>
Source§impl<T> IntoEither for T
impl<T> IntoEither for T
Source§fn into_either(self, into_left: bool) -> Either<Self, Self>
fn into_either(self, into_left: bool) -> Either<Self, Self>
self into a Left variant of Either<Self, Self>
if into_left is true.
Converts self into a Right variant of Either<Self, Self>
otherwise. Read moreSource§fn into_either_with<F>(self, into_left: F) -> Either<Self, Self>
fn into_either_with<F>(self, into_left: F) -> Either<Self, Self>
self into a Left variant of Either<Self, Self>
if into_left(&self) returns true.
Converts self into a Right variant of Either<Self, Self>
otherwise. Read more