服务器端 vs 客户端架构

服务器端 vs 客户端架构

当你访问一个网站时，有一个根本性问题：页面到底是在哪里构建的？是服务器准备好一切，给你发送一个完整的页面，还是你的浏览器下载一个骨架，然后自己构建页面？答案决定了从网站加载速度到搜索结果的显示效果等一切。

服务器端渲染：传统方法

在传统模型中，服务器承担繁重的工作。每当有人请求页面时，服务器从零开始组装HTML——从数据库提取数据，运行模板，并将完整页面发送到浏览器。这就是网络运行了几十年的方式，至今仍支撑着大量网站。

好处显而易见：搜索引擎可以轻松读取你的内容，因为它以完整形式到达。访问者看到的第一件事加载很快，因为无需等待JavaScript启动。即使有人禁用了JavaScript或使用非常旧的设备，页面也能正常工作。

但代价也是真实的。你的服务器必须更加努力，为每个请求生成页面。在页面之间导航意味着完全重新加载，这可能会感觉更慢。而且缓存变得更棘手——当每个页面都可能是个性化的时候，你不能为每个人提供相同的静态文件。

客户端渲染：类似应用的体验

现代替代方案颠覆了这种模式。服务器发送一个几乎空的HTML文件——只是一个容器——以及一个JavaScript包。然后你的浏览器接管，获取数据并完全在你的设备上构建界面。这就是单页应用程序的工作方式。

体验感觉更像原生应用。一旦初始加载完成，导航是即时的——无需刷新页面，无需等待服务器。服务器也减轻了负担，因为它只需提供静态文件和数据API。

但有一个问题。搜索引擎历史上难以读取富含JavaScript的网站，尽管它们已经改进很多。首次访问会感觉更慢，因为浏览器必须下载、解析并执行所有JavaScript，然后才能显示有意义的内容。在那段等待期间，访问者只能盯着空白屏幕。

静态站点生成：预构建以提高速度

如果你能两全其美呢？静态生成会在构建过程中提前构建所有页面。结果是放在CDN上的纯HTML文件，随时可以即时交付给任何人、任何地方。无需每个请求的服务器处理，也无需在首次加载时解析JavaScript包。

这非常快速且托管成本低廉。安全性极佳，因为请求时没有服务器端代码运行。但它只适用于内容不经常变化的情况——或者至少，不针对每个访问者不同。一个有1000篇文章的博客？完美。一个显示个性化数据的仪表板？不太行。

增量静态再生：折中方案

现代框架引入了一个巧妙的折中方案。页面最初是静态文件，但你可以告诉系统：“如果有人请求这个页面，并且它超过比如一个小时，就重新生成它。”阈值之后的第一个访问者会得到稍慢的响应，同时页面在后台重建，但之后的每个访问者都会得到新鲜的静态版本。

这为定期更新的内容提供了接近静态的性能——产品页面、带有评论的博客文章、文档——无需在每次内容变化时重建整个网站。

服务器组件：新篇章

最新的演变来自React生态系统。服务器不是发送HTML或完整的JavaScript应用，而是发送UI的轻量级描述——可以将其视为一组指令。浏览器使用它来更新页面，而无需为不需要交互的部分下载沉重的组件代码。

这意味着你可以编写直接与数据库通信或读取服务器文件系统文件的组件，而这些代码永远不会发送到浏览器。结果是：更小的JavaScript包，更快的初始加载，以及更简单的思维模型——数据获取就在你需要的地方进行。

选择适合你的方案

没有唯一的正确答案。内容密集型网站——博客、文档、营销页面——通过静态生成或增量再生表现最佳。电子商务产品页面受益于增量更新或服务器渲染的新鲜度。高度交互的仪表板和工具通常作为客户端应用或使用新的服务器组件模型效果最好。搜索可见性至关重要的页面应倾向于服务器渲染或静态生成。实时协作应用需要客户端架构自然处理的持久连接。

好消息是，现代框架允许你混合搭配。你可以在同一个项目中静态生成博客，服务器渲染结账页面，并将仪表板构建为客户端应用。架构服务于内容，而不是相反。