TLDR: AI-generated pages are often slow for reasons that have nothing to do with how they look. The model quietly inlines full-size images as base64, loads font families and weights the page never uses, and pulls entire frameworks from a CDN to do one small thing. You do not see it on a fast connection, but the person opening your link on a phone does. To make AI pages load fast, put the constraints in your prompt (images by URL not base64, two fonts max, no needless frameworks, lazy-loaded images, a target page weight), then check the total in your browser’s Network tab. Serving the finished page from the edge handles the rest.
You asked AI to build a page, it looks great, and then you open the link on your phone and it hangs for a second before anything appears. The design is not the problem. The weight is. AI models optimize for “this works and looks right,” not for “this loads fast on a slow connection,” so they reach for the heaviest convenient option at every turn. The result is a page that feels fine on your laptop and sluggish everywhere else.
The fix for how to make AI pages load fast is mostly about telling the model what not to do. Almost all of it happens in the prompt, and the rest is a two-minute check before you share. Here is where the weight hides and how to cut it.
Why are AI-generated pages slow?
A page feels slow for one of two reasons: it is heavy (too many bytes to download) or it is blocked (the browser cannot paint until something finishes loading). AI output tends to be both, and it is rarely your fault. When you ask for “a landing page with a hero image,” the model makes the choices that are easiest to get right, not the ones that are lightest.
Those easy choices add up fast. An inlined photo instead of a linked one. A font library “just in case.” A charting framework for a single bar chart. Each one is reasonable in isolation. Together they turn a page that should weigh 200 KB into one that weighs three megabytes, and most of that sits between the person and the first thing they see.
The biggest offender: images encoded as base64
If one thing is making your AI page heavy, it is probably images. When you ask AI to include a picture, it often encodes the whole image as a base64 string and pastes it directly into the HTML. It is convenient, the file stays self-contained, and nothing breaks. It is also the single worst thing you can do for load speed.
Base64 encoding makes an image about 33 percent larger than the original file. Worse, because the image data now lives inside the HTML, the browser has to download all of it before it can render the page, and it cannot cache the image separately or load it lazily. One full-size hero photo inlined this way can be a megabyte of text sitting in front of your first paint.
The fix is to reference images by URL, or to keep inlined images tiny. A small icon or a 1 KB SVG as base64 is fine. A 2000-pixel-wide photo is not. Tell the AI explicitly:
Reference all photos by URL rather than embedding them as base64. For any image you do inline, keep it under 5 KB. Use appropriately sized images, not full-resolution ones scaled down in the browser, and add loading=“lazy” to every image below the fold.
That one instruction often cuts page weight by more than half. Compressing the images you do use (a hero photo rarely needs to be more than 150 to 250 KB) handles most of the rest.
Fonts: load two, not twelve
The second most common source of bloat is fonts. AI will cheerfully load three or four font families, each with every weight from thin to black, when the page actually uses a regular and a bold of one font. Every weight is a separate file the browser downloads, and custom fonts block text from rendering until they arrive, so a heavy font setup shows up as a flash of invisible text on slow connections.
Pick one or two families and only the weights you need. If speed matters more than a specific look, system fonts cost zero bytes because they are already on the device. Ask for:
Use at most two font families, and load only the specific weights the page uses (for example 400 and 700). Add font-display: swap so text renders immediately in a fallback while the font loads. If a custom font is not essential, use a system font stack instead.
Frameworks and libraries you do not need
The third offender is the heavy dependency loaded for a light job. AI will pull the full Tailwind CDN build to style a handful of elements, load an entire charting library for one bar chart, or add an animation library for a single fade-in. Each of these is hundreds of kilobytes of JavaScript that has to download and run before the page is interactive.
For a simple page, you rarely need any of it. Plain CSS handles layout and styling. A few lines of vanilla JavaScript handle most interactions. A single chart can be drawn as inline SVG with no library at all. Tell the model to stay lean:
Do not load any external CSS or JavaScript frameworks. Write plain CSS and vanilla JavaScript. If the page needs a chart, draw it as inline SVG rather than importing a charting library. Keep all scripts at the end of the body and add the defer attribute so they do not block rendering.
The exception is a genuinely complex app, where a framework earns its weight. For the kind of page you build to share a link, it almost never does.
What AI reaches for by default, and the lean swap
| What the AI does by default | Why it is slow | Ask for this instead |
|---|---|---|
| Inlines photos as base64 | ~33% larger, blocks first paint, no caching | Reference images by URL, compress them |
| Loads full-size images | Megabytes to download and scale | Correctly sized images, loading="lazy" below the fold |
| Loads many fonts and weights | Each weight is a separate blocking file | Two families max, only the weights used, font-display: swap |
| Pulls a CSS framework from a CDN | Hundreds of KB to style a few elements | Plain CSS |
| Imports a charting library | Large JS bundle for one chart | Inline SVG chart, no library |
Puts scripts in the <head> | Blocks rendering until they load | Scripts at end of body with defer |
A copy-paste “fast by default” prompt
Instead of fixing weight after the fact, bake the constraints into your first prompt. Paste this block alongside your actual request and the model builds lean from the start.
Build this as a single self-contained HTML file, and optimize it to load fast on a mobile connection. Follow these performance rules:
- Reference all photos by URL, not base64. Keep any inlined image under 5 KB.
- Use correctly sized images, and add loading="lazy" to every image below the fold.
- Use at most two font families, only the weights the page actually uses, with font-display: swap. Prefer a system font stack if a custom font is not essential.
- Do not load any external CSS or JS frameworks. Use plain CSS and vanilla JavaScript. Draw any chart as inline SVG.
- Place scripts at the end of the body with the defer attribute so nothing blocks rendering.
- Aim for a total page weight under 500 KB. Tell me the approximate total when you are done.This pairs well with the broader prompting patterns in AI prompts that produce a page worth sharing, and once the first draft is lean you can polish it with follow-up prompts without re-bloating it.
How do I measure page weight and load speed?
You cannot improve what you do not measure, and the check takes two minutes. Open your page in Chrome, open DevTools (right-click, Inspect), and click the Network tab, then reload. At the bottom you will see the total transferred size and the load time. Sort the list by size to find the heaviest files, which will almost always be images.
For a score and specific suggestions, run Lighthouse (it is a tab inside DevTools) or paste your URL into Google PageSpeed Insights. The one habit that matters most: test on a throttled connection. In the Network tab you can switch “No throttling” to “Slow 4G” and reload. That is closer to what the person opening your link actually experiences, and it turns invisible bloat into something you can feel.
The last mile: serving the page fast
A lean page still loads slowly if it is served from a single server on the other side of the world. The file size is only half of speed. The other half is distance, how far the bytes travel and how quickly the server responds. This is the part you cannot fix in the prompt.
Once your page is trimmed, publishing it to a host that serves from the edge is what makes it fast for everyone, not just people near one data center. With VisiblePage you paste your HTML or drop a ZIP and get a live URL immediately, no build step, toolchain, or domain setup, and the page is served fast from the edge so it loads quickly wherever your reader is. Every button, chart, and animation stays interactive because you are sharing the real page. You can keep it public, private, or password-protected, point a custom domain at it, and because it is one canonical link, re-publishing an even leaner version updates what everyone sees without changing the URL.
Try it now: Publish your AI-generated HTML with VisiblePage and get a fast live link in seconds.
Frequently asked questions
Why is my AI-generated page so slow?
Usually weight, not design. AI tends to inline images as base64 strings that can run into megabytes, load several font families and weights you never use, and pull a whole CSS or chart framework from a CDN to do one small thing. None of it looks wrong on your fast connection, but on a phone over mobile data it loads slowly. The fix is mostly in the prompt: ask for compressed images or real URLs, one or two fonts, and no heavy libraries you do not need.
How do I make AI generate a lightweight page?
Put the constraints in the first prompt. Ask for a single self-contained HTML file with no external frameworks, images referenced by URL or kept small rather than inlined as base64, at most two font families with only the weights you use, images below the fold set to loading=lazy, and any scripts deferred to the end. Then ask it to keep the total page under a target size, like 500 KB.
What is a good page weight to aim for?
For a simple shareable page, aim for well under 1 MB total, and under 500 KB is very achievable for a text-and-image page. The single biggest lever is images: one uncompressed hero photo can outweigh everything else on the page combined. Compress images and the rest usually falls into place.
Do base64 inline images slow a page down?
They can. Base64 encoding makes an image about 33 percent larger than the raw file, and because the data lives inside the HTML, the browser cannot cache it separately or load it lazily. One or two small icons as base64 is fine. A full-size hero photo inlined as base64 bloats the HTML and delays the first paint. Reference large images by URL instead.
How do I measure how fast my page loads?
Open the page in Chrome, open DevTools, and look at the Network tab for the total transferred size and load time. Run Lighthouse (built into DevTools) or Google PageSpeed Insights for a performance score and specific suggestions. Test on a throttled connection, not just your fast desktop, because that is what most recipients actually have.
Ready? Turn your trimmed page into a fast live link and your first page is free.