Next.js is slow on shared hosting because most shared plans cannot keep a Node process running. Each cold request restarts the application before any code executes, adding a real but currently unmeasured delay on this site — see the four measurements below to quantify it on your own setup. Shared CPU allocation then throttles rendering further under load.

Key takeaways

  • Cold starts are the usual cause — no persistent Node process means every request pays initialisation cost.
  • Four measurements identify the culprit: isolated TTFB, cold vs warm, static vs rendered, and behaviour under concurrency.
  • TTFB feeds LCP directly. A 500 ms server delay pushes Largest Contentful Paint 500 ms later, whatever the front end does.
  • A faster server does not fix slow code. Unindexed queries and oversized images follow you to the new host.
  • Static export sidesteps the problem entirely if your app can live without server rendering.

The underlying mismatch

Shared hosting was built for PHP, which starts fresh on every request by design and costs a few milliseconds to do so. Next.js expects a long-lived Node process that starts once and serves thousands of requests. Running the second model on infrastructure built for the first is where the delay comes from.

When a shared host advertises Node support, it usually means a process manager that spawns your application on demand and reaps it after a short idle period. For a site with steady traffic that is tolerable. For a site with sporadic traffic — which describes most new sites — a large share of visitors pay the full startup cost.

Cold start
The delay when a request arrives and no warm process is available, forcing the runtime to initialise before application code runs. It is invisible in most benchmarking because repeated requests to the same route keep the process warm — you have to deliberately wait between requests to observe it.

Four measurements that identify the bottleneck

Run these in order. Each one rules something out, and together they distinguish the four common causes.

1. Isolate time to first byte

Browser dev tools blend server time with download and render time. Measure TTFB on its own:

curl -o /dev/null -s -w "ttfb: %{time_starttransfer}s total: %{time_total}s\n" https://example.com/

If TTFB is high but total time is only slightly higher, the server is the problem. If TTFB is low and total is high, your bottleneck is payload size, not hosting.

2. Compare cold against warm

Request a route, wait five minutes without touching the site, then request it again and immediately a third time. Compare the second and third figures.

Interpreting the cold-versus-warm gap on a server-rendered route.
Cold request Warm request Diagnosis Fix
1,200 ms 180 ms Cold starts Persistent process — VPS or managed platform
900 ms 850 ms Sustained slowness Application or database, not hosting
220 ms 190 ms Server is fine Look at payload and front end

3. Static asset versus rendered route

Request a plain file — a CSS bundle or an image — and then a server-rendered page from the same host. A fast static file alongside a slow rendered page places the delay firmly in application execution, not network or bandwidth.

4. Repeat under concurrency

Issue ten simultaneous requests and compare the median against your single-request figure. Shared hosting caps CPU per account, and that cap becomes visible precisely when several visitors arrive together — which is the moment it matters most.

Measure from where your users are. A 40 ms TTFB from a machine in the same city as the datacentre tells you nothing about the visitor in another continent. Test from at least one region representative of your actual audience.

What each result actually means

Symptom-to-cause mapping for slow server-rendered pages.
Symptom Likely cause Does new hosting fix it?
Large cold-warm gap No persistent Node process Yes
Degrades under concurrency Shared CPU throttling Yes
Uniformly slow, warm or cold Slow queries or blocking work in render No
Low TTFB, high total time Oversized payload No
Slow only from distant regions Single-region origin, no CDN Partly — add a CDN

Why this shows up in search performance

Time to first byte is the starting point for Largest Contentful Paint, so a 500 millisecond server delay pushes LCP 500 milliseconds later no matter how well images and scripts are optimised. Google also reduces crawl rate against consistently slow origins, which slows how quickly new content gets indexed.

This is the practical link between infrastructure and rankings, and it is why front-end optimisation alone plateaus. You can compress every image and defer every script, and a slow origin still sets a floor under your metrics that no amount of front-end work penetrates.

What to actually do

  1. If cold starts are the cause: move to anything with a persistent process — a small VPS or a managed platform both solve it.
  2. If CPU throttling is the cause: a VPS with guaranteed vCPU. Shared plans cannot be tuned out of this.
  3. If it is uniformly slow: profile the render path. Unindexed queries and per-request API calls are the usual offenders, and both follow you to a new host.
  4. If only distant regions are slow: put a CDN in front. Cheaper and more effective than relocating the origin.
  5. If you do not need server rendering: export statically and host on a CDN. The problem disappears and the bill goes to roughly zero.
Confirmed hosting is the bottleneck? The zero-downtime migration guide covers the move, and the cost calculator will tell you what the new tier costs before you commit.

Badri Dutta

Software engineer · 15 years building for the web

Fifteen years building for the web and eight doing technical SEO, now working with Java, Python and AWS in production. The diagnostic sequence here exists because “upgrade your hosting” is expensive advice to follow when the real problem was a missing database index.

Full background →