I honestly missed the days of flash-like smoothness, but I certainly didn’t miss the 10MB overhead that came with it. For years, if you wanted a smooth transition between pages in WordPress, you had to mess with Barba.js or some other heavy PJAX library that inevitably broke your wp_footer hooks. The View Transitions API is finally here to change that.
As of lately, this API is officially “Baseline,” meaning it’s supported by all major browsers. Consequently, we can now achieve app-like fluidity using native CSS. However, while the documentation makes it look like magic, implementing it in a Multi-Page Application (MPA) like WordPress requires a specific setup to ensure it doesn’t feel like a janky slideshow.
Setting Up the View Transitions API
Before we jump into the “recipes,” we need to opt-in. Since WordPress generates separate documents for every page load, you must include the @view-transition at-rule on both the source and destination pages. Specifically, for most of my projects, I drop this into the main theme stylesheet or a custom <style> block in the header.
@media (prefers-reduced-motion: no-preference) {
@view-transition {
navigation: auto;
}
}I’ve wrapped this in a prefers-reduced-motion query because accessibility isn’t optional. If a user tells their OS they don’t want things flying across the screen, you respect that. Furthermore, the navigation: auto descriptor is what enables this for cross-document navigations—standard WordPress links.
If you’re still refining your styling workflow, check out my guide on streamlining frontend CSS workflows to stay efficient.
Recipe 1: Pixelate Dissolve
This is a sophisticated take on the classic cross-fade. Instead of a simple opacity shift, it blurs the outgoing content while the incoming page snaps into focus. It feels high-end without being distracting.
html:active-view-transition-type(pixelate-dissolve)::view-transition-old(root) {
animation: bbioon_pixelate_out 1.4s ease forwards;
}
html:active-view-transition-type(pixelate-dissolve)::view-transition-new(root) {
animation: bbioon_pixelate_in 1.4s ease forwards;
}
@keyframes bbioon_pixelate_out {
0% { filter: blur(0px); opacity: 1; }
100% { filter: blur(40px); opacity: 0; }
}
@keyframes bbioon_pixelate_in {
0% { filter: blur(40px); opacity: 0; }
100% { filter: blur(0px); opacity: 1; }
}Recipe 2: The Wipe Up
Using clip-path is a powerful way to handle the View Transitions API. In this recipe, the new page content “reveals” itself from the bottom, effectively pushing the old page out of the frame.
@keyframes bbioon_wipe_in {
from { clip-path: inset(100% 0 0 0); }
to { clip-path: inset(0 0 0 0); }
}
html:active-view-transition-type(wipe-up)::view-transition-new(root) {
animation: bbioon_wipe_in 1.2s cubic-bezier(0.4, 0, 0.2, 1) forwards;
}Recipe 3: The 3D Flip
This is a “war story” special. I once spent three days trying to make a card-flip transition work for a client using GSAP. Now, we can fake a two-sided card flip along the Y-axis using just a few lines of CSS. It’s aggressive, so use it sparingly—perhaps for product detail pages.
@keyframes bbioon_flip_out {
100% { transform: rotateY(-90deg) translateX(-100vw); opacity: 0; }
}
@keyframes bbioon_flip_in {
0% { transform: rotateY(90deg) translateX(100vw); }
100% { transform: rotateY(0deg) translateX(0vw); }
}Recipe 4: Circular Reveal
This is one of the most popular patterns. The new page content expands from a central point. For more details on the underlying mechanics, refer to the official View Transition API documentation on MDN.
@keyframes bbioon_circle_in {
from { clip-path: circle(0% at 50% 50%); }
to { clip-path: circle(150% at 50% 50%); }
}Implementation Gotchas
The biggest bottleneck isn’t the code; it’s the Race Condition between your CSS animations and WordPress’s server-side rendering. If your server is slow, the transition might finish before the DOM is ready. Therefore, always optimize your backend performance first. I’ve written before about syncing frontend and backend workflows to prevent this jank.
Look, if this View Transitions API stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
Final Takeaway
The native API is a massive leap forward for the WordPress ecosystem. It eliminates the need for heavy JavaScript libraries while providing smoother, more accessible user experiences. Start small with a simple cross-fade, debug your selector types, and then move into complex clip-path wipes. Your users will notice the difference, even if they can’t quite name what changed.
