Server Actions dynamic rendering compared to static API fetch

[khuezy]

Verify canary release

• [X] I verified that the issue exists in the latest Next.js canary release

Provide environment information

N/A

Which area(s) of Next.js are affected? (leave empty if unsure)

App Router

Link to the code that reproduces this issue or a replay of the bug

https://sst-next-10-web.vercel.app/sa

To Reproduce

repo: https://github.com/khuezy/sst-next-10/blob/main/packages/web/app/sa/page.tsx

1. Go to site
2. Open Network tab
3. Click on "Fire Server Action" button 10 times to see average latency (~100ms)
4. Click on "Fire Regular fetch" button 10 times to see average latency (~25ms)

Describe the Bug

Using server actions incurs a 4x latency penalty compared to the traditional fetch api endpoint.

Expected Behavior

Server actions latency should be the same as regular /api calls. I understand Server Actions is still in alpha, hopefully it can be improved.

Which browser are you using? (if relevant)

N/A

How are you deploying your application? (if relevant)

Vercel, AWS, others.

[khuezy]

Example: the /sa endpoint is the server actions the /hello is the traditional /api/hello call

[jac0bbennett]

Is this due to vercel caching?

I see that for fetch, the response header X-Vercel-Cache is HIT, where the server action is MISS.

[khuezy]

Yea good catch, I think that either is partial or main reason for the extra latency.

[timneutkens]

Hey this is indeed a confusion between static and dynamic rendering, when you don't specify no-store on the fetch or on segment config and only have a GET in route handlers (route.ts / route.js) the route will be prerendered at build time which means it becomes a static payload. Server Actions can't be static by design, as they're meant to handle i.e. forms and rerendering of the path when you call revalidatePath / revalidateTag.

[khuezy]

Thanks for looking @timneutkens. You're correct, I missed the fact that it caches the static GET request during build.

[github-actions[bot]]

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.