AI integration has crossed a threshold. It is no longer a feature that distinguishes a product; its absence is increasingly a reason people choose a competitor. Businesses are adding chat assistants, recommendation engines, smart search and generated summaries at speed.
Many are also, without quite realizing it, adding several hundred kilobytes of JavaScript that runs on the main thread and quietly destroys their Interaction to Next Paint.
Both things are true at once, and the engineering question is how to get the first without the second.
The Pattern That Works
The applications winning with AI use it to make the core experience faster and more relevant. The ones failing bolt a chat bubble onto an unchanged site and call it an AI strategy.
Practically, that means asking what job the feature does before asking which vendor to use. Smart search that understands intent genuinely helps someone find a product. A chat widget that repeats the FAQ page does not, and it costs you performance for the privilege.
Why AI Widgets Are Heavy
A typical third-party AI chat widget ships a JavaScript bundle, a UI framework it may not share with yours, a websocket connection, and often an analytics layer. It frequently initializes on page load whether or not anyone opens it.
The damage shows up in two places. Input delay rises because the main thread is busy initializing something nobody asked for. Layout shift appears when the widget injects itself into the page after render. Both are measured, and both count against you.
Load It Only When It Is Wanted
The most effective single change: do not load the AI feature until the user signals interest.
Render a lightweight placeholder in plain HTML and CSS - a button, a search box, a chat bubble that is just a styled div. Load the real bundle on first interaction with it. Users who never open the assistant never pay for it, which is the large majority.
Where a feature must be available immediately, load it after the page is interactive rather than during load, and use requestIdleCallback so it fills a gap rather than competing with rendering.
Reserve the Space
Anything injected into the layout after render causes layout shift unless space was reserved for it. Give AI-driven sections an explicit min-height matching their loaded state.
This applies to recommendation carousels and generated summary blocks as much as chat widgets. A "recommended for you" strip that appears 1.2 seconds in and pushes the page down is a CLS failure with a friendly name.
Do the Inference Somewhere Else
Running model inference in the browser is possible and occasionally appropriate. For most business websites it is the wrong trade: large downloads, heavy main-thread work, and wildly variable results across devices.
Server-side or edge inference keeps the client light. The browser sends a request and renders a response, which is a problem browsers are extremely good at. Stream the response so the user sees text appearing rather than waiting for a complete answer, which improves perceived speed substantially even when total time is unchanged.
Design for the Failure Cases
AI features fail differently from ordinary features. They are slow sometimes, wrong sometimes, and occasionally unavailable entirely.
- Always provide a non-AI path. If smart search is down, conventional search must still work. If the assistant fails, the contact form is still there.
- Show progress honestly. A streaming response or a clear thinking state beats a spinner that conveys nothing.
- Set a timeout. An assistant that hangs indefinitely is worse than one that admits defeat and offers a human.
- Be clear about what it is. Users should know when they are talking to a machine, and how to reach a person.
Do Not Forget Accessibility
AI interfaces are frequently built as custom widgets, which means the accessibility work has to be done deliberately.
Chat interfaces need proper roles and live regions so screen readers announce new messages. Generated content that updates in place needs aria-live handled carefully, since an overly chatty live region is its own kind of hostile. Everything must be reachable and operable by keyboard, and focus must be managed when a panel opens and closes.
Measure Before and After
Take a Core Web Vitals reading before adding any AI feature and again after, in field data rather than on a development machine. INP in particular should be watched closely, since it is the metric these features most reliably damage and the one most sites already fail.
If a feature costs you a Core Web Vitals pass, that is not automatically a reason to remove it. It is a reason to know the trade you are making, and to decide it deliberately rather than discovering it in a ranking report three months later.
