An embedded widget is a guest on someone else’s website. It should load quickly and leave the host page alone.
That sounds obvious. It still takes some discipline. Every dependency, font, animation, and request ends up on a page we do not control.
Here is how the Proofi embed works today.
One script, built for the job
The dashboard is a Next.js app, but the customer-facing widget is not. It is a separate Preact package compiled by Rollup into one browser script.
Preact gives us components and hooks without making every site download the runtime used by our dashboard. Rollup resolves the imports, compiles the JSX, and minifies the result. There are no external UI libraries or web fonts in the embed.
New embed snippets use a stable script URL and put the widget ID in a data attribute:
<div id="jts-widget-your-widget-id"></div>
<script src="https://proofi.co/widget.js" data-widget-id="your-widget-id" async></script>The browser can reuse that script when a page contains more than one widget. The content still comes from the API, so edits made in Proofi can appear without asking someone to update their website.
A boundary around the CSS
Host sites are unpredictable. A rule such as button { border: 0 } or p { margin: 2rem } can quietly wreck an embed.
Proofi mounts each widget in a Shadow Root. Its layout rules stay inside that boundary, and the host page’s broad selectors stay outside. Colors, spacing, fonts, and motion are passed in through the widget settings instead of relying on inherited page styles.
The same boundary also gives us container-based responsive behavior. A grid embedded in a narrow sidebar should collapse even when the browser window is wide. Viewport breakpoints cannot tell us that, but the widget container can.
Fewer moving parts
The widget makes one content request. The response is cached according to the account plan, and the bundle is served as a static asset. Failed requests are contained inside the widget instead of affecting the rest of the page.
We also removed layouts that existed in the dashboard but not in the runtime. A shorter list of working layouts is better than a large selector full of fallbacks.
There is no universal Lighthouse score for an embed. The host page, network, placement, and amount of content all matter. We can control the code we ship, measure it, and keep unnecessary work out of the bundle. That is the standard we use.