Publishing & the Public Renderer

When you publish a document, BlnkSpace renders it through a server-side async React component called the Block Renderer. This page explains how publishing works end-to-end — from enabling a public URL to how each block type is rendered for visitors.

Publishing a document

Every document in BlnkSpace has a Published toggle. When turned on, the document becomes accessible at its public URL. When turned off, visitors see a 404 — the document and its content are never exposed.

How the renderer works

Published pages are rendered by an async React Server Component — no client-side JavaScript is required to display the content. The renderer receives the document's blocks, layout (navbar/footer), typography settings, and colors, then converts each block to its HTML equivalent server-side.

The rendering pipeline:

• The middleware rewrites tenant hostnames (your subdomain or custom domain) to an internal /site-render route, passing the host and path as query params.
• The site-render page resolves the document from the host/path combination, fetches the blocks and layout, then passes them to BlockRenderer.
• BlockRenderer is a server component. It iterates all blocks, recursively resolving column children, section children, and toggle children, rendering each into React nodes.
• The final HTML is sent to the browser. Most content requires zero JavaScript to display.

ISR caching

Published pages are cached using Next.js Incremental Static Regeneration (ISR) with a 60-second revalidation window. This means:

• The first visit after a cache miss renders the page fresh from the database.
• Subsequent visits within 60 seconds are served from the CDN cache — extremely fast.
• After 60 seconds, the next request triggers a background revalidation. Visitors still see the cached version while the new one builds.
• Content changes appear on the public page within ~60 seconds of saving in the editor.

Typography on published pages

The document's typography tokens (font family, font size, line height, letter spacing) are applied to each block via a blockWrapStyle function. This function reads the document-level typography and merges it with any block-level overrides from the selection toolbar.

The cascade is:

• Block-level override (set via selection toolbar) wins first.
• Document typography (set via the Typography picker or a branding preset) applies if no block override is set and the value is non-default.
• Hardcoded fallback (the renderer's own defaults) applies last.

Google Fonts on published pages

If the document uses a Google Font (for the body, navbar, or footer), the font stylesheet is injected server-side into the page HTML. No JavaScript is required — the <link> tag appears in the rendered HTML so the browser starts fetching the font immediately. Fonts are deduplicated: if the body and navbar share the same font, only one request is made.

Block rendering reference

The table below shows how each block type is handled in the public renderer. "SSR" means the block renders entirely server-side with no client JavaScript. "Client island" means the block requires a client component for interactivity but falls back gracefully if JS is slow to load.

Navbar and footer

If a document has useNavbar or useFooter enabled, the site layout's navbar/footer configuration is rendered above and below the block content respectively. Both are SSR — no client JavaScript required for the navigation structure itself. Dropdown menus require a client island for the open/close interaction.

If no footer is configured, BlnkSpace renders a minimal attribution footer with a "Made with BlnkSpace" link.

Content width

The document's width setting controls how content blocks are constrained. Named widths map to Tailwind classes; custom pixel values use inline styles. Full-width blocks (Hero, Section, Carousel, Infinite Carousel) always span 100% of the viewport regardless of the document width setting.