Optimizely developer for hire

Six things that come up on every Optimizely project

Optimizely's SPA support has gaps you only hit in production

Optimizely Web supports SPAs in its documentation, and that's accurate in the basics. The targeting mechanics are where it breaks. Set the audience to target a PDP path on Next.js Pages Router and a user who direct-lands on a PDP gets bucketed correctly. A user who lands on the homepage and clicks through to a PDP never gets bucketed at all, because the audience evaluation happened on initial page load. Removing the variant UI on navigation away is a separate problem Optimizely doesn't solve either. The pragmatic fix is to bypass Optimizely's audience targeting, run the experiment on every page (audience: everyone, every URL), and decide in code when to apply or tear down the variant.

SPA route changes don't activate experiments

Optimizely's snippet activates once on initial page load. Route changes after that happen client-side without firing a new pageload event. Without a custom URL change detector, the variation either persists into pages where it shouldn't or breaks because the elements it expected are gone. I use a MutationObserver pattern that re-runs the experiment on every URL change, with a hydration delay so React's reconciliation pass finishes before the variant mounts.

Late-rendering DOM elements miss the variation

Optimizely's applyChange() runs once at activation. If the target element hasn't mounted by then (lazy-loaded carousels, async-fetched recommendations, anything behind a network round trip), the change never applies. The test runs but the variant looks identical to control. I use a polling utility with a MutationObserver fallback and a configurable timeout, so the change applies whenever the element finally renders.

React's controlled inputs ignore variation code

Setting input.value = 'x' in variation code doesn't trigger React's onChange handler. Form state diverges from visual state and the test reports nothing useful. The fix is the native input descriptor pattern: pull the original value setter off HTMLInputElement.prototype, call it with the React-controlled input, then dispatch a bubbling input event so React's synthetic system picks up the change.

// Bypass React's overridden value setter so onChange actually fires
const setReactInputValue = (input, value) => {
  const nativeSetter = Object.getOwnPropertyDescriptor(
    window.HTMLInputElement.prototype,
    "value"
  ).set;

  nativeSetter.call(input, value);
  input.dispatchEvent(new Event("input", { bubbles: true }));
};

Variation code can wreck Core Web Vitals

Variation code that mutates layout after first paint causes Cumulative Layout Shift. Google penalises that in rankings, and brand teams pull tests that show up red in their CWV reports. I keep variation code under 50ms total execution and prefer class-name additions over inline style mutations, so layout changes paint in the same frame as the rest of the page. Skeleton loaders with matched dimensions keep CLS contribution at zero during async data fetches.

New interactive elements skip accessibility

Variations that add modals, overlays, or interactive components need focus traps, ARIA roles, and keyboard parity. The strategist's brief almost never mentions these. Skip them and the variant fails accessibility review when client engineering examines the build. I ship these by default: focus traps with AbortController cleanup, proper ARIA roles, aria-modal attributes, keyboard escape handling, and screen-reader sanity checks before handover.