Performance and flicker
Personizely is designed to change your pages without slowing them down or showing visitors the original before the variation, an effect known as flicker (or flash of original content). This page explains what the snippet costs in page speed, how to choose between asynchronous and synchronous loading, and what each campaign type does to keep changes invisible.
The snippet and page speed
- Lightweight and per site. Each website gets its own snippet, containing only its active campaigns and widgets and only the features they use. Drafts, paused items and unused features add nothing.
- Served from a global CDN, close to your visitors, and updated within moments when you publish a change.
- No extra round trip to show campaigns and widgets. They're delivered with the snippet. Only targeting that needs stored history, location or company data waits for a short server lookup.
- On Shopify, keeps working with common ad-blockers.
- Doesn't run for recognized bots and crawlers.
The Snippet card on the Dashboard shows the snippet's approximate compressed size, split into code and your campaign and widget data, and the features it currently includes. Stopping campaigns and widgets you no longer need is the most effective way to keep it small.
Asynchronous vs synchronous loading
| Asynchronous (default) | Synchronous |
|---|---|---|
Script tag | Has the async attribute | No async attribute |
Page rendering | Never waits for Personizely | Waits until the snippet has downloaded and run |
Content and split URL tests | The original can show briefly before the variation | Changes are applied before the page first renders |
Popups and widgets | Unaffected | Unaffected |
Best for | Sites that mainly use widgets, or personalize below the fold | Sites running A/B tests on visible page content, prices or URLs |
Synchronous loading delays the first render by the time it takes to fetch the snippet. Because it's small and served from a CDN (and cached by the browser after the first page), that's usually a short delay, and it's the trade most A/B testing tools ask for.
The first time you start a campaign on a site that loads asynchronously, Personizely asks "Prevent flicker on your site?" and offers Switch to synchronous or Keep async. Full-stack campaigns skip this prompt, because your own code renders them.
Change the loading mode
The setting is Settings → Tracking → Asynchronous script loading. How it reaches your site depends on the install:
Install method | How to apply the change |
|---|---|
Shopify app embed | Automatic |
Webflow, Square integration | Automatic. On Webflow the connected script never blocks rendering; for synchronous loading, Install Personizely on Webflow or Square. |
WordPress plugin | Use the plugin's own Async checkbox (Personizely → Toggle Advanced Settings) |
Script tag | Copy the updated snippet from Settings → Website to your site again |
Google Tag Manager | Not applicable: a tag manager always adds the script after the page starts loading |
Wix | Managed by the Wix app |
Shopify Hydrogen | Not applicable: the script loads in the browser after hydration |
For a synchronous tag, place it as high in the <head> as possible, before other heavy scripts.
How each campaign type avoids flicker
Campaign type | What visitors experience |
|---|---|
Only the elements being changed are hidden, and they fade in once the change is applied. The rest of the page renders normally. | |
The page stays blank until the visitor's group is decided. Variation visitors are redirected straight away; control visitors see the page. | |
On the first page of a session, variation visitors are redirected once into the variation theme. Later pages load directly in that theme. | |
Variation visitors are redirected to the alternate template on each matching page, and the extra URL parameter is removed from the address bar. | |
Price elements of campaign products stay hidden until they've been rewritten. | |
Your own code renders the variation, so there's nothing to hide. | |
Widgets | Popups, bars and callouts appear on their trigger, so there's no original to flash. Embedded widgets appear in place once rendered. |
When content stays hidden a little longer
Some campaigns can't be decided from what's in the browser alone, so their elements stay hidden until the data arrives:
- the target uses filters answered by the server, such as location, visit history or order history (see How targeting works);
- the variation uses Dynamic text (personalization variables) with visitor, location or company data;
- the target uses company data from an enrichment integration.
Hidden content is always revealed. If a change can't be applied quickly (for example, the element it targets never appears on the page), or targeting data fails to load, the original content is shown rather than staying hidden.
Redirect tests and reloading the control group
In split URL and template experiments, the variation is counted only after its redirect loads. Visitors who leave during the redirect are missing from the variation but not from control, which can bias results toward the variation. Turn on Reload the page for the control group (campaign Advanced settings) to give control visitors the same extra page load. It adds a page load for control visitors.
Single-page apps
On sites that change pages without a full reload (React, Vue, Next.js, Hydrogen and similar), Personizely detects route changes made through the History API. On each change it re-checks targeting, records a page view and re-applies campaigns for the new page, without reloading the snippet. Changes to only the URL hash or query string aren't treated as a new page.
Tips to minimize flicker
- Load synchronously if you run content, split URL or price tests, and place the tag high in the <head>.
- Don't install through a tag manager for sites that run content tests.
- Prefer targeting the browser can evaluate on its own (device, page, UTM parameters, cart, cookies) for above-the-fold tests. Server-evaluated filters add a short wait.
- Use stable CSS selectors in the visual editor, so the elements are found as soon as they're on the page.
- For server-rendered or headless pages, use Full-stack experiments and feature flags and render the variation in your own code.
- Avoid two campaigns changing the same element. The first campaign to change it wins, and the other's change isn't applied.
Behavior details and limitations
- Async loading can show the original first. With asynchronous loading, the browser may paint the page before the snippet arrives. The hiding described above starts when the snippet runs, so anything painted before that can briefly show the original.
- Price tests and async loading. The same applies to prices: until the snippet runs, original prices can show.
- Hydrogen and other client-rendered loads. When the script is injected after hydration, server-rendered content is visible first.
- Measuring speed. Lab speed tests don't always reflect what Personizely does for real visitors. Measure with real-user data (such as Core Web Vitals in Search Console) for the full picture.