SSR-FIRST LIVE UI
Deferred Blocks
The page is usable immediately, and slow regions arrive later as server-rendered HTML instead of hydration-heavy client code.
Live deferred surface
The shell is already there. These six regions arrive after it.
Each card below starts as skeleton HTML, appears with a deliberate staggered delay so the arrival sequence is visible, and is later resolved by the deferred runtime. Some stop there to demonstrate one-shot deferred delivery, while others keep reacting to real backend heartbeats over the shared kiss stream.
Arrival meter
Watch the deferred slots land in sequence.
Each layout_slot_deferred() region dispatches semitexa:block:rendered when its final content lands, whether that happened through direct HTML streaming, client template rendering, or emergency fallback recovery.
0 / 6 blocks loaded
Why it matters
Deferred slots let the page render immediately while slower regions arrive later as real server-rendered HTML.
#[AsSlotResource(deferred: true)] marks a region for late delivery. The shell is rendered first, then the server streams final slot HTML over SSE.
This keeps the page SSR-first even when some regions are expensive. The browser swaps in HTML instead of rebuilding the page from client state.
First paint
Shell is ready before slow regions
Navigation, copy, and layout arrive immediately. Expensive regions can take their time.
Delivery
HTML streams in, not client state
The server renders each slot and swaps it into place. No JSON hydration dance and no page rebuild.
Architecture
One rendering model everywhere
Static shell, deferred zones, and live widgets all stay inside the same SSR-first mental model.
Delivery modes
This page demonstrates the primary deferred delivery paths and documents the emergency fallback separately.
On this surface you can inspect the two expected steady-state paths: a normal html block streamed as ready markup and a real template block rendered in the browser from a published Twig asset. The fallback path still exists, but it should activate only when SSE delivery or client template rendering actually fails.
Live on this page
mode: html
The server renders the final fragment and streams ready-to-swap HTML over SSE.
- Best for SSR-first pages where the server owns rendering end to end.
- Zero client templating logic after the block arrives.
- Best fit for slots with rich Twig markup, SEO-sensitive content, or server-only presentation rules.
Live on this page
mode: template
The server sends structured data plus a published template path, and the browser renders that Twig template locally after the SSE payload arrives.
- Useful when the same template is intentionally shared between server output and deferred client rendering.
- Reduces payload size when HTML would be much heavier than the data slice.
- Use only when the client-side template contract is deliberate and stable.
Emergency path
mode: fallback
This is not a slot mode you configure. It is the client runtime's rescue path when SSE delivery or template rendering fails.
- The browser fetches already-rendered slot HTML from the fallback endpoint.
- Useful for resilience, not as the main architecture choice.
- If you see this often, fix the primary deferred path instead of designing around fallback.
Render shell
The page becomes usable immediately with real structure, headings, and navigation.
Stream late regions
Deferred slots keep loading in the background while the user is already on the page.
Swap HTML in place
The browser receives final HTML fragments instead of client-side instructions to rebuild the interface.
Deferred Transport
Shared kiss stream over plain HTTP
This card observes the same long-lived __semitexa_kiss connection that delivers deferred blocks. It does not open a second SSE connection.
Authorization is required before the deferred runtime can open its long-lived kiss stream.
text/event-stream
Content type
Authorization is required before the deferred runtime can open its long-lived kiss stream.
- Backend events will appear here…
Sign in with Google to see more.