Bolt app slow: is it the preview, the published site or the database?

"Slow" in Bolt can mean four different things: Bolt's chat taking ages to respond, the preview lagging, the published site loading slowly, or one screen hanging while it fetches data. They have different causes, and the fix for one does nothing for the others. So the first job is to work out which one you have.

Symptom

• Bolt's responses get slower and less accurate as the project grows.
• The preview takes a long time to start, freezes, or crashes the tab.
• The first load after a few days away hangs on a database restore.
• The published site is slow on phones, especially pages with images.
• One dashboard or list page takes seconds to show data while the rest is fine.
• Publishing fails because the project is too big:

Why it happens

The preview runs on your machine. Bolt is built on WebContainers, StackBlitz's runtime for Node.js inside a browser tab. Bolt's docs say WebContainers rely on your device's resources, so limited memory can make the preview fail or crash, which Bolt calls an out of memory (OOM) error. The preview also runs a development server. Vite's own docs explain that unbundled code is fine for development but inefficient in production, which is why production builds are bundled. Safari is different again: Bolt builds a hosted preview there, which refreshes after each change deploys.

Unpublished databases pause. After six or more days of low use, Bolt may pause the database of an unpublished project. The first request after that waits for a restore.

Media lives in the project. Bolt's docs say projects usually hit the 100MB limit because of large images or videos stored directly in Bolt. Even under the limit, heavy images are the most common reason a page is slow on mobile data.

Policies and queries scan whole tables. Bolt Database runs row level security on every request. Supabase's docs say an unindexed column in a policy turns reads into a full scan, and that wrapping auth.uid() in a select lets Postgres cache it instead of re-running it per row.

The chat context is full. Bolt's docs say that when context gets too large you may see errors, slower responses or lower-quality results. Large files fill it fastest.

The fix

1. Measure the published site, not the preview

Publish, then open the live URL in a private window with DevTools open on the Network tab. Reload with the cache disabled. Note the slowest requests: images, JavaScript files, or calls to your database. On a paid plan, Analytics in project settings also shows bandwidth use and top pages.

2. Shrink and move images

Bolt's docs suggest storage outside the project (Supabase Storage, Cloudflare R2, Cloudinary and others), then prompting Bolt to use the new URL. For images that stay, set dimensions and lazy-load anything below the fold:

<img
  src="https://cdn.example.com/hero-1200.webp"
  srcSet="https://cdn.example.com/hero-800.webp 800w, https://cdn.example.com/hero-1200.webp 1200w"
  sizes="(max-width: 768px) 100vw, 1200px"
  width={1200}
  height={630}
  alt="Market stalls at a weekend pop-up"
  loading="lazy"
  decoding="async"
/>

Use loading="lazy" only for images below the fold. The first image people see should load straight away.

3. Find slow queries

Open the database icon, then Logs, and choose PostgreSQL right after reproducing the slow page, because the page only keeps the past hour. Then open the table in Tables, click Query, and check the plan for the query the page runs:

explain analyze
select id, title, created_at
from public.orders
where user_id = '00000000-0000-0000-0000-000000000000'
order by created_at desc
limit 20;

If the plan shows a sequential scan on a large table, add an index on the columns you filter and sort by, and tidy the policy:

create index if not exists orders_user_id_created_at_idx
  on public.orders (user_id, created_at desc);
 
-- In the policy, wrap auth.uid() so it is evaluated once per query
-- using ((select auth.uid()) = user_id)

Ask Bolt to apply schema and policy changes so they're recorded in the project.

4. Fetch less, and fetch in parallel

If a page loads everything, one request after another, it waits on each in turn. Ask only for the columns and rows the screen needs, and start independent requests together:

const [orders, profile] = await Promise.all([
  supabase
    .from("orders")
    .select("id, title, status, created_at")
    .order("created_at", { ascending: false })
    .range(0, 19),
  supabase.from("profiles").select("display_name, plan").single(),
]);

5. Split the bundle by route

If the JavaScript download is large, load heavy screens only when someone opens them:

import { lazy, Suspense } from "react";
 
const Reports = lazy(() => import("./pages/Reports"));
 
export function ReportsRoute() {
  return (
    <Suspense fallback={<p>Loading reports...</p>}>
      <Reports />
    </Suspense>
  );
}

6. Speed up the editor and preview

• In the chat, enter /clear and pick Clear context when you finish a feature.
• Ask Bolt to list files over about 700 lines, then split them one at a time.
• Resize images stored in the project so the longest side is no more than 1,500 pixels, which Bolt's docs call a safe threshold.
• For OOM errors, close other tabs and other Bolt or StackBlitz projects, refresh, and try a browser with fewer extensions.
• Publish projects you rely on, so their databases stay awake.

How to prevent it

• Keep media out of the project from day one.
• Ask Bolt for pagination on every list that can grow.
• After each new table, ask for an index on its owner column and check the policies.
• Test the published site on a mid-range phone over mobile data before each launch.

When to get help

If the slowness comes from how the data is modelled, such as one table doing the job of five, indexes only go so far. Why AI-built apps are slow covers the general causes, and Bolt database issues covers the database side in more depth. The fix guide for vibe-coded apps puts performance in context with the other usual failures, and taking a Bolt app to production has the full launch checklist.

Run the free vibe-code health check for a first read. If it needs hands-on work, a Rescue Sprint is an audit plus fixes at a fixed price agreed after a technical assessment (from £750), usually in about a week.