A site that used to load fine now feels sluggish. The first screen takes a few seconds, and clicks are slow to respond.

"Suddenly" means something changed recently — usually a big image was added, data piled up, a free-tier project went to sleep, or a third-party script got bolted on. Below is a cause-by-cause checklist.

> There is no single magic fix. The reason varies from site to site. This guide helps you narrow down the culprit. Measure first (Step 0), then fix only the matching cause.

Step 0. Diagnose in 30 seconds — find where it's slow

Measure before you guess.

  1. Go to https://pagespeed.web.dev/, paste your site URL, click Analyze.
  2. Look at LCP (Largest Contentful Paint): 2.5s or less is good, over 4.0s is poor (web.dev thresholds).
  3. The Opportunities / Diagnostics list names concrete issues — "properly size images", "reduce unused JavaScript". Those are your suspects.

Have Chrome? F12 → Lighthouse tab → Analyze page load gives the same report. No install needed.

Cause 1. Images are too big (most common)

Upload a 4MB phone photo as-is and that single image drags the whole page down. If Step 0 flagged images, start here.

On a Next.js site, simply swapping <img> for next/image's Image auto-optimizes the size, quality, and format (WebP/AVIF). Off-screen images lazy-load by default, and adding width/height reserves space so the layout doesn't jump.

jsx

import Image from 'next/image'

<Image src="/hero.png" width={1200} height={630} alt="Hero image" priority />
  • Add priority to just the one hero image at the top so it loads first (renamed to preload in Next.js 16).
  • Every other image lazy-loads automatically with no extra options.

Using an AI coding tool (Cursor, Lovable, v0)? Tell it: "Replace every <img> tag with the next/image Image component, and add priority only to the top hero image."

Not on Next.js? Same principle: compress images (e.g. squoosh.app) and convert to WebP before uploading.

Cause 2. Data piled up and the DB scans the whole table

If it was fast at first but got slow as posts/users/orders grew into the thousands, the likely culprit is queries with no index. Without an index, the database reads the table top to bottom on every request (a full scan).

Fix on Supabase (Postgres):

  1. Supabase dashboard → Advisors → Query Performance (or Reports → Query Performance) to see slow queries and the columns they filter on.
  2. Add an index on the columns you frequently filter or sort by. In the SQL Editor:
sql

create index idx_posts_user_id on posts (user_id);
  1. If the table is already large in production, add concurrently so it doesn't lock the table for writes:
sql

create index concurrently idx_posts_created_at on posts (created_at);

Supabase also has an Index Advisor that recommends which indexes to add (Query Performance → pick a query → Indexes tab). Read the suggestion, then run the SQL above yourself.

Cause 3. A free-tier project fell asleep (only the first request is slow)

"Only the first load after a while is slow, then it's fine" → that's a sleep / cold-start signal.

  • The Supabase Free plan can pause a project after ~7 days of low activity. Once paused, the first request that wakes it is slow or fails; Restore the project from the dashboard to bring it back.
  • Serverless functions (Vercel, etc.) also cold-start slowly when they haven't been called for a while.

What to do: for a low-traffic service, hit it periodically to keep it awake, or move to a paid plan for always-on if you have real traffic. Knowing that "occasional slow first request" is normal free-tier sleep — not a bug — saves you from chasing ghosts.

Cause 4. A heavy script or third-party widget blocks rendering

If you recently added a chat widget, ads, analytics, web fonts, or a YouTube embed, it may be blocking your first paint. web.dev notes that synchronous scripts and render-blocking CSS in <head> delay rendering.

  • Defer non-essential external scripts with async/defer, or load them at the bottom of the page.
  • The scripts under PageSpeed's "Reduce the impact of third-party code" are prime suspects. Remove them one at a time to find the offender.

Still stuck?

  • Paste the top 3 findings from your Step 0 PageSpeed report straight into your AI coding tool and ask it to fix them. Lighthouse findings are specific enough to act as ready-made instructions.
  • Recall when it got slow and what you changed then — reverting the recent deploy/commit is often the fastest path.

Again: this is a checklist to narrow the culprit, not a one-line fix. Work it in order — measure (Step 0), then apply only the matching cause.