Cold Start Issue in NextJS application

[vjjcn]

Before opening, please confirm:

• [x] I have checked to see if my question is addressed in the FAQ.
• [x] I have searched for duplicate or closed issues.
• [x] I have removed any sensitive information from my code snippets and submission.

Amplify Hosting feature

Deployments, Frontend builds

Is your feature request related to a problem? Please describe:

Hello Community,

Lot of users in amplify are facing the issue in which the website takes more than 3-4 seconds to load because of the cold start, It makes UI experience of the application bad, some users might drop of the website because of the cold start.

Describe how you'd like this feature to work

I request you to improve the coldstart of the website which typically takes 3-4 seconds and make the UI experience of the Amplify better.

[github-actions[bot]]

This has been identified as a feature request. If this feature is important to you, we strongly encourage you to give a 👍 reaction on the request. This helps us prioritize new features most important to you. Thank you!

[mauerbac]

Can you provide more info about your app? Like versions and provide a screencapture?

[kachkaev]

Same issue here. Cold start takes more than five seconds. To me as a user, it feels forever. Just tried opening our team’s app on Monday morning and it took 7.08 seconds. It’s a B2B SaaS with low traffic so the probability of hitting cold instance is quite high.

Our stack:

• Amplify Gen 1
• Node 20 (latest available - see https://github.com/aws-amplify/amplify-hosting/issues/3978)
• Next.js 15.1 (latest) with pages router
• _app.js essentially contains only <Autenticator> (from @aws-amplify/[email protected]), the rest is client-rendered

I was thinking of running a cron job in CI that would fetch from Amplify once in 5-10 minutes. This might keep the app warm during business hours to avoid cold starts. But this is a pretty hacky solution to something that should work out of the box anyway. Not sure if constant artificial pre-warming would affect our bill. I hope to see some official guidance in Amplify docs.

---

UPD: tried opening a client-facing instance of our Amplify app (deployed from a different branch to a different domain). It took 14.84 seconds to make a cold request to /. Total time to login screen was over 16 seconds!

When refreshed (even without browser cache), loading is quite fast. Getting to the same <Autenticator> screen in under a second when Amplify is warm. I am in the same region, so makes sense. The initial request to / was only 137ms (100+ times faster than the cold one!).

I can reliably reproduce the above delay if nobody is visiting the website for more than 5-10 mins. It’s not a one-off thing.

[eaoliver]

This is the same issue as #3915 , which is marked as closed.

[mauerbac]

Yeah, that's fair. I just re-opened. The team is very aware of cold starts and was mostly using this issue as a means to track. I'll keep status updates here

[leonardoas10]

I have the same issue with my Gen 1 app, so im trying to find the new enhance in Gen 2 related to cold starts.

I use AWS Q Cli looking for some insights...

Cold Start Time Improvements in Amplify Gen 2

Specific Cold Start Metrics

• Gen 1: Typical cold start times ranged from 5-10+ seconds, sometimes reaching 15+ seconds for complex applications • Gen 2: Cold start times reduced to approximately 1-3 seconds (a 60-80% improvement)

Technical Reasons for Improved Cold Starts

1. Optimized Lambda Initialization • Gen 2 uses a specialized bootstrapping process that prioritizes the Next.js runtime initialization • Implements parallel initialization of critical components

2. Memory Management • More efficient memory allocation during function startup • Smarter garbage collection strategies to prevent unnecessary pauses

3. Dependency Loading • Gen 2 implements lazy loading of non-critical dependencies • Uses dependency bundling optimizations specific to Next.js requirements

4. Function Provisioning • Implements predictive scaling to keep functions warm based on traffic patterns • Uses provisioned concurrency more effectively for high-traffic routes

5. Runtime Optimizations • Specialized Node.js runtime configurations for faster startup • Optimized handler code that reduces initialization overhead

6. Caching Strategies • Improved caching of rendered components between invocations • Better persistence of compilation artifacts

7. Infrastructure Improvements • Enhanced VPC connection handling (if using VPC-connected functions) • Reduced latency in the request handling pipeline

P.S. I haven’t tested it yet.

[cheruvian]

Rather than us needing to build our own warmers can Amplify just expose the lambda config so we can provide a ProvisionedConcurrency configuration. It would be more $$ in AWS pocket at the end of the day and help us reduce the cold start penalty.

[mikefrancis]

Having just moved an app to Amplify to simplify billing, we're about to move back over to Vercel for modern versions of Node and faster cold starts. It's worth the money in our eyes, we'd love it if Amplify was at least in the same arena when it came to performance.

[kachkaev]

@mxkxf are you on Amplify Gen 1 or Gen 2? I have a small hope that upgrading could help, but if you are on Gen 2 already, that’s pretty disappointing.

Lack of comms from the Amplify team for such a critical UX problem is confusing. It feels that we are using an abandoned product and should move on.

[gvsakhil]

Its still the same behaviour now. I am planning to implement a health check using Route 53 and keep it warm all the time. This increases the cost but need it for faster page load in production. Hope AWS gives a solution soon for this.

[rhamnett]

Rather than us needing to build our own warmers can Amplify just expose the lambda config so we can provide a ProvisionedConcurrency configuration. It would be more $$ in AWS pocket at the end of the day and help us reduce the cold start penalty.

This is literally the simple solution

[startydev]

Hello, chiming in as I'm facing what appears to be the same issue. In my case, it's causing my Next.js application on AWS Amplify to crash with a server timeout.

The Problem

My users report that the application fails to load and they are met with a blank screen. After the report when I go to the web, this works. Then they check and now works. I could reproduce this after periods of inactivity so I realized it might be a cold-start issue.

Evidence

I've correlated these user reports with timeout errors in my logs. The key details from a sample log are the 30-second duration and the Status: timeout:

REPORT RequestId: d0f5195c-79a4-430a-9c05-XXXXXXXXXXXX Duration: 30000.00 ms Billed Duration: 31192 ms Memory Size: 1024 MB Max Memory Used: 153 MB Init Duration: 1191.38 ms Status: timeout

Investigation & Context

I have already investigated my application's performance and confirmed the following:

• Our external API calls are fast and optimized and this is not a stopper to render or block the page.
• The Next.js application code is designed to serve the initial page in under a second.
• Local performance is excellent, with no indication of such delays.

This leads me to believe the issue is not with the application logic itself, but with the hosting environment.

My Setup

• Next.js Version: 15.5.4
• Hosting: AWS Amplify.
  • Important: We are using Amplify for hosting only. No other Amplify services (like Auth, Functions, DataStore, etc.) are being used.
  • The app runs in SSR mode (no output: 'export' in next.config.js).
• API: Strapi hosted on Strapi Cloud with the free tier (any request is a blocker to render the init load).
• Amplify Config (amplify.yml):

version: 1
frontend:
  phases:
    preBuild:
      commands:
        - rm -rf .next
        - npm install -g pnpm
        - pnpm install
    build:
      commands:
        - pnpm run build
  artifacts:
    baseDirectory: .next
    files:
      - '**/*'
  cache:
    paths:
      - .next/cache/**/*
      - .npm/**/*
      - node_modules/**/*

Questions

Given that this only happens after inactivity, this strongly suggests a cold start issue on the Amplify/Lambda backend.

1. Could this behavior be directly related to cold starts?
2. Is there any specific configuration within Next.js or Amplify that I might be missing to mitigate these long cold start times for a server-rendered application?

Any help or pointers would be greatly appreciated. Thanks.