How Fast Are AI-Built Sites? What Actually Decides It
Speed comes from what the page ships, not from who wrote it. A generated marketing page is mostly text, a few images and a little script, so it loads like any other small page. What makes AI-built sites slow is what makes hand-built ones slow: heavy images, too many fonts, and scripts nobody needed.
That framing matters, because "is AI code fast" has no answer. Speed is a property of the output, and the output is a page in a browser. So this post covers what a build actually contains, which decisions cost you seconds, and how to measure the result instead of arguing about it.
What actually decides how fast a page loads?
Three things, roughly in order of impact. How many bytes the browser downloads. How many separate requests it makes to get them. How much work the processor does before the page becomes usable. Almost every performance discussion is one of those three wearing a different hat.
Images dominate the first one on nearly every marketing site. A hero photo dropped in straight from a camera can outweigh the entire rest of the page combined, and no amount of clever markup compensates for that. Compressing one file is usually the largest single win available to you.
The third one, processor work, is where frameworks, embeds and analytics tags land. Every third-party script is a request, then a parse, then an execution, and all of it competes with your own content for the main thread. This is why a visually modest page can still feel sluggish on a mid-range phone.
None of those three care who produced the markup. A generated page and a hand-written page carrying identical assets behave identically, because the browser has no idea which is which and no reason to care.
Is generated code slower than hand-written code?
Not inherently, and not usefully comparable in the abstract. The honest version of the question is narrower: does this particular build ship more than it needs to? That is answerable, and you answer it by looking rather than by reasoning about the tool that produced it.
Where generated output can go wrong is over-inclusion. Ask for a page with a gallery, a map, a chat widget and an animated hero, and you get all four, each with its own weight. The generator is doing what you asked. Nobody is standing behind it asking whether the map earns its place.
Where hand-written code goes wrong is the same place, just slower. Human-built sites accumulate plugins, tags and forgotten experiments over years. The difference is that a generated page starts small and grows by your explicit requests, which makes the weight easier to trace back to a decision.
What does a Zugo build actually ship?
A working project, checked before you get it. Every build is booted in a sandbox first, so a build that fails to open is reported as a failure instead of being handed over as a blank page. That lowers the risk of publishing something broken. It does not remove it, and it says nothing about weight.
| What lands in the page | Where it comes from | What it costs you |
|---|---|---|
| Markup and styles | The build itself | Small, and mostly text |
| Your images | Uploaded or linked by you | The largest variable on most pages |
| Fonts | The design of the build | One or two weights is cheap, six is not |
| Interactive behaviour | What you asked for | Grows with the number of moving parts |
| Analytics tag | The Google Analytics connector, if you add it | A third-party request on every visit |
| Database calls | Supabase, if the project has login or stored data | Depends on the page, not on the builder |
Read that table as a checklist rather than a verdict. The two rows you control most directly, images and fonts, are also the two that decide the outcome on the majority of simple sites.
Which choices make a generated page slow?
Four, and they repeat across almost every slow page we have seen described.
Uncompressed images. A full-resolution photograph used as a background is the single most common cause. Resize it to the size it is actually displayed at before you upload it.
Font sprawl. Each additional family and weight is another file to fetch and another moment where text can shift. Two weights of one family is usually enough for a marketing page.
Third-party embeds. Chat widgets, map iframes, social feeds and video players are entire applications loaded inside your page. Each one is a reasonable choice on its own, and four together are a decision you never consciously made.
Doing everything on one page. A single page carrying a shop, a blog feed and a booking form loads all three for a visitor who wanted one. Splitting them into a multi-page build costs 12 credits for the first three pages and 3 for each page after that, which is often cheaper than the traffic you lose.
How do you measure it instead of guessing?
By running the page through a tool that reports the same metrics search engines use, from a device that resembles what your visitors hold.
| Metric | What it measures | How to read it |
|---|---|---|
| LCP | When the main content becomes visible | Almost always dominated by your hero image |
| CLS | How much the layout jumps while loading | Usually fonts or images without reserved space |
| INP | How quickly the page responds to a tap | Usually scripts competing for the main thread |
| Total page weight | Bytes downloaded | The number to fix first, because it is the easiest |
Google publishes thresholds for those metrics and updates them, so take the current numbers from its documentation rather than from any blog post, including this one. What matters more than the exact bar is the direction: measure once before you change anything, then again after.
Do not measure a preview on a fast laptop over office wifi and call it representative. Test on a phone, on mobile data, on the published address. If you want traffic data alongside it, connecting analytics takes a few minutes.
What can you fix with an edit, and what needs the code?
Most of it is an edit. Ask for fewer fonts, a lighter hero, a removed embed, or the gallery moved to its own page, and the build changes. An edit costs 3 credits, so a round of trimming is cheap enough to do speculatively.
What an edit will not do is compress the photograph you uploaded. That happens before it reaches the builder, in whatever image tool you already have, and it is worth doing properly. The related question of using your own images covers formats and sizing.
Deeper work belongs in the code. Export the project to GitHub, profile it, and change what the profile tells you to change. That path is described in exporting the code, and it is also where a developer would start.
Does hosting affect the result?
Yes, and it is one of the few parts you do not have to think about at first. A published project is served from <slug>.zugo.run, and a custom domain connects on top of it without changing the build.
If you would rather own the serving layer, the Vercel connector deploys the project to your own account, and after a GitHub export you can deploy the repository anywhere you like. Hosting is a choice you can revise later, which is not true of a page built around six fonts.
What are the honest limits of this answer?
Three, stated plainly.
We are not publishing a benchmark. No number in this post claims how fast your page will be, because that depends on your images, your integrations and your visitors' devices. Treat any speed claim from any builder, ours included, as unverified until you measure your own page.
The sandbox check is about loading, not performance. It confirms the build boots. It does not grade weight, and it will not warn you that your hero image is enormous.
Heavy applications are a different problem. A dashboard reading live data or a 2D browser game has a performance profile that page-speed advice does not cover, and genuinely deep optimisation on a complex product is engineering work rather than a prompt. Zugo does not replace a development team there.
The quickest way to see where a build starts is to make one and measure it yourself. Describe a page at zugo.dev, publish it, and run the published address through a speed tool before you add a single image. That baseline tells you more than any general claim about AI-built sites.