#ssr and csr clarification

16 messages · Page 1 of 1 (latest)

uneven canopy
#

Hello, i ve a simple next.js 13.4 app that fetches some users with ssr and same app with csr and i compare the times shown in browser dev tools but csr calls are faster. Shoud i expect ssr same calls to have lower time?

uneven canopy
#

Yes, this behavior is in production build

#

For ssr, i use for fetch the parameter cache: 'no-store' based to the new api data fetching of next.js 13.4

stone perch
#

How did you fetch users? Is it from your own database or is it from external database hosted offshore?

uneven canopy
#

It s just a dummy endpoint from jsonplaceholder

dreamy sleet
uneven canopy
dreamy sleet
#

If you're revalidating it, you're not caching it, so I'm not sure if I'm following your question

#

generally you shouldn't need to revalidate unless you've sent a mutation and know it's been updated

#

otherwise you can just set the revalidate interval in the route segment config and it will revalidate on its own

uneven canopy
dreamy sleet
#

it's cached by default, sending no-cache opts you out of it for that request.

uneven canopy
#

I understand, so i will use fetch without extra parameter and it caches by default and it continues to be ssr i think