Blocking or async

The tradeoff, in one paragraph

The mode is nothing more than whether the script tag carries async. Everything else — targeting, measurement, attribution, preview — behaves identically in both. The only thing at stake is the pre-hide guarantee: whether a visitor can ever see the original content before the variant replaces it.

Blocking (tag as copied)

The script runs before the browser paints. Changes to visible content apply before anyone sees the page, so there is no flash of the original. The cost is a small wait on the rendering path, bounded by a hard deadline: if the script is slow, blocked, or down, the page reveals itself anyway. Your store can never be held hostage by Proa.

Choose blocking when an experiment changes above-the-fold content: hero copy, headline swaps, anything in the entry viewport. The flash of the original is exactly what such an experiment must not show.

Async (add async to the tag)

The script leaves the rendering path entirely and runs whenever it loads, usually after first paint. The page renders at full speed; in exchange, the original content may show briefly and then change.

Choose async when the experiment touches content the visitor will not see at first paint — below the fold, or later pages of the journey — or when you prefer to keep everything off the rendering path. That is a legitimate choice; just do not run async and then report the flash as a bug. It is the tradeoff you picked.

Never use defer: it gives up the pre-hide like async but still waits for the full document parse. The worst of both.

Our recommendation

Start async on a store that is new to Proa, and move to blocking once above-the-fold experiments need the guarantee. Switching is editing one attribute in the theme; no republish is required. Whichever you choose, write it down where your team will find it: the first question for any flicker report is "was this installed async?".

For the reasoning behind the tradeoff, the flicker post on the blog covers it in depth.