SPA and page transitions

Verba offers three ways to move between pages, and one of them, SPA, is a bigger decision than it looks. This page explains what each mode does and where SPA stops working, so you can decide before you turn it on rather than after.

#The three modes

The choice is a single field: VerbaTheme OptionsGeneralSite, in the Page transitions group.

Standard

Ordinary browser navigation. Nothing is intercepted, everything is compatible. The right answer for a site running a lot of third-party functionality.

Animated

An animated transition drawn by the browser itself, through the View Transitions API. The page still reloads, so compatibility is the same as standard, but the hard cut is gone. This is the default, and for most sites it is the correct answer.

SPA

The page is not reloaded. Its content is swapped instead, with everything below described. The strongest effect and the narrowest compatibility.

Start with animated. Move to SPA deliberately, after testing.

#What SPA changes

In ordinary navigation the browser throws the old page away and draws a new one from scratch. That is the white flash, the reloaded scripts, and the loss of whatever was on screen.

In SPA mode the header, the menu, and the running scripts stay alive while the content underneath is replaced. Media keeps playing, interface state survives, and the change can be animated. The prize is a site that feels like one continuous thing, more than raw speed.

#Why this is foreign to WordPress

This is the part to read twice.

WordPress is built around the full page load. Every plugin assumes its scripts start from a clean slate whenever a page opens. Remove the reload and that assumption breaks.

A plugin that initializes once, on document load, does not come back to life after a content swap. The form stops submitting, the slider is left as dead markup, the counter stops counting.

Barba.js, which the SPA mode is built on, was designed for lightweight front-end sites where one author controls every line of code on the page. WordPress is the opposite: an arbitrary amount of other people's code, none of it coordinated with the rest.

So SPA in WordPress is not a switch, it is an adaptation. Verba ships its own layer on top of Barba that brings back to life the things it knows about.

#What the layer handles

This list is the boundary of support, so it is worth reading as one.

After every transition it restarts the theme and Pro own modules, tears down carousels and sliders before the swap and builds new ones after it, and resets interface state: open menus, mega menus, modals, the command palette, a typed search query, stuck focus, and hover.

Elementor is handled separately. The new page styles are loaded while the curtain still covers the screen, and its widgets are restarted. In Elementor edit mode, SPA switches off completely rather than fighting the editor.

Things living outside the swapped area are kept in sync: the browser tab title, the body classes and data attributes, and the admin bar with the correct edit link.

Links that should not be intercepted are skipped automatically: file downloads, links opening in a new tab, anchors on the same page, galleries, and lightboxes.

Verba own integrations receive a signal after each swap and restore themselves. The signal is a document event, jkd:spa:navigated, carrying the new page content, so an integration is handed what changed instead of guessing. Three integrations subscribe to it today: Contact Form 7 forms, modals, and the image fade-in.

Alongside them, share buttons, Elementor styles and background effects, autoplay for embedded video, and reveal animations all come back after each transition. Those are parts of the theme rather than integrations, but for you they belong on the same list: they keep working.

There is a safety net for a page that never answers. After the request timeout the transition is canceled, so the site does not hang behind a closed curtain.

#Where support ends

Support is tied to this stack. What works is what the layer recognizes: the theme, the Pro plugin, our integrations, and a few known quantities like Elementor.

An arbitrary third-party plugin is not adapted for this and will not become adapted. If you are expecting SPA to survive a dozen unrelated extensions, that expectation is better corrected now than after launch.

Checking your own site takes five minutes. Turn SPA on, walk through the pages with forms, maps, a cart, and third-party widgets, and see what survives a transition.

One more thing worth knowing: a transition without a reload is not a new page view for an analytics script. The layer reports the view itself, but the third-party script has to be able to hear it. Many do, some do not.

#The SPA settings

The SPA (Barba) group appears only when the SPA mode is selected.

#Excluding one link from SPA

When a single widget on the site refuses to cooperate, you do not have to give up the mode. Mark the link, or the container around it, with data-barba-prevent and the browser will load it normally.

<a href="/checkout/" data-barba-prevent>Checkout</a>

<div data-barba-prevent="all">
  <a href="/checkout/">Checkout</a>
  <a href="/cart/">Cart</a>
</div>

The theme uses this itself: the WordPress admin bar carries the attribute, so its links always open with a normal page load.

#Questions

Which mode should I use?

Animated, unless you have a specific reason. It looks better than standard, costs nothing in compatibility, and needs no testing. SPA is for a site where you know what every plugin on the page does.

Is SPA better for SEO or speed?

Neither, particularly. Search engines request pages normally and get normal HTML, so SPA is neutral there. The gain is in how the site feels to a person clicking through it.

My analytics stopped counting page views in SPA mode

Your analytics script probably counts on page load only. Verba reports the view itself; the script has to listen for that. Check your provider documentation for single-page-app tracking, or use the animated mode instead.

Can I edit the code to make my plugin work under SPA?

You can, and it is on you. Direct code changes to work around these limits are outside what support covers.

Is smooth scrolling part of this?

No, that is a separate setting in the same tab. See General: site behavior.

Last updated 9 Sep 2026