One Embed Tag, Any HTML Site, Every Stack

Why CalcStack

Why CalcStack for HTML / Any Website?

Embed Code Reference

Three ways to embed CalcStack on any HTML page: a raw iframe for maximum control, a script tag with automatic resizing, or a framework component wrapper for React and Vue projects.

Find your Customer ID in your CalcStack dashboard under Settings. Without a Customer ID, the embed runs as a demo with CalcStack branding and no lead capture.

Performance, Core Web Vitals, and the Isolated Iframe

The reason an embedded tool does not drag down a hand-built site comes down to process isolation. A cross-origin iframe runs in its own browsing context, with its own JavaScript execution and its own layout work, so the calculator's scripts never compete for the main thread that paints your page. Google's Core Web Vitals measure your document, and the tool's work happens in a separate document, which is why a heavy interactive widget can sit on a landing page without moving its Largest Contentful Paint or its Interaction to Next Paint. The HTTP Archive Web Almanac has documented for years that third-party iframes are the standard mechanism sites use precisely because of this containment.

Layout shift is the metric to watch, and the fix is to reserve space. If you drop a bare iframe with no defined height, the browser lays out the page, then the tool loads and pushes content down, registering a Cumulative Layout Shift penalty. Give the iframe or its container an explicit height up front, or use the auto-resize script which sizes from a placeholder, and the slot is reserved before paint so nothing jumps. A reliable habit on hand-built pages is to set a minimum height on the container that matches the tool's typical first-render size, so even before the iframe paints the page already holds the right amount of vertical space. Pairing that with the loading="lazy" attribute on any tool below the fold defers its network cost until the visitor scrolls near it, keeping your initial page weight lean.

Treat the tool as you would any third-party resource: above the fold, let it load eagerly because it is part of the first impression; below the fold, lazy-load it so it never blocks the critical path. On a static site served from a CDN, the document itself paints almost instantly, and the tool streams in behind it. The visitor sees your page immediately and the interactive element appears a beat later, which is exactly the loading order you want and the one a monolithic, single-bundle approach struggles to achieve.

Static Site Generators and Framework Specifics

Because the embed is plain markup, it slots into any generator's templating without special handling, but each ecosystem has a small gotcha worth knowing. In Markdown-driven generators like Hugo, Jekyll, and Eleventy, raw HTML inside a content file may be escaped by the Markdown processor; the answer is a shortcode or include partial that emits the iframe verbatim, keeping your content files clean while guaranteeing the tag survives the build. In Astro, you can drop the snippet straight into a component or an MDX file, and because Astro ships zero client JavaScript by default the tool remains the only interactive cost on an otherwise static page.

Component frameworks need one extra consideration around their rendering model. A raw iframe will re-mount and reset its state whenever the surrounding component re-renders, so wrap it in a stable boundary, a memoized component, or use the script embed which reattaches itself on DOM changes. For single-page apps that swap routes without a full reload, the script embed is the safer default because it listens for the host element entering the page and re-initializes, where a static iframe can be left with a stale height after navigation. This is the same SPA caveat that applies to most third-party widgets, not something unique to one tool.

None of these stacks require a server. According to BuiltWith adoption data, static-first frameworks have spread well beyond their early developer niche into marketing and content sites, and the appeal is the same everywhere: ship a fast, cacheable document and layer interactivity on with embeds rather than rebuilding the page as an application. A calculator added through an iframe respects that architecture, because it adds a feature without adding a build dependency, a runtime, or a piece of infrastructure you now have to keep alive.

The same reasoning extends to where the site is hosted. Whether you deploy to a managed static host, a generic object store behind a CDN, or a traditional shared server, the embed behaves identically, because all the tool needs from the host is the ability to serve an iframe tag and reach the open web. There is no API route to provision, no environment variable to inject at build time, and no origin secret to protect, since the customer identifier in the embed URL is a public binding that links submissions to your account, not a credential. That keeps the security surface of adding a tool effectively flat: you are publishing one more line of static HTML, and everything stateful, the lead storage, the scoring, the routing, lives off your site entirely.