Why is my Lovable site slow? What we found testing 24 sites

Lovable gets a site live quickly, but that doesn't make it fast. We ran PageBench on 25 sites listed on the Made with Lovable directory, on a mid-range phone over Slow 4G. One run was interrupted on our side, which left 24 results:

This is a small sample and a rough picture. Each site got one test from one location, sites choose to be in that directory, and only 17 of the 24 had a visible Lovable reference in their HTML, so some may have moved on or been built differently. We aren't naming the sites, because the point is the pattern.

Four things stood out, in the order we'd tackle them.

1Check whether your pages are sent as real HTML

According to Lovable's docs, apps created since May 13, 2026 (June 22 on Enterprise) use TanStack Start with server-side rendering. Older React and Vite apps are single-page apps for human visitors: the browser gets an almost empty page, then has to download and run JavaScript before it can show anything.

That split showed up in our results:

To check yours, open your site and view the page source. If the body looks like the example on the right, with no visible text, your page is built by JavaScript. Lovable's docs say existing React and Vite projects can be upgraded to TanStack Start.

<body>
  <main>
    <h1>Your heading</h1>
    <p>Your page's text…</p>
  </main>
</body>

<body>
  <div id="root"></div>
</body>

Two caveats: eight sites is too few to prove the cause, and server rendering isn't free. The pages with content in the HTML had a slower first response, with a median time to first byte of 1.1 s against 444 ms, likely because the server does more work per request. They still showed content sooner overall.

2Shrink your images

Images were flagged on 18 of the 24 sites, because they were much larger than the size they're displayed at, in an older format, or both. On the sites where each issue came up, resizing could save a median of 303 KB, and converting to WebP a median of 415 KB. Those savings overlap, so don't add them together.

This is the biggest single gain on the worst pages. Two sites weighed over 2 MB and took over 10 seconds to show their main content, and the reports estimated that most of that weight could go.

You can do this yourself with our free image optimizer, which runs in your browser and gives you a zip of smaller files. Or paste something like this into Lovable:

Make the images on the home page load faster. Convert them to WebP, and resize each one to at most twice the size it's displayed at. Add width and height attributes. Give the main image at the top fetchpriority="high". Add loading="lazy" to images further down the page. Don't change how the page looks.

3Stop Google Fonts from blocking the page

On 15 of the 24 sites, the browser had to wait for the Google Fonts stylesheet before it could draw anything. That matters here because the largest element on the first screen was text on 19 of the sites, not an image, so visitors are mostly waiting for text to appear.

Self-host the fonts this site uses instead of loading them from Google Fonts. Keep only the weights the site actually uses, preload the main one, and use font-display: swap. Don't change how the text looks.

4Load less JavaScript up front

Long JavaScript tasks were flagged on 20 of the 24 sites, with a median estimated saving of 653 ms. While those tasks run, the page can't respond to taps. A common cause is a first page that loads code only other pages need, so start there.

Reduce the JavaScript the home page loads. Lazy-load routes and any heavy components that aren't on the first screen, such as charts, editors and animations. Remove libraries that aren't used. Tell me what you changed, and don't change how the page looks or behaves.

What you can probably ignore

• Layout shift. Only one of the 24 sites had a problem, so don't start there unless your report says otherwise.
• Cache settings. These were flagged on all 24 sites, but never as high impact, and they don't affect a visitor's first load.

Use your own report, not ours

These are patterns across a sample, and your site may have a different problem. Test your own page, then click Copy for AI to get a prompt with your actual fixes. Paste it into Lovable's chat, shortening it to the top fixes if it's too long.

If you've connected your project to GitHub, you can also use a coding agent on the repository. Lovable says that changes pushed to the active GitHub branch sync back into Lovable. See how to fix your site's speed with Claude Code for the full workflow.