Performance and Core Web Vitals.

Glopzi has a self-imposed performance budget. Numbers we’ll never blow through without a very good reason.

• Runtime JS: under 50 KB gzipped, base install. Adds for features you actually use (WebGL, split text, smooth scroll) load on demand.
• Configuration JSON: typically under 10 KB per site. Larger sites with dozens of animations still stay well under 50 KB.
• LCP impact: under 100 ms on a typical site. The runtime loads afterfirst paint and doesn’t block render.
• CLS impact: under 0.05. Animations run on transforms and opacity, not properties that trigger layout shifts.
• TBT impact: under 50 ms. The runtime doesn’t do heavy work on the main thread.

We monitor these on a Lighthouse pipeline against representative sites and refuse to ship releases that regress them.

When a visitor lands on a page with Glopzi installed, the loader script makes a single request for the compiled bundle for that site. The bundle is built per-site, and tree-shaken: it only includes the code paths you use.

• Only fade-and-translate animations? The bundle skips the WebGL renderer, the split-text module, and the smooth scroll engine. About 35 KB.
• Use a WebGL background?Three.js loads on demand the moment we encounter a WebGL effect. Bundles for individual effects (Aurora, Dot Grid) load separately, so a page with Aurora doesn’t pull Dot Grid’s code.
• Use split text? The SplitText helper loads only when an animation has the split-text modifier on. Bundles size grows by ~6 KB.
• Smooth scroll on? Lenis loads when the toolbar toggle is enabled. Around 8 KB extra.

The CDN serves compressed bundles with long cache headers. Returning visitors get them from cache and the impact is near zero.

Glopzi animates transforms (translate, scale, rotate), opacity, and filters by default. Browsers run these on the compositor thread, off the main thread. That’s why a Glopzi animation can play while your page’s JavaScript is busy doing other things.

Properties that dohit the main thread (width, height, top, left, padding, margin) are available in the editor but discouraged for high-frequency animations. We surface them under a small “may impact performance” note in the property panel.

When animations start with elements at opacity 0 or translated off-screen, there’s a brief moment between first paint and animation startup where elements would be visible at their natural state. That’s a flash of unstyled content, FOUC for short.

Glopzi prevents this with a small stylesheet served alongside the JavaScript bundle. It applies the “at rest” state (opacity 0, translated, etc.) so first-paint already looks correct, and the animation starts from that state when the JavaScript catches up.

On WordPress and plain HTML, the stylesheet is included in the JavaScript bundle and applied when the script runs. On streaming SSR frameworks (Next.js, Astro, Remix, SvelteKit), it ships as a separate <link> tag so it can apply before first paint. See the Next.js integration for the pattern.

Real numbers we’ve measured against typical installs:

• LCP (Largest Contentful Paint): the anti-FOUC stylesheet ensures Glopzi never delays your largest element. Pages that didn’t use Glopzi and pages that do measure within 50ms of each other.
• CLS (Cumulative Layout Shift): transform-based animations don’t shift layout. Sites that move from layout-property animations (top/left changes) to Glopzi typically improve their CLS score.
• FID and INP (Interaction): the runtime doesn’t do per-frame work on the main thread, so interactivity stays sharp even during complex animations.

Sites that pass Core Web Vitals before Glopzi pass them after. Sites that don’t pass before Glopzi don’t suddenly fail because of us.

What you can do for performance:

• Disable expensive animations on mobile. WebGL backgrounds drain battery on phones. Use breakpoint overrides to turn them off below the tablet breakpoint.
• Group rather than stagger many animations. Ten time animations on ten elements with overlapping triggers create more work than one group with ten members.
• Prefer in-view triggers over load. Animations that only run when scrolled into view defer their cost until needed. Animations triggered on load all run at once on first paint.
• Be sparing with WebGL. One Aurora is beautiful. Five Auroras on the same page is a calculator-grade GPU workout.

• Responsive animations done right covers the “disable on mobile” pattern in depth.
• Troubleshooting has the recipes for when you suspect a regression.
• WebGL backgrounds covers their per-effect cost and when to use them.