认识达内从这里开始

我们在前几期的文章中给大家简单介绍了服务器渲染的一些基础知识与常见类型等内容，而本文我们就继续通过案例分析来了解一下，服务器静态渲染与客户端渲染的实践方法。

1、静态渲染

静态渲染发生在构建时，并提供快速的次绘制、次内容绘制和交互时间-假设客户端JS的数量有限。与服务器渲染不同，它还设法实现始终如一的快速字节时间，因为页面的HTML不必即时生成。通常，静态呈现意味着提前为每个URL生成单独的HTML文件。通过提前生成HTML响应，可以将静态呈现器部署到多个CDN以利用边缘缓存。

静态渲染的解决方案有各种形状和大小。Gatsby之类的工具旨在让开发人员感觉他们的应用程序是动态呈现的，而不是作为构建步骤生成的。其他像Jekyll和Metalsmith这样的公司拥抱它们的静态特性，提供了一种更加模板驱动的方法。

静态呈现的缺点之一是必须为每个可能的URL生成单独的HTML文件。如果您无法提前预测这些URL的内容，或者对于具有大量独特页面的网站，这可能具有挑战性甚至不可行。

React用户可能熟悉Gatsby、Next.js静态导出或Navi-所有这些都可以方便地使用组件进行创作。但是，了解静态渲染和预渲染之间的区别很重要：静态渲染页面是交互式的，无需执行大量客户端JS，而预渲染改进了必须启动的单页应用程序的次绘制或次内容绘制客户端以使页面真正具有交互性。

如果您不确定给定的解决方案是静态渲染还是预渲染，请尝试以下测试：禁用JavaScript并加载创建的网页。对于静态呈现的页面，大多数功能在没有启用JavaScript的情况下仍然存在。对于预渲染页面，可能仍然有一些基本功能，如链接，但大部分页面将是惰性的。

2、客户端渲染(CSR)

客户端渲染(CSR)是指使用JavaScript直接在浏览器中渲染页面。所有逻辑、数据获取、模板和路由都在客户端而不是服务器上处理。

对于移动设备，客户端渲染可能难以获得并保持快速。如果做少的工作，保持紧张的JavaScript预算并以尽可能少的RTT交付价值，它可以接近纯服务器渲染的性能。使用HTTP/2服务器推送或\<linkrel=preload>可以更快地交付关键脚本和数据，这可以让解析器更快地为您工作。像PRPL这样的模式值得评估，以确保初始和后续导航感觉即时。

客户端渲染的主要缺点是所需的JavaScript量会随着应用程序的增长而增长。添加新的JavaScript库、polyfill和三方代码后，这变得尤其困难，它们会争夺处理能力，并且通常必须在呈现页面内容之前进行处理。使用依赖于大型JavaScript包的CSR构建的体验应该考虑积极的代码拆分，并确保延迟加载JavaScript——“只在需要时提供您需要的服务”。对于交互性很少或没有交互性的体验，服务器渲染可以代表这些问题的更具可扩展性的解决方案。

对于构建单页应用程序的人来说，识别大多数页面共享的用户界面的核心部分意味着您可以应用应用程序外壳缓存技术。与服务工作者相结合，这可以显着提高重复访问时的感知性能。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。