服务器端渲染

服务器端渲染是一种技术，它由服务器生成页面的完整标记并将其发送给浏览器，而不是发送一个最小化的文档，再由 JavaScript 填充内容。浏览器可以在收到响应后立即显示有意义的内容，而无需等待整个程序包下载、解析、执行和获取数据。

它解决了纯客户端渲染的一些具体且有据可查的缺陷。内容显示速度显著提升，尤其是在 JavaScript 执行成本较高的低速设备和网络连接上。搜索引擎和其他自动化用户可以直接获取内容，而无需依赖可能延迟或不完整的渲染阶段。社交分享预览无需特殊处理即可正常工作。此外，当 JavaScript 加载或执行失败时（这种情况比大多数团队预想的要频繁得多），用户体验也能更加优雅地降级。

水合作用是页面渲染过程中的必要成本，而且常常被低估。服务器渲染的标记显示完毕后，客户端框架必须附加事件处理程序并重建其内部状态，才能使页面具有交互性。在此期间，页面看起来已准备就绪，但实际上没有响应，这会导致一种明显的故障：访问者点击任何可见元素，但没有任何反应。在大型页面和速度较慢的设备上，这段时间可能会相当长。

为了降低这种成本，已经出现了几种方法。部分和选择性水合技术只使页面中可交互的部分具有交互性，而不是整个页面。流式传输技术逐步发送标记，使内容在整个页面生成之前就显示出来。孤岛架构将交互组件视为静态标记中的独立单元。这些方法都减少了初始渲染后所需的客户端工作量。

对于内容不会随请求而变化的情况，静态站点生成是值得优先考虑的方案。页面在构建时渲染并以文件形式提供，这比每次请求渲染速度更快、服务成本更低、弹性更高，也更容易在边缘进行缓存。如果内容会变化但并非每次访问者都会更改，则增量重建策略会按计划或按需重建受影响的页面，从而在无需完全重建的情况下获得大部分优势。

与静态托管相比，虚拟托管在运维方面存在诸多差异，需要提前规划。每次请求渲染都会消耗与流量成正比的服务器资源，这引入了静态文件所没有的扩展性和成本问题。缓存变得至关重要，而缓存包含个性化内容的页面则需要仔细区分哪些内容因用户而异，哪些内容保持不变。服务器错误现在会影响页面渲染，而不仅仅是数据加载。

数据获取策略在很大程度上决定了实际的性能优势。服务器端渲染只有在页面所需数据能够快速获取的情况下才有效，而需要等待多个缓慢的内部服务的服务器端渲染，其首字节响应速度可能比立即显示页面的客户端渲染慢。如果依赖项响应缓慢，则在等待其他部分解析的同时，先流式传输已准备就绪的部分，这样可以保持性能优势。

决策应以内容和受众为导向，而非盲目遵循框架形式。内容丰富、需要在搜索排名靠前且在网络连接不佳的情况下也能快速加载的页面将受益匪浅。而对于需要身份验证、搜索可见性无关紧要且用户已加载应用程序的高度交互式应用而言，获益则少得多，其复杂性可能并不值得。许多产品明智地针对不同部分采用不同的方法。

由于该选择会同时影响基础设施、交付和搜索性能，因此它是一个架构决策，而非前端偏好。在实践中，它会在以下方面进行评估： 网络性能 根据测量现场数据开展工作，并通过以下方式实施 产品开发并且，搜索的影响通过以下方式进行评估： 营销服务因为索引行为通常是支持这种改变的最有力论据。