What 154 Websites Built by Lovable Actually Weigh
We measured page weight, request count and LCP on 154 websites that Lovable built from our prompts. The median transfers 1.15 MB and paints in 1.1 seconds. Images are almost all of it.
5
min read
Table of Contents
Sites built by Lovable are not slow by default. They are heavy, and almost all of the weight is images nobody asked to be that size.
Every site in our library is built by Lovable from one of our prompts, and the median one transfers 1.15 MB and reaches Largest Contentful Paint in 1.1 seconds. That is faster than most hand-built small business sites, and it is the opposite of what people assume about AI-generated code.
We measured 154 of them. Each one was built by Lovable from a single prompt, published to a lovable.app address, then loaded in a real Chromium browser at 1366 by 900 with every response recorded until the network went idle. Nothing here is estimated by a tool. These are the bytes the browser actually received.
The numbers
Median transferred: 1,180 kB. The mean is 1,268 kB, so the distribution is only mildly skewed.
Ninetieth percentile: 1,903 kB. The heaviest single site transferred 3,491 kB.
Over 1 MB: 98 of 154 sites, which is 64 percent. Eleven sites went over 2 MB.
Requests: median 13, maximum 26.
Largest Contentful Paint: median 1,124 ms, seventy fifth percentile 1,804 ms.
LCP over 2.5 seconds: 23 sites, which is 15 percent.
Thirteen requests is a genuinely good number. A small business site on a typical page builder will make sixty to ninety. These builds produce one JavaScript bundle, one stylesheet and the images, with no plugin chain and no tag manager behind them.
So the request count is not the problem. The bytes are.
Page weight across 154 sites built by Lovable: bytes transferred per page with a cold cache, in 200 kB bands. The orange band holds the median, 1.15 MB.
Images are roughly 72 percent of the weight
Broken down by file type across the library, images account for about 72 percent of transferred bytes, JavaScript for 24 percent and CSS for 2 percent.
Share of transferred bytes by file type across the same 154 sites. JavaScript is near identical on every site, so it never explains why one page is heavier than another.
That single ratio explains the whole distribution. The lightest site we measured, an SEO agency page, transfers 423 kB because it is almost entirely type and rules with one small photograph. The heaviest, a vacation rental page, transfers 3.4 MB because it carries a full bleed hero, a gallery and a set of interior shots, none of them resized.
The four heaviest sites in the library are all photography led: a vacation rental at 3.4 MB, a personal brand page at 2.9 MB, a travel blog at 2.6 MB and an interior design studio at 2.6 MB. The four lightest are all text led. There is no third category.
The JavaScript is not the villain
A quarter of the bytes is JavaScript, and it is close to a fixed cost of the stack Lovable builds on. Every one of these sites ships React, Vite, a router and an animation library whether the page animates much or not. That baseline lands at roughly 250 to 350 kB transferred.
You can argue that a brochure site does not need React at all, and you would be right. But it is not what makes any particular site heavy, because it is the same on the lightest page and on the heaviest. If you want a lighter site, the lever is the photographs.
Three lines that cut the weight by a fifth
All three belong in the prompt rather than in a clean up afterwards.
Name the image dimensions. Hero images no wider than 1600 px, thumbnails no wider than 600 px. Left alone, the model takes whatever the image source hands it, which in our library meant hero images 1920 px wide.
Ask for lazy loading below the fold explicitly. It already appears on 86 percent of images in our library, so this line mostly guards against the exception rather than changing much.
Cap the number of photographs per section. A twelve image gallery is the most reliable way to push a page past 2 MB. Six reads the same and carries half the photographs.
None of this asks you to understand the build. It asks you to decide the sizes yourself instead of leaving the decision to the model, which is the same principle that governs colour, type and layout.
We tested the three lines
Advice about prompts is cheap, so we checked this one. We took the five heaviest photography led prompts in the library and had Lovable build each of them twice on the same day: once exactly as written, and once with the three lines above added at the end. Nothing else changed. Every finished site was then measured three times, the same way as the rest of this study, and we compared the medians.
Vacation rental: 3.08 MB without the lines, 2.20 MB with them, 29 percent lighter.
Travel blog: 1.65 MB to 1.00 MB, 39 percent lighter.
Wedding venue: 1.89 MB to 1.55 MB, 18 percent lighter.
Personal brand: 1.94 MB to 1.99 MB, no real change.
Interior design studio: the version with the lines failed to build, so there is nothing to compare.
Across the four pairs that built, the three lines made the page about a fifth lighter on average, and up to a third lighter on the sites that lean hardest on photography. You could see why in what Lovable did during the build: with the lines in place it generated smaller images to begin with, capped the hero at 1600 px instead of 1920 px, and on the travel blog it resized every other photograph to 600 px on its own.
The personal brand page is the useful exception. Its main image is a cut out portrait, which the model treats as the hero, and the lines allow a hero up to 1600 px. If one large image carries your design, these lines will not shrink it. Give that image its own size.
Lazy loading made no measurable difference, because the sites built without the line already lazy loaded nearly every image below the fold. Largest Contentful Paint did not move consistently either: it improved on one site, stayed level on two and got slightly worse on one.
Treat this as a small test rather than a law. It is four pairs, each built once, and the same prompt built twice with no change at all already varies by up to a fifth. The two most photography heavy sites moved well beyond that noise. The wedding venue sits close to it.
The honest limits of this measurement
These are single page sites, measured once each, on a fast connection, with a cold cache and no throttling. A visitor on a weak mobile connection will see very different LCP numbers, and the 15 percent of sites that already exceed 2.5 seconds here will be considerably worse there.
These figures describe Lovable specifically. The same prompts run through Bolt or v0 produce a different bundle and we have not measured those, so do not read 1.15 MB as a number for AI builders in general.
We also measured each page as built, before anyone swapped the generated images for photographs of a real business. In practice that swap usually makes the page heavier, because real photographs arrive straight off a phone at full resolution. If you take one thing from this, take that: the moment you put your own pictures in, resize them.
Keep reading: how many credits a Lovable website costs · how to prompt Lovable so it works first time · Lovable prompts by industry.
