Is your AI-powered website too slow? a 2026 performance checklist for SMBs.

A checklist for “AI‑ready” websites, like the one from Agtivation, rightly focuses on schema markup, clean content, and accessibility — the things that help AI engines understand your site. That is about being indexable. But a site that shows AI features (a conversational widget, personalised product grids, real‑time content assembly) creates a performance problem those checklists never touch. For example, a chatbot that loads a 2.1 MB JavaScript bundle and makes five synchronous API calls on every page hit can push the Time to Interactive past 8 seconds. Traditional speed advice — compress images, minify CSS, use a CDN — barely moves the needle because the bottleneck is the AI plumbing itself. We see SMBs launch advanced AI features, see conversion rates stall because the page feels heavy, and mistakenly blame the whole platform. The real fix is treating AI components as first‑class performance items, not just bolt‑on marketing magic.

Start by isolating AI impact. Open Chrome DevTools, record a page load, and look at the Network tab. Filter by third‑party domains associated with your AI services (e.g., widget provider, recommendation API). If an AI call takes more than 600 ms and it’s blocking the main thread, that’s a red flag. A quick litmus test: temporarily disable the AI feature via a query string (?noai=1) and compare Lighthouse scores. If the Performance score jumps from 35 to 65, the AI integration is your main culprit. Next, profile JavaScript execution. Many chatbot widgets run a full TensorFlow.js model on the client; you can spot that in the Performance panel as a long, synchronous “scripting” block. For server‑side AI, monitor TTFB for the AI endpoint separately. Tools like WebPageTest let you script a multi‑step journey so you can see exactly when recommendation data arrives. The goal is a clear metric: AI‑induced delay = Time to Interactive with AI active minus Time to Interactive with AI suppressed. That number tells you where to focus.

Different AI features demand different fixes.

Chatbots - Lazy‑load the entire conversation interface: load the script on the “load” event with a 2‑second delay, or on the first scroll. - Pre‑fetch and cache common intents. If “shipping policy” generates the same static reply, serve it from a CDN edge with a 5‑minute TTL instead of hitting your AI backend every time. - If your model runs on‑device, shrink it. Quantising a BERT‑based model from float32 to int8 often cuts inference time by 40 % with negligible accuracy loss.

Recommendation engines - Move from client‑side “load all, filter later” to server‑side filtering that returns only the top 4 items, reducing payload size. - Pre‑fetch recommendations during idle time: after the page is interactive, silently fetch suggestions for the next likely page and store them in a cookie or session storage. - If personalisation is user‑account‑based, render recommendations server‑side and revalidate every 30 minutes with stale‑while‑revalidate.

Dynamic AI‑generated content (e.g., personalised headlines, summary blocks) - Always default to server‑side rendering. Generating content inside the visitor’s browser adds N milliseconds of scripting for each element. - Use partial hydration: load the static page shell first, then progressively hydrate only the AI‑generated sections as they become ready. - If the content is cacheable per segment (e.g., “visitor from Germany gets the same tailored message”), cache at the edge using a CDN with a customised cache key.

Run through these items every time you deploy or update an AI feature. A “no” to any of the first five means measurable slowdown.

1. Every third‑party AI script (chat, search, personalisation) loads with “defer” or “async” — none block rendering.
2. Client‑side AI models are quantised and do not exceed 500 KB before decompression.
3. AI API responses that return static or slowly‑changing data are cached with an explicit TTL (browser cache, CDN, or server‑side cache).
4. A fallback for each AI service is in place: a static FAQ instead of a spinning chatbot, a default product list instead of a blank recommendations panel, or a static headline when generation fails.
5. You can measure the exact user‑facing latency of each AI call using a real‑user monitoring (RUM) tool or custom performance.mark entries.
6. Your CDN is configured to cache AI‑generated assets (like dynamically resized product images) close to the user, not just static files.
7. On mobile, AI‑heavy components are either replaced with a lighter alternative or only loaded when the visitor actively engages.
8. You review AI component performance during every sprint, treating an AI API timeout as seriously as a server error.

Once the checklist is applied, set up ongoing monitoring so you catch regressions early. We instrument AI calls with custom timers: wrap the API fetch with `performance.mark('ai‑call‑start')` and `performance.measure('ai‑call‑duration')`. This data flows into our RUM dashboards alongside standard metrics. If the 75th percentile AI response time moves from 400 ms to 1.2 seconds, we know immediately that something changed — perhaps the backend model got larger or a new data source was added. For debugging, tie AI‑specific error logs to user session IDs; when a shopper complains about a stuck recommendation carousel, you can pull the exact API response that caused it rather than guess. Balancing is an honest conversation about what the business values: a 10 % uplift in recommendation click‑through might not be worth an 800 ms additional load time if overall conversion drops. Implement progressive enhancement: deliver the essential content and core purchase path in under 2 seconds, then asynchronously mount the AI features. That way, even on a flaky 4G connection, the customer can buy while the smart bits finish loading in the background.