live-preview browser rendering cache debugging cross-browser

Live Preview shows different than browser

You’ve built your page in Site Designer, checked it in Live Preview, and everything looks right — but when you open the published site in a browser (or send a link to a client), the layout is different. Here are the common causes and how to address each one.

Cause 1: Browser extensions are modifying styles

Ad blockers, accessibility tools, reading mode extensions, and custom CSS extensions can all alter a page’s appearance. What you see in your browser may not be what your client sees in theirs.

Fix: Test your published site in an incognito or private browsing window where extensions are typically disabled. If the site looks correct in incognito, an extension is the culprit. Disable extensions one by one to identify which one.

Cause 2: Cached files in the browser

After a site update, the browser may serve cached versions of CSS, JS, or images rather than the newly published files. This is especially common during development when you’re publishing frequently.

Fix: Force a hard refresh to bypass the cache:

Windows/Linux: Ctrl+Shift+R or Ctrl+F5
macOS: ⌘⇧R

For a complete cache clear, open DevTools (F12), right-click the refresh button, and choose Empty Cache and Hard Reload (Chrome/Edge) or clear via Settings → Privacy → Clear Browsing Data.

Cause 3: OS font rendering differences

Font rendering varies between operating systems. macOS uses subpixel antialiasing by default; Windows uses ClearType; Linux uses its own rendering stack. The same font at the same size can look heavier, lighter, or have slightly different metrics on each OS.

Fix: This is expected behavior. To minimize impact, use fonts that render well cross-platform, set explicit font-weight values (not just bold), and test on multiple operating systems if visual consistency is critical. BrowserStack lets you test on real remote machines.

Cause 4: The canvas rendering engine differs from production browsers

Site Designer’s design canvas uses its own rendering context for the visual editor. It is not a perfect pixel-for-pixel match to every browser. Minor differences in border rendering, shadow blur radius, or font hinting are possible.

Fix: Always use Live Preview (not the canvas alone) as your source of truth. Live Preview runs a real local web server and opens your site in your default browser, giving you an accurate rendering. The canvas is for editing, not for final visual verification.

Cause 5: CSS that depends on JavaScript

Some visual states depend on JavaScript executing. If a framework component (a sticky header, an animated scroll effect, a dropdown) requires JS to initialize, the canvas may show the un-initialized version while a browser shows the JS-enhanced version, or vice versa.

Fix: Test interactive components exclusively through Live Preview or the published URL — never judge them by the canvas state.

Cause 6: Flash of unstyled content (FOUC)

If your CSS is loaded asynchronously or if a render-blocking JS file delays parsing, visitors may briefly see unstyled HTML before styles apply. This appears as a flicker or layout jump on first load.

Fix: Ensure your main stylesheet is loaded in the <head> with a <link rel="stylesheet"> (not deferred). Check Page Settings → Head Code in Site Designer to verify no scripts are inadvertently blocking CSS. Fonts loaded from Google Fonts can also cause FOUC — use font-display: swap in your @font-face rules (configurable in the Resources panel).