Live preview

To enable live preview, import the Strife package to let Strife know that you are ready to receive updates from the Strife Studio.

Use npm

Live preview is available as the @strifeapp/strife package via npm.

npm install @strifeapp/strife

Then import the Strife SDK

Import in script file

import '@strifeapp/strife';

Import in HTML

<script src="@strifeapp/strife"></script>

Use CDN

The Live Preview package is also available via CDN.

<script type="module" src="https://unpkg.com/@strifeapp/strife"></script>

Full-height preview (Chrome 154+)

Strife Studio shows your page at its full height. By default the SDK measures the page and reports the height; in browsers that support responsive iframes (Chrome 154+) the browser sizes the preview frame from your page's own layout instead. That needs one line in your page's <head> — it is ignored once <body> has opened:

<meta name="responsive-embedded-sizing" content="allow-origins=*" />

@strifeapp/astro's <LivePreview /> adds it for you in edit mode. You can narrow allow-origins to Strife Studio's origin. Without the tag, or in other browsers, the SDK's own measurement is used as before.

Checks in the preview

While a page is open in Strife Studio's live preview, the preview SDK can check it and hand the result to Studio: an accessibility audit, and what the page weighs. Turn both on by placing the <strife-insights> element once in your layout's body:

<body>
  …
  <strife-insights hidden></strife-insights>
</body>

The element renders nothing, needs no script of its own and works the same in every framework. Put it in the body, never in <head>: there the browser ends the head at an element it doesn't know and moves everything after it into the body. The checks run only in Studio's preview, and your visitors get an empty tag. hidden keeps that empty element out of your layout (in a grid or flex body it would take a track and a gap); the SDK still finds it. Leave the element out to skip both. Requires @strifeapp/strife 1.23.0.

The element is not a security boundary: the SDK runs the checks for the page that frames it and asks, and the audit's result includes short HTML excerpts. If your site loads the SDK for every visitor and renders anything visitor-specific, load it only on preview requests (as <LivePreview /> does), or limit who may frame the page with Content-Security-Policy: frame-ancestors.

Where to put the element in Astro, Next.js, Vue and Nuxt, .NET and plain HTML, what editors see, and what to check when the buttons don't show:

Accessibility in the preview

On a page that carries <strife-insights>, the preview SDK runs an axe-core accessibility audit and hands the result to Studio. It downloads axe-core only when Studio asks for an audit, so your visitors never load it.

The preview toolbar then shows the number of failing rules; opening it lists every rule by impact (critical, serious, moderate, minor) with its explanation, a link to the guideline and the failing elements — hover one to see it outlined in the preview, and click one to open the field it renders (the SDK names each element by its data-field or the stega code in its text, the same answer the hover highlight uses). The audit runs once the page has connected, again 1.5 s after your last edit, and on the panel's rerun button.

The page never sends the audit anywhere itself: on teams with Content Insights, Studio stores the result of the page load and of the rerun button, per locale, for the content list's Accessibility filter. A site without <strife-insights> reports nothing and Studio shows no button. Requires @strifeapp/strife 1.23.0. On Astro, <Insights /> from @strifeapp/astro used to run the audit; from 1.10.0 it renders nothing, so replace it with the element.

Performance in the preview

On a page that carries <strife-insights>, the preview SDK also measures what the page weighs, after it loads and again after each edit (once the new images have loaded). It checks the images and third-party embeds against a budget: total image weight, one heavy image, images loaded eagerly, images far larger than they are drawn, and embeds. The preview toolbar shows the page's level (Poor, Needs improvement or Great) in its own tool, with the findings split into Your content and Template and code.

An image or embed counts as content when it renders a field (its data-field, or the stega code in its alt or text). Everything else is the template's. Only content findings set the level, so a heavy image in your layout never marks every page Poor. Checks only a developer can fix (missing width/height, JPEG or PNG instead of AVIF or WebP, page weight, number of requests) are always listed under Template and code.

Sizes come from the browser's Resource Timing. A cross-origin image discloses its size only when its response carries Timing-Allow-Origin; without it the size is estimated from the image's pixels and format, and the panel marks it ≈. Requires @strifeapp/strife 1.17.0; from 1.23.0 it runs only on a page with <strife-insights>.

Troubleshooting

Live preview doesn't load when running my site locally. When Strife Studio (a public HTTPS site) loads your local dev server (http://localhost:...) inside its preview panel, your browser's local-network-access protection kicks in — this is standard browser security, unrelated to Strife, and not a mixed-content (HTTPS/HTTP) issue (localhost over plain HTTP has long been exempt from that). The prompt looks different per browser:

• Safari shows a dialog asking to allow the Studio domain to access your "loopback network."
• Chrome doesn't prompt at all — instead, click the site info icon (the padlock) next to the address bar while on Strife Studio and enable Apps on device.

If live preview silently doesn't work and no permission dialog ever appeared, this is the most likely cause — check your browser's site permissions directly rather than waiting for a prompt.