3 ms·

Does Next.js do pre-rendering, i.e. if I have a store with 500 products, will it pre-render the HTML (photos, etc.) for all 500 products and serve it as a stati

Does Next.js do pre-rendering, i.e. if I have a store with 500 products, will it pre-render the HTML (photos, etc.) for all 500 products and serve it as a static request? Or will it assemble the template on the server, send it down to the client and then do some amount of interactivity hydration later on during the page load? What if my store has multicurrency / multilingual versions of all these 500 pages - will it pre-render all of these combinations? I haven't used a JS framework with server-side rendering in a while - but from what I remember it seemed to add a terribly high TTFB to the overall page load, which negatively impacted SEO. As a result we abandoned SSR based frameworks completely and just went with minimal JS on the client and pre-rendered all the pages on the server as HTMLs which loaded pretty much instantly. Most of the time when I see the "new hotness" being advertised, there don't really seem to be any specifics that tackle advanced use-cases so it's difficult to accurately assess whether the technology is worth serious consideration

mathnovice 6y ago
> if I have a store with 500 products, will it pre-render the HTML (photos, etc.) for all 500 products and serve it as a static request? You can set it up to retrieve all 500 products and render the html on the server. > What if my store has multicurrency / multilingual versions of all these 500 pages - will it pre-render all of these combinations? The server is making all the requests that would have been made on the frontend. So if the server knew the locale of the user it could presumably load the correct currency and language.
chrisco255 6y ago
Next.js can do both pre-rendering (static output) and dynamic server-side rendering. I can't speak to your questions about internationalization though.
ryanto 6y ago
yes, next will prerender everything. you should give it a try.
rory 6y ago
It _can_ prerender all of those combinations. Here is a directory I made with 1000+ pages, prerendered and hosted for free on netlify: https://www.givepuppylove.com/organizations/ https://www.givepuppylove.com/organizations/ . I've found that single digit thousands is about the maximum you can currently have and keep build times reasonable. If you want to recognize the user's location and display the appropriate currency or language, you would probably want to wrap content dependent on location in a "ClientOnly" type component. So it would not be prerendered in that case. Example code: export default function ClientOnly({ children, ...delegated }) { const [hasMounted, setHasMounted] = useState(false) useEffect(() => { setHasMounted(true) }, []) return hasMounted ? <div {...delegated}>{children}</div> : <div></div> } This allows you to grab things off the "window" and change behavior based on that info, which you can't do with prerendering.
- rory 6y ago
  As far as count of pages Vercel has a limit of 16000 and Netlify technically has no limit (AFAIK), although the build times will cost you eventually. You can work around this limit in a lot of cases while keeping things prerendered by putting dynamic information in querystrings.
  - acoard 6y ago
    You're totally right. Apparently this on the Nextjs team's radar though: >Up next, we will be working on a supplemental RFC to address two additional incremental static generation capabilities: > - Re-generating and invalidating multiple pages at once (like your blog index and a certain blog post) > - Re-generating by listening to events (like CMS webhooks), ahead of user traffic Source: https://nextjs.org/blog/next-9-5#stable-incremental-static-regeneration https://nextjs.org/blog/next-9-5#stable-incremental-static-r... But yeah, if you have 10k pages it seems unavoidable to me that initial build time will be high. With `fallback: 'blocking` you could decide to build each page at runtime when it is requested for the first time – this spreads out initial build time. What would be nice is being able to re-use compiled pages across builds. Imagine having 10k pages compiled, and you have to push out a new build that only updates 5 pages, or none at all (eg an API change). It would be nice if it could make use of the compiled pages from the previous build, only re-compiling the pages that needed it. Of course the devil is in the details, and figuring out which pages need to be re-compiled basically requires you re-building the pages.
ThalesX 6y ago
Disclaimer being that I'm talking mostly about 5 - 10 page presentation websites, consistently, I achieve 95+ on Google Page Speed for Mobile when deploying the Next.JS solutions on the Vercel infrastructure. There are helpers for working with images that can generate multiple versions, transform to WebP and other stuff. This is where most of the optimization work goes I think. > Most of the time when I see the "new hotness" being advertised, there don't really seem to be any specifics that tackle advanced use-cases so it's difficult to accurately assess whether the technology is worth serious consideration I'm also averse to 'hotness' but at the same time, consideration should be given based on use case. I can't talk for advanced use-cases with Next.JS but using it for the one off freelancing simple website gig, it's a breath of fresh air. There's also a customer serving around 100.000 pregenerated web pages (simple stuff, catalog item with pictures, related items and people linked to it) and the speed is insane for navigating their internal catalogue :)
gherkinnn 6y ago
I recently played around with Next 9.5 prerendering. It had about 400 simple pages with artificially slow API responses to get an idea. - you can prerender a decent amount of pages no probs - you can prerender only a subset and then have Next render the necessary pages on the server upon request - as the page is being prerendered, you can send placeholder content, so ttfb is low - linking to a non-prerendered page within Next will prefetch (and thus prerender) said page as soon as the link is in the viewport (can be disabled) - in Vercel you can set the branch name as an env variable. I set it to prerender almost nothing during build time if the branch name contained “hotfix” So far I think it is worth serious consideration. Will it work for you? I dunno. But it’s a breeze to set up, quick to learn, and run some experiments of your own.
dbbk 6y ago
> I haven't used a JS framework with server-side rendering in a while - but from what I remember it seemed to add a terribly high TTFB to the overall page load, which negatively impacted SEO. You can just stick a CDN like Cloudflare in front of your requests, and this issue is resolved.

mathnovice 6y ago

> if I have a store with 500 products, will it pre-render the HTML (photos, etc.) for all 500 products and serve it as a static request? You can set it up to retrieve all 500 products and render the html on the server. > What if my store has multicurrency / multilingual versions of all these 500 pages - will it pre-render all of these combinations? The server is making all the requests that would have been made on the frontend. So if the server knew the locale of the user it could presumably load the correct currency and language.

chrisco255 6y ago

Next.js can do both pre-rendering (static output) and dynamic server-side rendering. I can't speak to your questions about internationalization though.

ryanto 6y ago

yes, next will prerender everything. you should give it a try.

rory 6y ago

It _can_ prerender all of those combinations. Here is a directory I made with 1000+ pages, prerendered and hosted for free on netlify: https://www.givepuppylove.com/organizations/ https://www.givepuppylove.com/organizations/ . I've found that single digit thousands is about the maximum you can currently have and keep build times reasonable. If you want to recognize the user's location and display the appropriate currency or language, you would probably want to wrap content dependent on location in a "ClientOnly" type component. So it would not be prerendered in that case. Example code: export default function ClientOnly({ children, ...delegated }) { const [hasMounted, setHasMounted] = useState(false) useEffect(() => { setHasMounted(true) }, []) return hasMounted ? <div {...delegated}>{children}</div> : <div></div> } This allows you to grab things off the "window" and change behavior based on that info, which you can't do with prerendering.

rory 6y ago
As far as count of pages Vercel has a limit of 16000 and Netlify technically has no limit (AFAIK), although the build times will cost you eventually. You can work around this limit in a lot of cases while keeping things prerendered by putting dynamic information in querystrings.
- acoard 6y ago
  You're totally right. Apparently this on the Nextjs team's radar though: >Up next, we will be working on a supplemental RFC to address two additional incremental static generation capabilities: > - Re-generating and invalidating multiple pages at once (like your blog index and a certain blog post) > - Re-generating by listening to events (like CMS webhooks), ahead of user traffic Source: https://nextjs.org/blog/next-9-5#stable-incremental-static-regeneration https://nextjs.org/blog/next-9-5#stable-incremental-static-r... But yeah, if you have 10k pages it seems unavoidable to me that initial build time will be high. With `fallback: 'blocking` you could decide to build each page at runtime when it is requested for the first time – this spreads out initial build time. What would be nice is being able to re-use compiled pages across builds. Imagine having 10k pages compiled, and you have to push out a new build that only updates 5 pages, or none at all (eg an API change). It would be nice if it could make use of the compiled pages from the previous build, only re-compiling the pages that needed it. Of course the devil is in the details, and figuring out which pages need to be re-compiled basically requires you re-building the pages.

ThalesX 6y ago

Disclaimer being that I'm talking mostly about 5 - 10 page presentation websites, consistently, I achieve 95+ on Google Page Speed for Mobile when deploying the Next.JS solutions on the Vercel infrastructure. There are helpers for working with images that can generate multiple versions, transform to WebP and other stuff. This is where most of the optimization work goes I think. > Most of the time when I see the "new hotness" being advertised, there don't really seem to be any specifics that tackle advanced use-cases so it's difficult to accurately assess whether the technology is worth serious consideration I'm also averse to 'hotness' but at the same time, consideration should be given based on use case. I can't talk for advanced use-cases with Next.JS but using it for the one off freelancing simple website gig, it's a breath of fresh air. There's also a customer serving around 100.000 pregenerated web pages (simple stuff, catalog item with pictures, related items and people linked to it) and the speed is insane for navigating their internal catalogue :)

gherkinnn 6y ago

I recently played around with Next 9.5 prerendering. It had about 400 simple pages with artificially slow API responses to get an idea. - you can prerender a decent amount of pages no probs - you can prerender only a subset and then have Next render the necessary pages on the server upon request - as the page is being prerendered, you can send placeholder content, so ttfb is low - linking to a non-prerendered page within Next will prefetch (and thus prerender) said page as soon as the link is in the viewport (can be disabled) - in Vercel you can set the branch name as an env variable. I set it to prerender almost nothing during build time if the branch name contained “hotfix” So far I think it is worth serious consideration. Will it work for you? I dunno. But it’s a breeze to set up, quick to learn, and run some experiments of your own.

dbbk 6y ago

> I haven't used a JS framework with server-side rendering in a while - but from what I remember it seemed to add a terribly high TTFB to the overall page load, which negatively impacted SEO. You can just stick a CDN like Cloudflare in front of your requests, and this issue is resolved.