SSR & streaming

A skeleton whose layout is known without touching the DOM is rendered on the server as real elements, so it arrives in the initial HTML and paints before any JavaScript runs. That is what makes <Skelly> usable as a Next.js loading.tsx or a Suspense fallback, where there is no client runtime yet to mount into.

// app/dashboard/loading.tsx
import { Skelly } from 'use-skelly/react'

// A preset needs no DOM measurement, so the skeleton
// is rendered into the server HTML itself — it paints
// on first paint, before any JavaScript runs.
export default function Loading() {
  return <Skelly preset="dashboard" visual="shimmer" />
}

Which skeletons can be server rendered

Three cases need no measurement, and all three ship in the server response: an explicit spec, a preset, and a container with no children — a standalone route fallback, which resolves to the generic skeleton.

A measured skeleton cannot be. Measuring means reading real geometry off real markup, and inside a loading.tsx the page it would measure has not rendered — the fallback renders instead of it. Those skeletons mount after hydration, which is the right trade for a client-side loading state and the wrong one for a route fallback.

// Measured skeletons are client-side: the markup has to
// exist before it can be measured.
<Skelly loading={isLoading}>
  <ProfileCard user={data} />
</Skelly>

// Server-rendered: the layout is known up front.
<Skelly preset="profile" />
<Skelly spec={compiledSpec} />

Reserved space, no layout jump

Skeleton items are absolutely positioned, so a standalone skeleton would otherwise give its container no height and paint over whatever follows it. When there is no real content underneath, the overlay joins normal flow and carries the spec’s own extent, reserving exactly the space the skeleton occupies.