Page Transitions in Bricks Builder: What They Are and How to Add Them

Click around a well-made portfolio site and the pages seem to flow into each other: a brief fade, a sweep of color, and you have arrived. On an ordinary WordPress site, every click is a hard cut: blank screen, a moment of churning, pop. The difference is a page transition, and adding one to Bricks is more attainable than it used to be.

What exactly is a page transition?

A page transition is an animated change between two pages instead of an abrupt swap. When a visitor clicks a link, something intentional happens on screen: the current page fades out, a panel slides across, the new page rises into place. The destination appears as part of that motion rather than after a blank moment. That is the entire concept.

One clarification: a page transition happens between pages. Effects that play while you move down a single page are scroll animations, and we cover those separately.

Why doesn't every WordPress site have them?

Because of how the web traditionally works. A normal website (WordPress included) does a full page reload on every click: the browser throws away the current page, downloads the next one, and draws it from scratch. That blank moment is not a bug; it is the web's default behavior. There is simply no built-in place to put an animation.

Historically, the only fix was JavaScript that intercepts navigation: code that catches your click, loads the next page in the background, animates the swap, and updates the address bar so everything still behaves like normal browsing. It works (award-winning sites do exactly this), but it is genuinely hard to get right, and small mistakes break back buttons, analytics, and other plugins.

Browsers have started closing this gap with the View Transitions API, a newer feature that lets sites describe transitions between pages with far less custom code. Support has been improving, but adoption is still uneven. You cannot yet count on every visitor's browser handling it, and most WordPress themes and plugins do not take advantage of it. For now, practical page transitions on WordPress still come from tooling.

What makes a good page transition?

Having built seven of them, we think the good ones share four traits:

• Fast. Well under a second. A good transition masks loading time the browser was spending anyway; a slow one adds a toll booth to every click. If visitors could describe your animation in detail, it is too long.
• Consistent. The same transition everywhere. A different effect on every page does not read as creative. It reads as chaos.
• Respectful of reduced motion. Some visitors get genuine discomfort from on-screen motion, and their operating system says so through a setting called prefers-reduced-motion. A page transition is full-screen motion, the most noticeable kind, so honoring that setting matters here more than anywhere. The right fallback is a plain, instant page change.
• Never in the way. Clicks must work instantly, and normal browsing must survive: back and forward buttons, opening links in new tabs, bookmarks. If the effect ever fails, the site must fall back to an ordinary page load, never a broken one.

What are your options in Bricks?

1. Hand-built JavaScript

This is developer territory. Someone writes the interception code themselves and handles every edge case by hand: external links, file downloads, form submissions, analytics tracking. The reward is total creative freedom; the price is a permanent maintenance responsibility. If you have a developer and a bespoke vision, it is legitimate. If you are reading a beginner's guide, it is not your road.

2. GSAP-based tooling

Tools in the Bricksforge and Motion.page camp let you choreograph transitions with animation timelines instead of raw code. The power is real, and so is the learning curve. Our complete animations guide compares this route against the others in detail.

3. Pre-built transitions

The third option is transitions someone already built and debugged. Bricksfusion's animations plugin includes seven page transition effects that install as native Bricks functionality: you pick an effect and configure it visually, with no navigation code to write or maintain. Each one has a live demo where you can click between real pages and feel the timing before deciding. The trade-off is the usual one: you choose from a curated set of seven rather than designing your own from zero.

When should you skip page transitions entirely?

Transitions are the most oversold animation type, so here are three situations where the honest answer is "don't":

• Content-heavy sites where readers navigate constantly. Documentation, blogs with deep archives, news sites. A reader who opens thirty pages meets your transition thirty times, and even a fast one starts to feel like a tax.
• Sites that are already slow. A transition decorates the wait; it does not shorten it. If your pages take ages to load, fix that first; our performance guide shows you what to measure.
• Audiences where motion is a liability. If accessibility is central to your site's mission, full-screen motion is the kind most likely to trouble motion-sensitive visitors. Reduced-motion support helps, but not every affected visitor has the setting turned on. When in doubt, leave it out.

Transitions are seasoning, not the meal. They belong on portfolios, agency sites, and product showcases: places where the feel of the site is part of the pitch. They rarely belong on sites whose whole job is delivering information fast.

Bottom line

Page transitions went from "hire a developer" to "pick one and configure it." If your site sells a feeling, a fast, consistent transition is one of the few effects visitors notice on every click. Start with the live demos, keep it under a second, run the back-button test, and pair it with restrained scroll animations rather than piling on both at full volume.