Why AI-built websites load slow
The AI built the site quickly. Now the site loads slowly. The hero image takes three seconds to paint. The page jumps around as elements load in different orders. By the time the layout settles, the visitor has already started thinking about whether to bounce.
This is not because AI is bad at performance. It's because AI tools optimize for what looks finished in the preview pane, and the preview pane lies. The preview runs on a fast development machine, on a fast local network, with no third-party scripts loading from real CDNs, with cached assets that don't actually need to be downloaded. The preview is showing you the site at its best possible performance. Real visitors are loading it at its actual performance, and the gap is usually big.
Five reasons this gap is so consistent. Each has a specific diagnostic and a specific fix.
Reason one: images shipped at full source size
The hero image looks great in the preview. It's also a 4MB JPEG straight from a stock photo source. The AI inserted it without resizing it for the actual viewport it'll render in. Real visitors download all 4MB, even on a phone that'll never render it larger than 800 pixels wide.
The diagnostic is to open the network tab in devtools, load the page, and look at the size of each image asset. If any single image is over 200KB, it probably needs to be smaller. If any image is over 500KB, it almost certainly does. Modern formats (WebP, AVIF) compress aggressively without quality loss visible at typical web sizes.
The fix is mechanical. Resize images to the dimensions they'll actually render at, convert to a modern format, and serve responsively (different sizes for different viewport widths). This is one of the highest-leverage performance fixes because images are usually the largest single asset on any page.
Reason two: render-blocking scripts at the top
The AI added analytics, a chat widget, a tag manager, a fonts loader, maybe a feature-flag service. Each of these was inserted as a script tag in the head of the document. The browser hits each script tag, stops everything it's doing, fetches the script, executes it, then continues parsing.
The visitor sees a blank page until all those scripts have finished. Even if each script is small, the cumulative cost of synchronous loading across half a dozen tags can push the time-to-first-paint past three seconds, which is where visitor attention starts breaking down.
The diagnostic is to look at the head of your HTML for <script> tags. Any script tag without async or defer attributes is render-blocking. Most third-party scripts can be loaded asynchronously without breaking their functionality.
The fix is to add defer to script tags that don't need to execute before the page renders, and async to scripts whose execution timing doesn't matter. Critical-path scripts (the ones that genuinely need to run before the page is interactive) stay synchronous but get audited for whether they're really critical.
Reason three: font waterfalls
The AI used three custom fonts because each one looked right in the preview. Each font is loaded from a different vendor's CDN. The browser has to fetch each one before it can render text in that font. While the fonts are loading, the visitor sees either nothing (font-display: block) or text in a fallback font that jumps to the real font once it loads (font-display: swap).
Either path is bad. The "nothing" path means the visitor sees an empty page longer than they should. The "swap" path means the page jumps as fonts load, which is its own performance signal Google measures (Cumulative Layout Shift).
The diagnostic is to check how many custom fonts the site loads. More than two is almost always too many. Look at the network tab and time how long font loading takes on a throttled connection.
The fix is to consolidate to one or two custom fonts, preload them in the document head, and use system-font fallbacks that match the custom font's metrics closely so the swap is less visually disruptive.
Reason four: third-party embed weight
The site has a chat widget, a video embed, a Twitter timeline, an Instagram feed, a Calendly button, a Stripe checkout, an analytics script. Each one is loaded from a different third-party domain. Each one loads its own JavaScript, its own CSS, its own assets. The cumulative weight can easily double or triple the page's total size, often without the operator realizing it.
The diagnostic is to view the page in devtools and look at the total transferred size. Compare to the size of just your own assets (HTML, CSS, your scripts, your images). The gap is the third-party embed cost.
The fix is to question every embed. Does the chat widget have to load on every page or just on the contact page? Does the analytics need a 200KB tag manager or would a 5KB lightweight tracker do? Can the video embed be replaced with a static thumbnail that loads the real embed only when clicked? Each embed audit reduces the page weight by the size of that embed.
Reason five: layout shift cascades
The page loads, the visitor starts reading, then a banner appears at the top and pushes everything down. They lose their place. Then an image finishes loading and pushes content again. Then a font swaps and the line breaks recalculate. The page is visibly unstable for several seconds.
This is Cumulative Layout Shift (CLS), and it's one of the metrics Google measures as a Core Web Vital. High CLS hurts both visitor experience and search ranking. AI tools generate it consistently because they don't reserve space for elements that load asynchronously, so when those elements arrive, everything else has to move.
The diagnostic is to load the page on a throttled connection and watch how much things jump as the page settles. Devtools has a CLS measurement that quantifies it.
The fix is to reserve space for asynchronously-loading content (set explicit dimensions on images and embeds, reserve space for ads and banners, use font-display strategies that minimize swap shift). This is one of the cheaper structural fixes once you know to look for it.
How to measure
The three Core Web Vitals are the right baseline: Largest Contentful Paint (when the main content becomes visible), Interaction to Next Paint (how responsive the page is to clicks and taps), Cumulative Layout Shift (how visually stable the page is as it loads). Google publishes them, measures them across the real web through Chrome's real-user telemetry, and uses them as ranking signals.
The diagnostic tool is PageSpeed Insights (or Lighthouse, which is what powers it). Run the URL through it, look at the report, focus on the failures. The report tells you exactly which assets, scripts, fonts, or layout shifts are responsible for poor scores.
The pattern that drove me to take Core Web Vitals seriously was the three-leg gate methodology on this site's own /log mesh visualization. The gate's performance leg caught regressions that the structure and function legs missed. Performance isn't a separate optimization pass at the end. It's a gate that runs alongside structure and function from the start.
Two-tier fix
If the site has any of the five reasons above and needs to ship soon, the quick-wins tier handles the worst of it: resize the largest images, defer the obvious render-blocking scripts, drop fonts you don't truly need. A focused afternoon on quick wins usually moves the Core Web Vitals scores from poor to acceptable.
The structural tier takes longer but produces durable performance. Consolidate fonts to a system that works. Audit and prune third-party embeds. Reserve space for asynchronously-loading elements. Build the performance-mindedness into the next iteration so the site stays fast as it grows.
If the site is already shipping slow, both tiers apply. The quick wins stop the immediate bleed. The structural pass keeps it from coming back.
Got an AI-built site that's loading slow and you can't tell which of the five reasons is doing it? Send the site URL and a PageSpeed Insights report. VibeKoded can scope the build, ship the prototype, or hand off the production site. → Work with VibeKoded