为了加速繁重的 web 应用程序，每个浏览器和 web 服务器都采用缓存机制来缓存客户端机器上的可重用脚本。 这改善了 CSR 和 SSR 的加载时间。 然而，CSR 有一个主要的好处。
在 CSR 中，只要不需要延迟加载模块，基于 CSR 的 Web 应用程序也可以在没有互联网的情况下运行（除非您调用数据 API）。 加载后，应用程序不再需要向服务器发送请求。这允许浏览 Web 应用程序，就像一个简单的桌面应用程序。
然而，在 SSR 中，总是向服务器发送请求。 因此，与 CSR 相比，SSR 的页面加载时间无疑更长。缓存确实提高了 SSR 的内容渲染速度，因为浏览器需要从缓存中检索必要的脚本。下图描述了浏览器如何处理对缓存脚本的重复请求：
请注意，大多数脚本是从内存或磁盘加载的。 这大大缩短了加载时间并防止了服务器上的过度负载。
如何选择合适的渲染方案 Dynamic Content Loading服务器通常驻留在具有更高计算能力和显着更高网络速度的机器上。 凭借这种速度和能力，它在处理预期数量的处理请求时永远不会耗尽资源。 结果，在服务器上获取内容变得相对更快。
另一方面，客户端计算机的计算能力有限，在客户端获取和呈现动态内容可能需要更长的时间。 这意味着获取呈现的内容所消耗的总时间会更长。 因此，如果您的网站涉及重复的动态内容呈现，SSR 是比 CSR 更好的选择。
Web Application UX vs Website UX尽管它们看起来几乎相同，但 Web 应用程序和网站是两种不同的 Web 内容格式。 Web 应用程序是一个完整的应用程序，可用于会计、CRM、人力资源管理、项目管理等目的。另一方面，网站提供信息内容。
与网站相比，Web 应用程序涉及更多的用户交互。 在用户交互较高的场景中，确保用户交互不会花费很长时间是至关重要的。 因此，与 SSR 相比，CSR 更适用于 Web 应用程序。
另一方面，对于网站，如果每次点击都加载新网页，对于客户来说也能接受，因为缓存通常会负责加速渲染。 此外，SSR 还确保为爬虫提供正确的元数据——与 CSR 相比，这使得 SSR 更适合网站。
结论CSR 和 SSR 对于您计划提供给用户的 UX 至关重要。 我希望本文能帮助您从功能和实用的角度理解这些概念。 最终的选择最终是你的。 考虑到上述因素，明智地选择。 错误的选择可能会让您重新开发整个网站或 Web 应用程序。 正确的选择可能会减少您将来的代码管理工作。
更多Jerry的原创文章，尽在："汪子熙":