Chapter 03 of 12·Getting started

How it works

Measure, compile, render — skelly derives skeletons from your real layout, so they can never drift.

1

Measure

On first render — or at build time for SSR — skelly walks the subtree and records each element's box, border radius, and content type: text, image, or block.

2

Compile

Measurements compile to a compact skeleton spec — roughly 100 bytes per component — cached and reused across renders and sessions.

3

Render

While loading, the spec renders as shimmer, pulse, or optimistic placeholders in the same box — zero layout shift when real content arrives.

The Compiled Spec Output (JSON)

When the compilation phase finishes, the layout tree is translated into a lightweight, inspectable array of coordinate specifications:

skeleton.jsonjson

[
  { "x": 0, "y": 10, "w": 380, "h": 22, "type": "block" },
  { "x": 0, "y": 42, "w": 240, "h": 14, "type": "block" },
  { "x": 0, "y": 74, "w": 44, "h": 44, "r": "50%", "type": "image" },
  { "x": 56, "y": 80, "w": "95%", "h": 10, "type": "text" },
  { "x": 56, "y": 98, "w": "88%", "h": 10, "type": "text" }
]

Each item inside the specification array maps to a target element bounds:

x / y: The left and top coordinates relative to the parent wrapping boundary.
w / h: The measured width and height dimensions of the shape.
r: Optional border-radius property (e.g. 50% for circular profiles).
type: Element content category, mapping to text, image, or generic block structures.

Last updated July 2026Suggest an edit or report a docs issue ↗