Performance & caching

Zeeker keeps the code on the host page small and loads the social application asynchronously only when it is useful. The default website integration does not preload an iframe, Google Fonts, or speculative connection hints.

On the wire

The compressed sizes below describe the current production build. They are measurements, not fixed API limits, and can change as the widget evolves.

Resource	Current size (gzip)	When fetched
loader.js	~2.9 KB	When the asynchronous script tag loads. It only installs the window.zeeker API bootstrap.
trigger.js	~4.8 KB	For host-triggered installs. It waits for the selected interaction.
runtime.min.js	~74.3 KB	Injected as an async script when the selected mode becomes eligible, or immediately when an urgent API method needs it.
Boot payload	Variable	After the runtime starts. It includes the published config and only the data required by the selected mode.
Zeeker surface	Variable	When a visible fixed/inline surface mounts or when the visitor opens a panel. It is not preloaded by default.

Use the scripts with async so they do not hold up HTML parsing:

<script
  src="https://embed.zeeker.com/api/embed/widget/loader.js"
  data-zeeker-config="YOUR_CONFIG_ID"
  async
></script>

An asynchronous script still performs a small amount of work when it executes, so validate its effect on your own page rather than relying on a universal Lighthouse score.

Loading sequence

1. loader.js registers lightweight API shims and queues early calls.
2. Floating installs wait for host load and an idle window. Fixed/inline installs wait until their reserved target is near the viewport. Native WebViews load immediately because Zeeker is the app screen itself.
3. Calls that require the runtime now—open(), identify(), identifyObject(), logout(), and load()—skip the idle wait. A user-triggered download is requested at high priority; background downloads remain low priority.
4. The runtime requests the mode-aware boot payload.
5. Zeeker creates the visible surface required by that mode. A floating or trigger panel does not create its social iframe until it opens.

The visible loading stages use the same compact infinity mark and the selected light or dark theme. The host keeps its loading surface until the child is ready, so nested Chat startup does not display additional loading cards or a dark screen inside a light embed.

Buttons use consistent interaction feedback where the device supports haptics and the viewer has enabled it. Feedback also covers menus and framed sign-in controls. Scrolling, dragging, and disabled controls do not activate buttons.

Calling window.zeeker.load() is an explicit way to start the asynchronous runtime without opening a surface. window.zeeker.refresh() preserves its existing full-page reload behavior without first downloading a runtime that cannot be used.

Interaction-first trigger mode

Trigger integrations should use the smaller interaction-first entry point:

<button class="open-community">Community</button>
<script
  src="https://embed.zeeker.com/api/embed/widget/trigger.js"
  data-zeeker-config="YOUR_CONFIG_ID"
  data-zeeker-mode="trigger"
  data-zeeker-selector=".open-community"
  async
></script>

trigger.js listens for the configured host-page interaction and downloads runtime.min.js asynchronously only when the visitor activates it. Supplying data-zeeker-selector means the entry point does not need to fetch the embed config merely to discover which element opens Zeeker. If the selector is stored only in the published config, that small lookup runs later, after the host page has loaded and gone idle.

The Preload configurator option deliberately opts into loading a destination in the background once the full runtime is active. It can make the first open faster, but it transfers work to visitors who may never open Zeeker. Leave it off on performance-sensitive websites; reserve it for cases such as native app/WebView screens where an instant transition is worth the background request. The trigger.js entry point itself still waits for host interaction before loading that runtime.

Mode-aware boot data

The boot endpoint returns the published config, page context, counts, and at most the additional datasets needed for the selected presentation:

• A standard floating or trigger integration does not eagerly request unrelated feed data.
• A fixed social-snippet configuration requests only the visible snippet sources and its configured item limits.
• Nudge data is capped to the item needed for the current presentation.
• References and other optional collections are omitted unless the mode uses them.

This keeps the initial API response proportional to what the page can actually render.

Caching

Static widget code advertises short browser/shared-cache lifetimes so fixes can roll out without long-lived stale bundles:

• loader.js, trigger.js, and runtime.min.js: max-age=300, s-maxage=300, stale-while-revalidate=86400, with ETag validation.
• Boot responses contain live reply and reaction totals and therefore use no-store. A separate mode-scoped KVS object is used only as an outage fallback.

The runtime has a stable URL rather than a content-hashed, year-long cache key. Browser and CDN behavior still depends on the visitor's cache state, the hosting environment, and intermediary cache policy.

Web Vitals

The implementation is designed to reduce risk to the host page, but no third-party script can guarantee identical Lighthouse or field metrics for every site.

• LCP: the bootstrap does not request fonts, an iframe, or social content on its critical path. Floating and trigger modes keep their runtime off that path; visible fixed content begins only when its reserved target approaches the viewport.
• CLS: floating and trigger surfaces overlay the page. Generated fixed/inline snippets include responsive reserved heights so their content can mount without moving the host page.
• INP: the bootstrap installs small event/API shims. Opening Zeeker necessarily does more work in response to that interaction; trigger mode postpones that work until the visitor asks for it.

Test the exact published integration on representative mobile and desktop pages. In DevTools, disable cache and confirm:

1. loader.js is the only Zeeker JavaScript needed during initial parsing.
2. runtime.min.js starts after host load/idle for floating mode, near the viewport for fixed mode, or only after interaction for trigger.js.
3. No Zeeker iframe, Google Fonts request, or Zeeker preconnect appears before the selected mode requires it.
4. Fixed/inline containers have stable dimensions before their content mounts.

Run Lighthouse both with and without the embed, using the same browser profile and several samples, and compare the median rather than a single run.

CSP

Strict CSPs generally need these origins:

script-src    https://embed.zeeker.com;
frame-src     https://*.zeeker.com;
connect-src   https://api.zeeker.com https://embed.zeeker.com;
img-src       https://* data:;
style-src     'self' 'unsafe-inline';

Merge them into your existing policy instead of replacing it. Your configuration may require narrower or additional image origins depending on the content shown.

Network failures

If the runtime script fails to download, the bootstrap keeps queued calls and allows a later urgent method—or window.zeeker.load()—to try again. It does not run a hidden retry loop that competes with the host page.

If boot data cannot be retrieved, the widget attempts its configured cached fallback where available and otherwise does not mount a broken surface. Inspect [Zeeker] console messages and the Network panel when diagnosing a failure.

Self-hosting

The bootstrap, trigger entry point, and runtime are served from embed.zeeker.com; self-hosting is not currently supported. If policy requires proxying these assets through your own CDN, contact support so caching, CSP, and update behavior can be reviewed for that deployment.