AI builders default to heavy: full framework bundles, web fonts, icon libraries, generous markup. Prompts that ship lean from the start, plus the trim pass for what slipped through.
You prompted Lovable to build a landing for your product. The output looks great in the preview. You download the HTML and check the file size: 2.4MB. On hotel Wi-Fi it takes 8 seconds to render. On cellular it takes longer; some viewers close the tab before the page finishes.
What happened: the AI tool defaulted to its standard stack — Tailwind CSS via CDN, a JavaScript framework bundled in, Google Fonts pulled at runtime, a Lucide icon library with 1500 unused icons, generous wrapper divs everywhere. Every default is defensible in isolation; together they make a small page heavy.
Trimming the size is two passes — one in the prompt, one after.
The common contributors, in rough order of weight impact:
For a typical landing-page output, the total lands somewhere between 1MB and 3MB. Most of it is bytes the page doesn't need.
The fastest way to ship light is to never ship heavy. The prompt that asks for vanilla output from the first generation:
Build this as a vanilla HTML page. No React, no Vue, no framework. CSS in a
<style>block (no Tailwind CDN — write the specific styles needed). System font stack only (no Google Fonts, no web font imports). Icons as inline SVG (no icon library). JavaScript only where the page genuinely needs interactivity, inline in<script>. The output should be one HTML file under 200KB.
For tools that lean heavily toward framework output (v0 especially):
The deliverable is a single HTML page that ships to one client; it doesn't need to be a deployable React app. Use vanilla HTML + inline CSS + minimal vanilla JS. No build step. No npm dependencies. The reader opens the file in a browser; the file is the whole product.
This cuts the typical 2MB output down to 100-300KB on the first generation. The visual usually stays equivalent — most landing-page designs don't actually depend on the framework being there, the framework was just the AI tool's default starting point.
For tools that default to multi-file project scaffolds (Lovable, Cursor with code-mode), the explicit "one HTML file, no build step" framing flips the scaffold off.
The pattern is the same as the cross-tool portable-HTML prompts — being specific about what you don't want produces leaner output than asking for "a simple page."
For pages already generated, four trim moves catch most of the remaining weight.
If the output uses Tailwind, the Tailwind CDN serves the whole framework. The fix is to compile a static stylesheet with only the classes the page actually uses:
npx tailwindcss -i input.css -o output.css --content "./page.html"
Drop the resulting output.css inline into the HTML, remove the CDN script tag. Typical reduction: 250KB → 5-15KB for a landing page.
For Claude artifacts specifically, the export checklist covers the Tailwind step in more detail.
Open DevTools → Coverage tab → reload the page. The Coverage tool shows which JS bytes ran versus which sat unused. Anything over 50% unused is a candidate for removal.
For AI-generated pages that import the whole lucide-react package for 3 icons, the fix is to replace the imports with inline SVG (copy the 3 specific icons from the Lucide site as raw SVG, paste inline). Cuts 200KB+ down to 1-2KB.
For images under 50KB after conversion to WebP, base64-encode and inline. For larger images, keep them external on an asset host (or use lazy loading via the native loading="lazy" attribute).
Squoosh handles the compression locally in the browser — drag in a PNG, get a WebP at 60-80% smaller for visually equivalent quality.
Run the final HTML through a minifier. The biggest single win:
npx html-minifier-terser page.html -o page.min.html --collapse-whitespace --minify-css --minify-js
Typical compression: 30-50% reduction on AI-generated output (the wrapper-div pattern compresses well; the markup gets quite redundant).
What's worth aiming for, by use case:
For AI product landings shipped as a portfolio piece, the first two are the right targets.
Once the page is trimmed, drop it at a private link to test the actual feel on a different network — the local browser cache hides a lot of perceived weight. Free, no card, 7-day self-destruct, useful for sanity-checking how the page lands on cellular.
Three quick checks, in order of effort:
For most workflows, the DevTools number is enough. Lighthouse and PageSpeed are worth running once before the final ship.
Trimming page weight is for static deliverables — landings, reports, portfolios. It's not for:
The light-weight pass is for the case where the AI tool's defaults brought in more than the page needs. For most landing pages, reports, and one-off deliverables, that's most of the time.
For static HTML files that ship as a deliverable, the self-contained inlining work and the lightweight trim usually happen in the same pass — the goal is one portable file that's small enough to feel instant.
Nothing happened when you asked Claude to publish. There are four separate things it could mean, they look identical from the chat window, and each has a different fix. Here's how to tell them apart in order.
AI builders ship beautiful forms with no idea where the submissions go. Three shapes that actually work — mailto, third-party embed, serverless route — and the prompts that make each one ship cleanly.
AI tools default to modular HTML — clean for development, fragile for one-file delivery. Cross-tool prompt templates that produce a single portable file from the first generation.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.