Performance
Keep Liquid Glass performant by using compact modes, optional peers, lazy heavy effects, reduced motion, and bounded preview rendering.
#Use the Smallest Surface That Works
Start with the component that solves the product job with the least runtime cost. `GlassCard`, `GlassButton`, `GlassTabs`, `GlassSidebar`, `GlassDataGrid`, and `GlassDashboard` cover many production screens without media analyzers, WebGL, or continuous animation.
Reach for visualizers, 3D, particle effects, realtime collaboration, and AI service surfaces only when they carry product meaning. If a screen is a billing form, a stronger card and focused form states are usually better than a heavy animated background.
#Guard Heavy Effects
Canvas, media analyzers, WebGL surfaces, realtime collaboration, and scroll-linked effects need explicit runtime guards. Pause them when hidden, when the tab is backgrounded, when the surface is outside the viewport, and when reduced motion is enabled.
For dashboards and admin screens, prefer static chart snapshots until the user asks for live updates. For media surfaces, show poster art and controls first, then start analyzers only when audio or video is actually playing.
const reduceMotion = window.matchMedia('(prefers-reduced-motion: reduce)').matches;
const shouldAnimate = isVisible && isPlaying && !reduceMotion;
return <GlassMusicVisualizer isPlaying={shouldAnimate} contained compact />;#Bundle Strategy
Keep optional peers tied to feature routes. Chart peers belong with analytics pages. Three.js peers belong with 3D demos or spatial product surfaces. Realtime peers belong with collaboration routes. This keeps simple app shells from paying for features they do not render.
In Next.js, lazy-load heavy client-only surfaces and provide a stable fallback. Do not dynamically import the entire product shell just to avoid one client component; isolate the expensive feature.
import dynamic from 'next/dynamic';
const MediaConsole = dynamic(() => import('./MediaConsole'), {
ssr: false,
loading: () => <GlassCard>Loading media controls...</GlassCard>,
});#Measurement Checklist
Run a production build, inspect the route in a real browser, and check interaction cost after hydration. Watch for large layout shifts, overlay controls escaping containers, long-running animation loops, and idle CPU from visual components left mounted offscreen.
For launch pages and docs, preview cards should use `contained`, `compact`, fixed height, and disabled portal controls when available. A component demo that leaks a fixed button into the header is a product bug, not just a visual blemish.