Add skeleton loading component

[juanfra]

What problem does this address?

Loading states are one area where small improvements can make a big difference in how polished and intentional the editor feels. For many people, their first experience with the block editor is creating a new post or page, and they're immediately greeted with the starter patterns modal. Right now, the loading experience feels a bit aggressive and can make the interface look broken while the patterns actually load. It's not the best first impression.

We have quite a few places in the editor where content loads in a bit abruptly (the pattern inserter being a good example). These transitions make the editor feel less polished, especially on slower connections.

Proposed solution

Introduce a skeleton loading component that we can use throughout the editor to create smoother, more intentional loading states. This would improve perceived performance (skeleton screens make wait times feel shorter), reduce layout shift and give a more polished feeling (content has a predictable space before it loads, no abrupt changes).

I believe we could start experimenting with it in places like the pattern inserter, the starter pattern modal. And there's plenty of future opportunities: Dataviews, medialibrary, site editor when loading templates, or anything that can have a predictable layout or loads remote content.

Having a shared skeleton component would give us a consistent loading language across the editor and make it easy to improve these experiences incrementally

Here's a couple prototypes:

skeleton-pattern-inserter.mp4

skeleton-prototype-dataviews.mp4

^ Just a proof of concept, probably we should also make the title and content of each pattern part of the skeleton loading.

[AyushMhaisane]

Hi @juanfra, this looks like a great addition for improving perceived performance!

I would love to work on building this SkeletonLoader component.

My plan:

Create the base component in @wordpress/components (with support for basic props like width, height, and variant).

Implement the pulse animation to match the prototype.

Replace the loading state in the Pattern Inserter as the first test case.

Let me know if you have any specific API preferences, otherwise I will get started!

[juanfra]

Love the enthusiasm, @AyushMhaisane! Really appreciate you wanting to jump on this.

I think it'd be worth bringing @WordPress/gutenberg-components and @WordPress/gutenberg-design into the conversation before we start building. Would be great to align as a team on:

• What animation approach feels right for WordPress (pulse, shimmer, fade, etc.)
• How the component API should work, how it fits in the design system (there's a lot happening in terms of components right now, see Design System: Support for admin redesign #71196 )
• Where we want to test this first to validate the concept

IMO pattern Inserter is definitely a good candidate, but there might be other high-value spots worth considering too. We could support different shapes, border-radius, and even animations. I definitely like what shadcdn does.

I'd love to hear thoughts from the different groups and find an initial agreement before we start building.

[AyushMhaisane]

Thanks @juanfra! That makes complete sense—aligning on the design/API first is crucial since this will be used globally.

I also really like the shadcn approach; their 'pulse' animation is subtle and doesn't distract from the layout.

I will stand by for the design team's input. Once we have a consensus on the direction, I'm happy to help build the prototype!

[ciampo]

I definitely like what shadcdn does.

From a quick look, the loader is basically a filled div + pulsating animation, and the consumer is responsible for applying size / shape (rectangle vs circle?).

As @juanfra suggested, most of the work needs to happen on the design side, and then we'll collaborate on the engineering side to create a coherent API surface for it. Not sure about the priority of this item, though — there's always a lot of work and a skeleton component may not be the most urgent task.

[AyushMhaisane]

Understood on the priority! I'll keep an eye out for when the design team has capacity to look at this. Happy to pick it up whenever it makes sense for the roadmap.

[juanfra]

From a quick look, the loader is basically a filled div + pulsating animation, and the consumer is responsible for applying size / shape (rectangle vs circle?).

Yes, that's pretty much the idea. Something that can be easily used to build richer loading states.

Totally agree on priority being subjective. From my side, I see this as a relatively small lift that could bring a nice win in perceived UX and performance across different areas of the editor.

[fcoveram]

As mentioned in #74572, we should address this at the system level. +1 to follow shadcdn example in terms of effect and duration (fade?).