Very slow build time to a NextJS app with only 2 pages with SSR

[willianjusten]

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 read the guide for submitting bug reports.
• [X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.

App Id

d1ywuiyssz1l16

Region

us-east-2

Amplify Console feature

Build settings, Performance

Describe the bug

If you can see in the following image:

My builds are taking almost 10 minutes, but it's a very small project (NextJS with 2 static pages for now). I even removed testing stuff to run inside my CI/CD on Gitlab to save some time, but it still too slow... =/

Another thing that I noticed is that initially Amplify identified my project as Web Cypress even when I defined nextjs stuff.

---

If you could take a look, maybe it's just a misconfiguration, but it looks really weird.

Expected behavior

It shouldn't take more than 2-3min, follow bellow the same project on Netlify and it's very similar in Vercel as well.

Reproduction steps

1. Init the project with amplify init and answer the questions (remember it's next ssr project, so the build folder is .next)
2. Add hosting with amplify add hosting
3. Connect with Gitlab
4. Wait and see the build

Build Settings

version: 1
frontend:
  phases:
    preBuild:
      commands:
        - yarn
    build:
      commands:
        - yarn build
  artifacts:
    baseDirectory: .next
    files:
      - '**/*'
  cache:
    paths:
      - node_modules/**/*

Additional information

No response

[quinnturner]

The long build time is related to this application being an SSR application (instead of SSG). SSR applications currently take several minutes longer (my estimate is ~6-10 minutes) than SSG applications.

This long deployment time issue is likely not readily resolvable on Amplify's end. Vercel has a fundamentally different architecture for CDNs/Compute@Edge under the hood than AWS Amplify. Vercel uses Fastly (which is essentially Varnish-as-a-Service), whereas AWS uses CloudFront. Unlike Fastly, CloudFront does not support instant invalidations and propagations in CDNs & deployments of Compute@Edge. As a result, Amplify is bottlenecked by CloudFront.

I suggest updating the title of this post to include SSR since this is only related to SSR apps.

[willianjusten]

Oh, that's sad =\

Both Vercel and Netlify takes only 2min at maximum...

[medelman17]

Just wanted to comment that this remains an outstanding issue--have been dealing with excessively long build times just today.

At the very least, can the team provide any clarity with respect to what exactly is going on during the five+ minutes between: (1) SSR build Starting; and (2) SSR complete?

[quinnturner]

From @ferdingler on #2272:

The reason for deployment times taking several minutes (~6 to 13 minutes) is because of the propagation time of the CloudFront distribution across all edge locations globally. The deployment itself (updating the code and creating resources) is actually pretty fast, but the rest of the time is just waiting for propagation to finish.

We are aware that customers like faster deploy times and we are looking into ways to improve this. Thanks again!

[reedshea]

I'm experiencing a similar issue, I think - but it seems that although my application is purely a static site (SSG), Amplify still builds a server-side rendered version. The back-end CloudFormation work is pretty quick (3 minutes), and the front-end SSG build looks like it takes just a few seconds for this site. But the subsequent SSR build takes 7 minutes:

2021-11-28T21:19:06.524Z [INFO]: info  - Compiled successfully
2021-11-28T21:19:06.526Z [INFO]: info  - Collecting page data...
2021-11-28T21:19:08.270Z [INFO]: info  - Generating static pages (0/9)
2021-11-28T21:19:09.928Z [INFO]: info  - Generating static pages (2/9)
2021-11-28T21:19:09.936Z [INFO]: info  - Generating static pages (4/9)
2021-11-28T21:19:09.971Z [INFO]: info  - Generating static pages (6/9)
2021-11-28T21:19:10.093Z [INFO]: info  - Generating static pages (9/9)
2021-11-28T21:19:10.093Z [INFO]: info  - Finalizing page optimization...
2021-11-28T21:19:10.097Z [INFO]: 
[...]
2021-11-28T21:19:10.106Z [INFO]: λ  (Server)  server-side renders at runtime (uses getInitialProps or getServerSideProps)
                                 ○  (Static)  automatically rendered as static HTML (uses no initial props)
                                 ●  (SSG)     automatically generated as static HTML + JSON (uses getStaticProps)
                                 (ISR)     incremental static regeneration (uses revalidate in getStaticProps)
2021-11-28T21:19:10.292Z [INFO]: Starting SSR Build...
2021-11-28T21:26:15.502Z [INFO]: SSR Build Complete.
2021-11-28T21:26:16.796Z [INFO]: # Completed phase: build
2021-11-28T21:26:16.821Z [INFO]: ## Build completed successfully

[quinnturner]

@reedshea make sure your build script in package.json is:

{
  "scripts": {
    "build": "next build && next export"
  }
}

The behaviour you're describing happens when the build script is just next build. When Amplify sees next export, if will forcibly only deploy the static assets and none of the Lambdas.

I suggest to create a fresh new Amplify application for this SSG-only deployment. Historically, the transitions between SSR<->SSG on Amplify within the same application results in hard-to-debug issues.

[reedshea]

Thank you, @quinnturner! I'll investigate and see whether that approach makes sense. There may be a need for SSR pages in my application, so I'll tread carefully and try to avoid running into hard-to-debug problems...

[nickmcmillan]

Same situation here. Small (10-ish SSR pages) NextJS site. No idea what's happening during these ~8 minutes.

2021-12-03T04:05:18.299Z [INFO]: Starting SSR Build...
2021-12-03T04:13:09.007Z [INFO]: SSR Build Complete.

[manelephant]

I don't understand how a small company like Vercel can implement a smooth deployment of a nextjs app in any version and amazon can't.

Wasted a full day on amplify trying to deploy nextjs 11 without success. Cryptic or false error reporting during build.

[llogan382]

@quinnturner that recommendation worked great. Below, build 7 is just using next build build 8 is using next build && next export. These results are substantial:

[nickmcmillan]

I think that's fine if all that's needed is a static site - which is what next export generates. But if we want a site with any SSR pages - ie those that run on Next's nodejs environment - then we have to go through Amplify's very slow SSR build step.

[jayfry1077]

My site with 5 small pages and 1 hello world api took 17 minutes to build.

[entest-hai]

No excuse CloudFront, it should be much faster

[ivancsicsmarkus]

Many applications need SSR with faster build times. Our build times are around 12 minutes. More than 60% of that is "Starting SSR Build...". We understand that Cloudfront and Lambda@Edge need some time to update but it could be faster for such tasks where only a small number of assets and functions have to be updated.

[yauri-io]

I'm having the same issue. I'm looking for a different provider for hosting my NextJS project (SSR). The build time on Amplify is too long, and I experienced 2 times stuck on build process, I just cancelled it.

[justyn-clark]

Same here and I'm ready to throw my laptop out of the window!!!

I'm testing an issue only happening in Amplify and it takes 15mins each time for only a few pages.

This is very painful.

[matart15]

1. created a new nextjs app.
2. just in case deleted pages/api. only 2 pages. index.js and 404
3. next build. Not next build && next export because we will use both SSG and SSR in the future.

local	amplify on aws
time yarn build	phase.build.commands
10.41s	12 minutes 39 seconds

[PixellUp]

A very simple Next JS website took a whooping 40 min to deploy. This is unacceptable!!!

Before

[justyn-clark]

A very simple Next JS website took a whooping 40 min to deploy. This is unacceptable!!!

Before

Dude I'm done with this setup and possibly Next JS and Gatsby altogether after this.

Do yourself a favor like I did and join the Remix.run team and deploy on Fly.io. It will change your life.

[nickmcmillan]

justyn-clark The problem this thread is discussing relates to Amplify's slow SSR build system, the bottleneck has nothing to do with using NextJS, even less to do with Gatsby.

[ajest]

Same problem here, we need to a solution

[esukram]

Hi everyone.

I am also affected by that problem 😞

2022-03-02T08:51:56.673Z [INFO]: Starting SSR Build...
2022-03-02T08:58:03.864Z [INFO]: SSR Build Complete.

A question to the Amplify folks: Do you know, why those build steps are slow? Is it some sort of remoting, what could be disabled / configured?

Thanks, Markus

[jw4949]

same issue here... any idea how to fix this?

[DavideCarvalho]

Deploy times were usually at 10 minutos, but since last wednesday it got even worse, going to 20 minutes to 1 hour

[TomJD]

How is this issue open for such a long time and no fixes have been implemented? Just as @manelephant said, how can Vercel achieve this working flawlessly and Amazon is still scratching its head?

[arshkkk]

Considering some caveats while working with AWS amplify for NextJS, after that getting longer time ( so higher prices )

I moved to vercel, so much easy and hassle free

[m1stermanager]

i had just decided to host an app via amplify to stay in the AWS ecosystem and now I have to figure something else out. frustrating.

[m1stermanager]

I imagine AWS doesn't care about this because vercel (from my understanding) is leveraging lambda.... so AWS gets the $$ in any case.... even if they are leaving some on the table

edit: be a little nicer.

[calavera]

hey folks 👋 I work on Amplify Hosting. We're working on improving this experience in this part of our product. Unfortunately, it's not an easy fix, but we're taking steps in the right direction.

[CauanCabral]

Thanks @calavera , keep us up to date, please.

More frustrating than the issue is the lack of any feedback from AWS team about it.