Skeleton Screen

A skeleton screen shows the expected shape of a page before its content is ready. Blocks where a photo, title, price, or card will appear can reduce a jarring empty screen and communicate that loading is underway. Unlike a spinner, the skeleton suggests which parts of the interface are coming, but it must not masquerade as already available information.

Consider a local contractor directory that loads appointment options after the initial page render. A restrained placeholder can preserve the eventual card dimensions and reduce visible layout movement while the real options arrive. However, indefinitely animating gray bars would hide a genuine failure. Provide an understandable error or retry state when content cannot load, and do not display fabricated appointment availability in the placeholder.

Accessibility requires more than visual polish. A skeleton should not clutter keyboard navigation or be announced as multiple meaningless interface elements. Use appropriate loading status and consider the `aria-busy` state where relevant; respect reduced-motion preferences for animations. Once the actual content arrives, update the status appropriately. Skeletons can improve perceived continuity, but they do not make network transfer or JavaScript execution inherently faster. This term differs from a loading spinner, placeholder input text, and responsive layout techniques, although they may appear together in a component.