Performance lag due to Supabase getUser calls in Next.js middleware

[filigreti]

Bug report

• [y] I confirm this is a bug with Supabase, not with my own application.
• [y] I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

Calling supabase.auth.getUser() using the createServerClient with the @supabase/ssr package on every page route in Next.js middleware causes noticeable lag, especially on slow networks.
This negatively affects user experience by slowing down route transitions.

To Reproduce

Create a Next.js app with middleware as shown in the supabase documentation.
Integrate Supabase with middleware as configured.
Navigate between routes, observing delays.
Turn on the browser slow mode to simulate slow network network speed

Expected behavior

I expected the route transitions to be smooth and not experience noticeable lag, even on slower network connections.

System information

• OS: [macOS]
• Browser (if applies) [hrome]
• Version of supabase-js: ["^2.39.3"]
• Version of Node.js: [stable version]

Additional context

Add any other context about the problem here.

[charislam]

Hi @filigreti! Moved this to a discussion because the instructions and SDK work as intended, but there are certain mitigations you can try:

1. If you have routes that don't require a Supabase call, you can update the matcher to exclude them.
2. You can also validate the JWT yourself in middleware, rather than calling the Supabase Auth server to do it. We generally don't recommend this because the performance benefit may not be worth the security risks. It is very important that you:

• Validate the JWT by checking the signature. Do not just rely on what the cookie tells you, because anyone can send any cookie to you that they want.
• Never leak the JWT signing key on the client. This can be easy to overlook on Next.js because of the mix of client and server code. Make sure wherever/however your signing key is imported, it is always isolated to server-only code.

Any route that requires a Supabase call (i.e., requires going through the middleware) is already making that call (and probably other calls) to begin with, so there are probably other reasons causing the slowdown as well. You can look into ways to increase the perceived speed of the response, for example via transitions

[kangmingtay]

I heard the team was considering asymmetric JWTs and possibly using a caching mechanism for getUser() to reduce latency. I'm not sure if this is being worked on or if it's off the table.

We're working on this right now - if you need to verify the JWT to use the claims outside of Supabase, you need to perform the verification on your own.

Once we have support for asymmetric JWTs, it will be much easier (and safer) to support this natively in the supabase-js package.

[j4w8n]

both approaches seem to have downsides: approach 1: use getSession() and risk security breaches. approach 2: use getUser() and risk degraded performance

what is the recommended way then?

(unfortunately all my existing routes have to go through middleware)

Supabase official recommendation is to call getUser. It might be best to stick with this for a bit longer, until the work kangmingtay spoke of is finished.

If you're willing to take things into your own hands, then the non-recommended but lowest-latency and safe way (in my opinion) is to verify and decode the JWT and create your own validated session. Be sure to only use your project's JWT secret on the server-side (which I heard can be a bit trickier in Next?). I have a SvelteKit example of this, but it's just js/ts if you're using a different framework. After the the team is done with their work, I plan to reevalute my approach. Checkout the event.locals.getSession code in https://github.com/j4w8n/sveltekit-supabase-ssr/blob/main/src/hooks.server.ts

[pppdns]

@kangmingtay any updates on the asymetric JWT work? Is there some branch/issue that we can subscribe to to get updates? (and possibly contribute?)

[CesGalaxy]

The only problem with that approach is that currently, supabase refreshes the user's session only when calling .auth.getUser() (not when calling .auth.getSession()), and thus if a user returns to your app 2 days later, they will be logged out.

I hope this helps someone:

My app was very slow with the middleware and I managed to fix it by creating an API route that calls the getUser() method, then at the root layout I wrapped all the pages with a client component that called that API route (I think you could make it run just once a day, so it doesn't call the API without reason) and the cookies get updated after refreshing the user token.

Sorry for my bad english :P

[PatrickRogg]

@kangmingtay any idea when you or someone from the team get a chance to work on this or when it will be completed?

I think this is one of the most impactful changes that you could make for Next.js.

I tested both getUser and getSession and the difference is massive. You literally can feel the difference as a user when navigating through pages. With getUser switching pages feels clunky and slow. With getSession switching pages is almost instant.