A preloader is a screen that covers your site while your site loads. Stated plainly like that, the problem is obvious: it delays the thing the reader came for in order to hide the fact that it is not ready. Almost every preloader on the web makes the page slower to use, not faster.
There is one case where it earns its place, and it is worth naming precisely before looking at the components.
When it is justified
The first frame would otherwise be wrong. A page whose hero is a WebGL scene, a heavy font or a video shows something broken for a second: unstyled text, a black rectangle, a half-drawn canvas. A cover that hides that and lifts when the scene is ready is genuinely better than watching it assemble.
The transition is the product. An agency site, a portfolio, a launch page where the entrance is part of the work. That is a deliberate cost, and the portfolio guide makes the case that on those sites the craft is the argument.
Everywhere else - a documentation site, a dashboard, a shop, a blog - a preloader is a second added to every visit for nothing.
The components
Preloader by info-mdshakeeb is the animated loading screen, Preloader by gaxocif204 is the full-screen version that exits with a slide-up, and Preloader by Kousthubha Yadiyala is the restrained one.
Arc Preloader Hero by Ruixen UI is the editorial take, where the cover cycles through a few words before revealing the page.
The rules that keep it honest
A hard ceiling. Whatever it is waiting for, the cover lifts after a fixed maximum - a second, at most two. A preloader with no timeout is a broken page for anyone whose asset request failed.
Never wait for everything. Wait for the specific thing that would look wrong: the font, the hero image decode, the scene's first frame. Waiting for the window load event means waiting for every tracking script and every below-the-fold image.
The content exists underneath. The cover is an overlay, not a gate. The HTML must be complete and rendered behind it, or a crawler and an answer engine see a loading screen where your page should be. This is the most expensive way to get a preloader wrong.
Exit fast. The lift should take 200 to 400ms. A three-second choreographed exit is the animation costing more than the load it was hiding.
Once per session. A cover on every navigation turns a site into a slideshow. Store a flag.
Respect reduced motion. Under prefers-reduced-motion, skip the animation and reveal immediately.
The alternative that is usually better
Most of what a preloader hides is fixable directly, and the fixes make the page genuinely faster rather than apparently smoother.
A font that causes a flash wants font-display: swap and a preload. A hero image that pops in wants a fetchpriority="high" preload and reserved space, per the gallery guide. A canvas that draws in stages wants a poster frame behind it, which the shader guide covers. A layout that jumps wants its dimensions declared.
Do those four and the reason for the cover disappears, which is the outcome to aim for.
Where else to look
The honest list, because the answer is not always us:
| Source | Best for | Trade-off |
|---|---|---|
| Fixing the first paint | Removing the need for a cover at all | Real work, and the right work |
| A skeleton screen | Waiting for data rather than for assets | A different problem, per the loading guide |
| A poster frame | Hiding a canvas or video's first moments | Only covers that element |
| 21st | Full-screen covers when the entrance is the point | Quality varies by author, so preview before you take it |
Taking one
Every component page has a live preview and the code. Installing goes through the shadcn CLI against our registry:
That key comes from your 21st account, and installs require a membership. Set API_KEY_21ST once in your shell and the command works for anything in the catalogue.
Frequently asked
- Should a website have a preloader?
- Only in two cases: when the first frame would otherwise be visibly wrong, such as a WebGL hero or a heavy font, or when the entrance is genuinely part of the product, as on an agency or portfolio site. Everywhere else it adds a second to every visit for nothing.
- What rules make a preloader acceptable?
- A hard timeout of a second or two so a failed asset does not trap the reader, waiting for one specific thing rather than the window load event, a fast exit of 200 to 400 milliseconds, showing it once per session, and honouring prefers-reduced-motion by revealing immediately.
- Do preloaders hurt SEO?
- They do when the page is gated rather than covered. The HTML must be complete and rendered behind the overlay, or a crawler and an answer engine see a loading screen where the content should be. That is the most expensive way to get this pattern wrong.
- What removes the need for a preloader?
- Four fixes that make the page genuinely faster: font-display swap with a preload, a high-priority preload and reserved space for the hero image, a poster frame behind a canvas, and declared dimensions so the layout does not jump. Do those and the reason for the cover disappears.