Drawbacks of SSR
At the same time, there are significant drawbacks to enabling SSR. It adds complexity to your development process. Your code must run in two different environments: client-side and server-side (in a Node.js environment invoked from ASP.NET Core). Here are some things to bear in mind:
- SSR requires a Node.js installation on your production servers. This is automatically the case for some deployment scenarios, such as Azure App Services, but not for others, such as Azure Service Fabric.
- Enabling the
BuildServerSideRendererbuild flag causes your node_modules directory to publish. This folder contains 20,000+ files, which increases deployment time.
localStorage. If your code (or some third-party library you reference) tries to use these APIs, you’ll get an error during SSR. For example, don’t use jQuery because it references browser-specific APIs in many places. To prevent errors, you must either avoid SSR or avoid browser-specific APIs or libraries. You can wrap any calls to such APIs in checks to ensure they aren’t inv