heaven.helloimabid.com

Next.js what actually works on this platform

Most of what makes a Next.js site slow is decided at build time — which routes are static, what ends up in the client bundle, and where the server boundary sits. These are the levers, in the order worth pulling them.

• No Next.js cache header on this response, so either the HTML is rendered per request or it is served by something in front that strips the header — worth confirming before you tune anything.
• Time to first byte measured 181ms on this run — one sample, so re-run it a few times before treating it as the number.

1. Decide the rendering mode per route, not per app. Next.js will statically generate, revalidate on a schedule (ISR) or render per request, and the choice is made route by route. A public marketing or content page rendered per request pays a server round trip on every visit for output that could have been reused. Start with the routes that get the most traffic and the least personalisation.
2. Read the cache header before changing anything. x-nextjs-cache (or x-vercel-cache) reports HIT, STALE, MISS, BYPASS or PRERENDER for the HTML. MISS or BYPASS on a page with no per-visitor content is the clearest signal you have something to gain; a HIT means the render is already free and your time is better spent on the client bundle.
3. Check First Load JS per route. next build prints it. That number, not TTFB, is what a visitor waits through before the page becomes interactive. A shared component pulled into the root layout is charged to every route, so look for one heavy import inflating the whole app rather than a single slow page.
4. Keep server-only work behind the server boundary. A dependency imported in a Client Component ships to the browser. Date libraries, SDKs and icon sets pulled across a "use client" boundary are a common way an otherwise small app grows a large bundle — audit what crosses it.
5. Use next/image and next/font rather than raw tags. next/image serves modern formats at the right size and reserves space so the layout does not shift; next/font self-hosts the font files and removes the render-blocking request to a font host. Both are small changes with visible effects on Core Web Vitals.
6. Load third-party scripts through next/script. Analytics, chat widgets and tag managers loaded as plain script tags block the main thread during hydration. next/script with an afterInteractive or lazyOnload strategy moves them out of the critical path without removing them.

The full instruction set, and a machine-readable copy of this report, live at heaven.helloimabid.com.md — paste that URL into your AI builder's chat and it can work straight from these measurements.