Lovable.app and the AI-Website Hype: What I Learned Rebuilding Off It

I built my first TruLight SLC website on Lovable.app, an AI-website builder. You describe what you want in a chat box and a few minutes later you have a working site, deployed and live. I was hooked. The thing looked clean and I'd shipped a real domain in an afternoon. The trouble showed up later, when I started running the site through real-world mobile speed tests instead of just my office Wi-Fi. The page that felt instant on my MacBook was taking six or seven seconds to load on a typical four-year-old phone on cellular. The same content. The same domain. The same site I'd just shipped. Failing in the field.

That gap is what kicked off the rebuild. Not a Core Web Vitals report. Not a Google ranking drop. The actual difference between how the site felt to me and how it was performing for the people I needed to reach. This post is the long version of what happened next, what I actually learned about AI website builders, and what I'd tell any home-services owner looking at the wave of AI-builder marketing and wondering if the answer is sitting in a chat prompt.

What is Lovable.app, actually?

Lovable.app is an AI-native website builder. You give it a prompt in plain English, it generates a working site, and it deploys it for you on a subdomain like yourbusiness.lovable.app. It uses React (a JavaScript framework), Vite (a development build tool), and Tailwind (a styling framework) under the hood, and it can wire your forms and data to Supabase, a hosted database service, for things like contact forms or login.

The output is a single-page application. SPA, for short. That's a website where the visitor's browser downloads a JavaScript bundle on first visit and then "hydrates" the page: runs that JavaScript to draw the layout, fetch the content, and wire up every button. The cost is that every first visit pays the full bundle download, and the phone does the rendering work a traditional server would have done before shipping the page.

Lovable is genuinely good at what it's good at. The chat-driven workflow is fast. The default design beats most stock templates. According to the Lovable documentation, it ships React + Vite + TypeScript with shadcn/ui components and connects to Supabase for the data layer. It's a real product, built well, and one of the most popular AI website builders on the market in 2026.

What's actually wrong with AI-built websites?

The architecture is the problem, not the AI. AI builders like Lovable, Bolt, V0, and the various chat-driven Wix and Squarespace AI features all ship the same SPA pattern. That works for a software dashboard. It hurts a marketing site that has to load fast on cellular for someone who hasn't decided whether to call you.

Here's what that meant on my Lovable site, captured the day I cut over:

• Total page weight on the homepage: 35.3 MB across 220 requests on every first visit. That's not a typo. Thirty-five megabytes shipped to a phone on cellular before the visitor saw a button.
• Time to first byte: 585 ms. That's how long the visitor's phone sat there waiting after asking for the page before any data started coming back.
• Largest contentful paint: 1.92 seconds on a desktop with a fast connection. Considerably worse on a phone in the field.
• Indexed page count: 8 total pages. The site couldn't grow into the long tail of "permanent lighting Cottonwood Heights" or "permanent lighting Sandy" because adding pages on Lovable means adding to the same SPA bundle, which makes the bundle even heavier.

The site looked fine. That's the trap. On office Wi-Fi on a fast Mac, the page felt instant. On a real-world phone over cellular, the page weight and the SPA hydration combined into a six-second wait, with a chat widget sitting on top of the call-to-action button by the time anything settled.

To be fair, the page weight isn't entirely Lovable's fault. I uploaded big hero images, bolted on a chat widget, and left demo components I never trimmed. A more careful Lovable build would have shipped less. But the floor is the framework itself: the React bundle, the Vite runtime, the hydration step. Even with surgical trimming, a Lovable site is structurally a single-page app on a generic CDN. That's a ceiling you can't config your way around.

Why did the same content get so much faster on a different stack?

Because the stack does the work the browser used to do. When I rebuilt TruLight SLC on Next.js 15 (a React-based framework that pre-renders pages at build time) and deployed it to Vercel's edge network (Vercel runs 126 points of presence across 51 countries, per their CDN documentation), the visitor's phone stopped doing the rendering. The HTML was already finished, sitting on a server in their region, and shipped down the wire as plain text.

The numbers, three cold runs each, same machine, same Playwright setup on both sites:

Metric	Old (Lovable.app)	New (Next.js + Vercel)	Change
Total load time	4,155 ms	745 ms	5.6x faster
Time to first byte	585 ms	37 ms	15.8x faster
First contentful paint	1,920 ms	313 ms	6.1x faster
Largest contentful paint	1,920 ms	391 ms	4.9x faster
Page weight	35.3 MB	10.0 MB	3.5x lighter
Indexed pages	8	67	8.4x more

The full breakdown lives at our TruLight SLC case study, with side-by-side screenshots of the old hero (a dark-navy template wall with a stacked headline) and the new hero (a real photograph of an installed permanent-lighting job on a Salt Lake City home at night). Same phone number. Same offers. Same domain. Same content, written from the same brief. The only thing that changed was the substrate underneath.

The 15.8x time-to-first-byte improvement is the cleanest story. On Lovable, the request had to wake up a hosted runtime to generate the page. On Vercel's edge, the request hits a server in the visitor's metro that already holds a finished copy of the HTML. Vercel's own benchmarks put edge-side rendering at 20 to 50 ms TTFB, and the TruLight rebuild landed at 37 ms. That's the entire gap between "feels instant" and "feels modern but slow."

Why the AI-builder hype is louder than the architecture

This is the part that took me longest to see clearly. AI website builders are in a hype cycle. Every week there's a new one: Lovable, Bolt, V0, Mocha, Framer's AI builder, Wix's AI mode, the Squarespace AI redesign tool. The marketing is unified: "build a real site from a prompt." The implication is that the AI is the meaningful part.

It isn't. The AI is generating code on top of a stack that was already chosen for you. Lovable picked React + Vite + Tailwind + Supabase before you opened the chat box. Bolt scaffolds the same shape of app in a browser sandbox. V0 outputs React components on top of shadcn/ui. The AI varies, the output substrate is roughly identical: a single-page app, hydrated client-side, served from a generic CDN.

None of those builders ship statically pre-rendered HTML on an edge network. None give you the 30 to 50 ms TTFB the modern Jamstack delivers. None produce the SEO footprint a properly templated Next.js site does, where every service area page is its own real URL with its own meta description and schema markup. The marketing focuses on speed of creation. The cost is speed of delivery, which is what your customer actually experiences.

I'm not saying the AI builders are scams. I used one. It got me to a live site faster than I could have alone. The point is that "AI-built" is a feature of the authoring tool, not of the website. The site itself is judged by Google, by your customer's iPhone, and by your competitors' faster sites. Those judges don't care how the code got written. They care what got shipped.

When is an AI website builder actually the right choice?

Use an AI builder when you need to ship a working prototype fast and the audience is forgiving. Pitch decks, internal tools, founder demos, MVP landing pages for a product that doesn't exist yet, course or coaching pages where the visitor already trusts you. The SPA architecture is fine when the visitor is already committed and the conversion isn't gated by speed.

Don't use one for the production website that holds your phone-ringing local-services business. The cost shows up in three places. First, mobile speed: home-services traffic runs 65% to 80% mobile, often on cellular, often on older phones, and an AI-builder SPA routinely takes three to six seconds to settle in those conditions. Second, SEO surface area: the long-tail "service in city" pages that drive local rankings are hard to add to an SPA without bloating the bundle, which is why my Lovable site sat at 8 pages while the rebuild grew to 67 with no added load time. Third, owner control: you don't really own the site, you own a project file in someone else's hosted runtime, and your migration cost goes up the longer you wait.

The honest framing: an AI builder is a great way to discover what you want your site to be. It's a poor place for that site to live once you know.

What the rebuild actually taught me

Speed is a function of architecture, not template choice. I spent weeks trying to optimize the Lovable site. Compressed images, removed widgets, deferred scripts, shaved a few hundred milliseconds, felt good for an afternoon. The rebuild got me 5.6x faster the same week with no further optimization, because the new stack starts from a different floor. The framework runtime alone on the old site was heavier than the entire homepage on the new one.

The visitor sees the substrate, not the AI. My customers don't know what Lovable is, what Next.js is, what Vercel's edge is. They know whether the page settled before they got bored. The technical layer is invisible until it fails, and when it fails it fails on the people you spent money to get to the page in the first place.

The same content on a different stack becomes a different website. The TruLight SLC case study screenshots are the most surprising part. The old and new sites share roughly 80% of the copy. Same offers, same phone, same financing, same warranty. The new site looks like a different brand. Not because we redesigned every section, but because real install photographs replaced template hero panels, and because the page now arrives whole on a phone instead of trickling in.

The rebuild also moved indexed page count from 8 to 67 without changing the load profile, because every new page is just another piece of pre-rendered HTML on the same edge cache. That matters more than any single load-time number for a local-services business. Every long-tail city-by-service URL is real on the new site. On the old site they didn't exist, and couldn't, without making the bundle worse for everyone.

How to know if your AI-built site has the same problem

Run your home-page URL through Google's free PageSpeed Insights on the mobile tab. The two numbers that tell the story:

• Mobile LCP. If it's over 2.5 seconds you're failing Google's "good" threshold and your competitors who pass it are getting a quiet boost in mobile-first ranking, which is the dominant ranking mode now.
• Total page size. Open Chrome DevTools, go to the Network tab, reload the page on a throttled "Slow 4G" profile, and watch the bottom-right number. Anything over 3 MB on a small-business site is a structural problem, not an asset problem.

If you're failing both, the floor is the platform. You can spend a month optimizing or you can spend a week rebuilding on a stack that starts from a passing grade. Most owners I talk to have already done the optimization round. The rebuild is what they were avoiding.

Frequently asked questions

Is Lovable.app bad?

No. Lovable is a well-built AI builder for prototyping, founder demos, and internal tools. It ships a single-page React app on a generic CDN, which works fine for low-traffic, high-trust audiences. It struggles with the mobile speed and SEO surface area requirements of a local-services marketing site, and that's the use case where Front Door Digital sees the rebuild value most often.

Will switching to a different AI builder fix the speed problem?

Usually no. Lovable, Bolt, V0, Framer AI, Wix AI, and Squarespace AI all ship variations of the same client-side hydration pattern. The architectural ceiling is similar across the category. A real step-change in mobile speed comes from moving off the AI-builder category onto a statically pre-rendered stack: Next.js, Astro, or Remix in static mode, hosted on Vercel, Netlify, or Cloudflare Pages.

Can I export my Lovable site and rebuild it elsewhere?

Yes. Lovable exports the React + Vite + Tailwind code and you can take it with you. The catch is that exporting the SPA isn't the same as having a fast site, because the architecture comes with the export. A real rebuild means re-templating the content into a statically rendered framework, not just changing where the same SPA gets hosted. We did the latter for TruLight: the content survived, the architecture was replaced.

How long does a rebuild take and what does it cost?

For a typical local-services site, two to four weeks from kickoff to launch, depending on how many service area pages need to ship and how clean the existing content is. The architectural rebuild itself is the deterministic part: same stack, same edge deployment, same templating pattern across every Front Door client. Pricing lives on the pricing page.

If you've gotten this far you probably already know which side of the rebuild question your own site is on. The cheapest test you can run: pull up your homepage on a four-year-old phone on cellular, with one bar of signal, and watch the spinner. That's the test I missed running on Lovable until it was costing me leads. It's also where most of the rebuilds we ship at Front Door Digital end up starting.