Page issues in the Visual Editor

  • Updated
  • Optimizely Web Experimentation
  • Optimizely Performance Edge
Your experiments are more likely to be effective if you follow the best practices for configuring them. See Create an advanced experiment plan and QA checklist.

Before you start an experiment, you should preview it to make sure that it is working as intended. Check your site’s existing functionality and new elements you added, and navigate to the events tab to make sure that your goals are firing correctly.

Load pages in the Visual Editor

Understanding how pages load in the Visual Editor may help you determine exactly why your pages are not loading in the Visual Editor the way you expect them to.

Optimizely Web Experimentation and Optimizely Performance Edge try to load pages over HTTP and HTTPS, with a 15-second timeout for the page to register a "hello" message. If that timeout occurs, the pages are loaded over a proxy.
Optimizely Web Experimentation and Optimizely Performance Edge then pre-loads up to four pages in the Visual Editor.

Handle changes and reloading pages

In Optimizely Web Experimentation, whenever you make changes in the Visual Editor, Optimizely Web Experimentation uses a clone of the DOM <body> element for the initial page load, and then resets the <body> each time, applying your new change immediately afterwards. This method has one drawback: the global JavaScript context cannot be reset without reloading the entire page. When this happens, custom code changes are applied over and over again in the same global context, which can cause unexpected behavior.

Optimizely Performance Edge keeps track of the changes you made in a change list. What happens next depends on the type of change you just made:

  • If it is a visual change
    • The changes are added to or updated in the change list.
    • The change list is sent down to the iFrame.
    • The previous change list is undone, and the new change list is applied in its place. This is possible because Optimizely Performance Edge stores the necessary information to undo all visual changes it applies.
  • If it is a custom code change
    • Optimizely Performance Edge reloads the entire page and applies all your changes in order. This is required because you cannot "undo" a code change.

Changes execute in the order they display in the sidebar, and each change waits for the one immediately preceding it to complete before it executes. Changes cannot be reordered.

The Visual Editor workflow

As described previously, when you open a page in the Visual Editor, it attempts to load three protocols (HTTP, HTTPS, and proxy) at the same time. If the protocol requested by the user (HTTP or HTTPS) does not load, Optimizely Web Experimentation and Optimizely Performance Edge use the proxy load as its fallback option. The production client then begins loading JavaScript files:

  • The first JavaScript file to load—innie.js—identifies the version of the Visual Editor being used.
  • The production client loads the p13n_inner.js JavaScript file. This is the file that contains the core logic required to manipulate and interact with the pages on your site.

The p13n_inner.js file fetches the Visual Editor client from the app's backend (the production client is too lean to run in the Visual Editor). The Visual Editor client then requests the Visual Editor data for the specific project you are working in and is then initialized.

The full paths for these JavaScript files are the following:
  • app.optimizely.com/js/innie.js
  • app.optimizely.com/dist/js/p13n_inner.js

Troubleshoot page issues

If everything looks good, then start running your experiment. If not, check this article to help diagnose the issue. There are a few common reasons you can troubleshoot: