做网站读哪个专业,中国招标采购导航网,网络营销策划是什么意思,怎么在网上卖东西?渲染模式有好多种#xff0c;了解下web的各种渲染模式#xff0c;对技术选型有很大的参考作用。
一、静态HTML时代
早期#xff08;1990 - 1995年#xff09;网页开发完全依赖手工编写HTML#xff08;HyperText Markup Language#xff09;和CSS#xff08;层叠样式表…渲染模式有好多种了解下web的各种渲染模式对技术选型有很大的参考作用。
一、静态HTML时代
早期1990 - 1995年网页开发完全依赖手工编写HTMLHyperText Markup Language和CSS层叠样式表。开发者通过文本编辑器如Notepad、Vi直接编写代码定义页面的结构和样式。
HTML文件通常包含固定的文本、图片和超链接CSS用于简单的样式调整如字体颜色、背景色。例如
htmlheadtitle我的第一个网页/titlestylebody { background-color: #ffffff; }h1 { color: #0000ff; }/style/headbodyh1欢迎访问我的网站/h1p这是一个静态页面。/p/body
/html开发者将编写好的HTML/CSS文件通过FTP文件传输协议工具如FileZilla、WS_FTP上传到Web服务器。服务器接收到请求后直接返回这些静态文件给用户的浏览器。
服务器在此阶段仅作为“文件存储仓库”不涉及任何动态处理逻辑如计算、数据库查询直接返回预存的HTML文件。
1.解决的问题
静态HTML的诞生标志着互联网从“文档共享”向“信息展示”的转变。
早期的网页主要用于展示固定内容例如
公司介绍如企业官网新闻公告如报纸的在线版本个人主页如学者或爱好者的个人博客
通过HTML的超链接特性用户可以轻松跳转到其他页面形成“超文本网络”。
由于无需复杂的后端逻辑或数据库静态网页的开发和部署成本极低适合资源有限的早期互联网环境。
2.局限与痛点
1内容更新需手动修改并重新部署
如果需要修改网页内容如更新新闻标题开发者必须重新打开HTML文件手动修改代码保存后再通过FTP重新上传到服务器。这一过程耗时且容易出错。
对于频繁更新的网站如新闻门户维护成本极高。
2无交互能力
静态网页无法实现动态功能。例如
表单验证用户提交表单后服务器无法实时校验输入是否正确。动态内容无法根据用户请求生成个性化内容如显示用户登录状态。
用户只能被动浏览内容无法参与互动如注册、评论、搜索。
3多页面重复内容维护成本高
多个页面的公共部分如导航栏、页脚需要重复编写HTML代码。例如
!-- 页面1 --
nava hrefindex.html首页/aa hrefabout.html关于我们/a
/nav!-- 页面2 --
nava hrefindex.html首页/aa hrefabout.html关于我们/a
/nav(4)SEO搜索引擎优化受限
早期搜索引擎主要依赖静态HTML的结构化标签如h1、title抓取内容。但静态网页缺乏动态元数据如动态生成的描述标签导致SEO效果有限。
3.代表技术
Apache1995年推出的Apache HTTP Server成为当时最流行的Web服务器软件。它支持静态文件的高效分发并通过.htaccess文件管理权限和重定向规则。
Nginx2004年推出的Nginx以高性能著称尤其擅长处理高并发的静态文件请求。
FTP工具如FileZilla:允许开发者将本地文件上传到远程服务器是早期网页部署的核心工具。FTP缺乏版本控制功能容易因多人协作导致文件冲突。
4.本质文件分发与超文本系统
在静态HTML时代Web的核心功能是“文件分发”。服务器仅负责存储和返回预先生成的HTML文件不进行任何计算或动态处理。
例如用户访问http://example.com/index.html时服务器直接返回存储在硬盘上的index.html文件。
Web被设计为“超文本系统”其核心是通过超链接a标签将分散的文档连接成网络。例如
a hrefabout.html关于我们/a用户点击链接后浏览器会向服务器发起新的请求获取目标页面的HTML文件并渲染。
服务器在此阶段完全不具备动态处理能力。例如无法存储或查询用户数据服务器无法运行JavaScript或其他脚本语言所有内容必须在部署前编写完成。
静态HTML时代奠定了互联网的基础但其局限性也显而易见。
随着用户需求的复杂化如动态内容、交互功能后续技术如CGI、PHP、JavaScript逐渐兴起推动Web从“静态文档展示”向“动态交互应用”演进。
二、动态脚本与模板引擎服务端渲染SSR 1.0
后来1995 - 2005年出现了动态脚本语言例如PHPHypertext Preprocessor、JSPJavaServer Pages、ASPActive Server Pages等动态脚本语言允许开发者在服务端动态生成HTML内容。
通过脚本语言将数据库中的数据与HTML模板结合输出完整的页面。例如
!-- PHP示例 --
?php$user Alice;echo h1Welcome, $user/h1;
?!-- JSP示例 --
%String user Bob;
%
h1Welcome, % user %/h1早期动态脚本语言结合模板引擎如Smarty、Jinja2进一步分离逻辑与视图。例如
!-- Smarty模板示例 --
h1Welcome, {$user}/h1此种模式的特点是所有页面生成逻辑在服务器完成浏览器仅负责渲染静态HTML。
工作流程如下
用户请求 → 服务器执行脚本 → 动态生成HTML → 返回给浏览器解析。这种模式也叫服务端渲染SSR 1.0模式
1.解决的问题
动态脚本语言支持连接数据库如MySQL、Oracle实现内容实时更新。例如
// PHP连接数据库示例
$conn mysqli_connect(localhost, user, password, dbname);
$result mysqli_query($conn, SELECT * FROM users);
while ($row mysqli_fetch_assoc($result)) {echo p . $row[name] . /p;
}这种方式广泛应用于电商网站商品列表、新闻门户实时更新、用户个人资料页等。
通过动态脚本处理表单数据、验证用户输入、实现登录/注册功能。例如
// PHP表单处理示例
if ($_SERVER[REQUEST_METHOD] POST) {$username $_POST[username];$password $_POST[password];// 验证逻辑echo Welcome, $username;
}通过Session/Cookie实现用户登录状态的维护。
模板引擎如Smarty、Jinja2允许开发者复用公共模块如导航栏、页脚避免重复编写HTML。例如
!-- Smarty模板复用示例 --
{include fileheader.tpl}
mainp动态内容区域/p
/main
{include filefooter.tpl}2.局限与痛点
1前后端强耦合
后端工程师需同时处理业务逻辑如数据库操作和HTML拼接导致代码臃肿。
前端设计师无法独立开发界面协作效率低下。
2体验差
每次用户交互如点击按钮、提交表单需重新加载整个页面导致“整页刷新”。
用户体验卡顿交互响应慢。
3扩展性弱
服务端需为每个请求生成完整HTML流量激增时服务器易成为性能瓶颈。
高并发场景下服务器负载过高响应时间变长。
3.技术代表
WordPressPHP:基于PHP的开源内容管理系统CMS通过插件和模板实现动态页面生成。低门槛、快速搭建博客/网站支持主题定制和扩展。
DjangoPython:特点Python的Web框架内置ORM对象关系映射和模板引擎Django Templates。开箱即用的功能如认证系统、数据库迁移适合中大型项目。
Java Servlets/JSPJava的Web开发技术通过Servlet处理请求JSP实现动态HTML生成。企业级应用的稳定性与扩展性适合高并发场景如银行系统。
4.本质渲染服务端计算
页面渲染完全由服务器完成浏览器仅负责解析和显示生成的HTML。
用户请求 → 服务器执行PHP/JSP脚本 → 生成HTML → 返回浏览器 → 渲染页面与静态HTML的对比此模式页面内容动态生成服务器需执行脚本并返回结果。
就是服务器需为每个请求生成HTML资源消耗大。动态内容也难以预渲染或缓存导致重复计算。
动态脚本与模板引擎1995-2005年标志着Web从“静态文档展示”向“动态交互应用”的过渡。
通过PHP/JSP/ASP等技术开发者实现了内容动态化、用户交互和代码复用但也暴露了前后端强耦合、整页刷新和扩展性差等问题。
这一阶段奠定了服务端渲染SSR的基础为后续MVC框架如Spring MVC、Ruby on Rails和前后端分离架构的演进提供了方向。
三、Ajax崛起与CSR时代前后端分离的雏形
2005年谷歌在Gmail中大规模应用AjaxAsynchronous JavaScript and XML首次展示了无需刷新页面即可实现动态内容更新的能力。
XMLHttpRequestXHR是JavaScript中用于发送HTTP请求的API允许浏览器在不刷新页面的情况下与服务器通信。
它的核心功能是发起异步请求GET/POST接收服务器返回的JSON/XML数据动态更新页面局部内容如评论列表、搜索结果。
const xhr new XMLHttpRequest();
xhr.open(GET, https://api.example.com/data, true);
xhr.onreadystatechange function () {if (xhr.readyState 4 xhr.status 200) {document.getElementById(content).innerHTML xhr.responseText;}
};
xhr.send();2006年John Resig推出jQuery解决了早期JavaScript开发的痛点如跨浏览器兼容性、繁琐的DOM操作。
它的核心功能是通过简洁的API如$(#id)快速定位和操作元素统一处理浏览器差异如IE与Firefox的事件模型简化XHR调用如$.ajax()。
$.ajax({url: /api/comments,method: GET,success: function (data) {$(#comments).html(data);}
});但是jQuery 时代 DOM 操作很混乱状态逻辑分散难维护手动性能优化成本高。
2013年React 诞生了Facebook 为解决复杂动态 UI 的维护难题如新闻流实时更新而推出首次引入虚拟 DOM和组件化开发模式。
2014年尤雨溪推出了Vue技术该框架为平衡渐进式开发体验可逐步集成与高性能响应式更新而设计核心是响应式数据绑定 和 模板编译。
两者重新定义了前端开发范式组件化、数据驱动并主导了现代 Web 渲染架构演进解决了复杂交互界面的可维护性与动态视图的更新性能。
1.解决的问题
实现无刷新局部更新用户提交评论后仅更新评论区域无需刷新整个页面。或者输入关键词时动态加载匹配结果如Google搜索建议。
这样减少了页面跳转避免“白屏”现象。仅传输必要的数据如JSON降低了带宽消耗。
同时这也是前后端职责分离的雏形。
后端角色只需要提供标准化的API如RESTful API专注于数据处理和业务逻辑。
GET /api/users/123 HTTP/1.1
Accept: application/json前端角色也只需要负责页面渲染和交互逻辑如通过JavaScript动态更新内容。
fetch(/api/users/123).then(response response.json()).then(data renderUserProfile(data));2.局限和痛点
1白屏时间长
特别是在单页面应用SPA时代前端需先下载并解析JavaScript框架如React、Vue页面初始化时需等待多个API请求完成动态生成DOM树并绑定事件耗时较长。
用户首次访问时可能看到空白页面体验不佳。
2SEO不友好
搜索引擎爬虫如Googlebot难以解析JavaScript动态生成的内容传统SEO优化手段如标签、静态HTML失效。
早期的单页应用SPA因内容无法被爬取导致搜索引擎排名下降。
3低端设备体验差
大体积JavaScript框架如jQuery 多个插件在低端手机或老旧浏览器中执行缓慢。
动态渲染依赖JavaScript若网络延迟或脚本执行失败页面无法正常显示。
3.技术代表
1Backbone.js引入MVC模式
将应用分为模型Model、视图View、控制器Controller通过事件绑定实现数据与视图的解耦。
框架本身仅提供基础结构开发者需自行组织代码适合需要高度定制化的项目如企业级应用。
const User Backbone.Model.extend({defaults: { name: Guest }
});
const UserView Backbone.View.extend({render: function () {this.$el.html(h1 this.model.get(name) /h1);}
});
const user new User({ name: Alice });
const view new UserView({ model: user, el: #user-profile });
view.render();(2) AngularJS双向绑定
视图与模型自动同步如表单输入与变量直接关联通过HTML指令如ng-model定义交互逻辑。
提供路由、依赖注入、表单验证等内置功能适合需要强结构化的大型项目如管理后台。
div ng-appmyApp ng-controllerUserControllerinput typetext ng-modeluser.nameh1{{ user.name }}/h1
/div
scriptangular.module(myApp, []).controller(UserController, function ($scope) {$scope.user { name: Bob };});
/script4.本质客户端计算与异步交互的革命
此阶段的核心是“客户端生成HTML”浏览器通过JavaScript动态加载数据并渲染页面服务器仅提供数据接口如REST API。
计算逻辑从服务端转移到客户端浏览器不再是“解析器”而是具备动态计算能力的“终端”。
通过 XMLHttpRequestXHR或 Fetch API 实现异步请求页面无需整体刷新即可更新局部内容如评论列表、搜索建议。
打破“请求-刷新”的同步模式引入“事件驱动”的异步交互范式。
无刷新更新提升了交互流畅性。jQuery和MVC框架降低了前端开发门槛。
Ajax的出现标志着Web从“服务端渲染”向“客户端渲染”CSR过渡推动了前后端分离的雏形。
前后端开发可以并行降低耦合度提升开发效率。后端可使用任意语言如Java、Python前端统一使用JavaScript。
但白屏时间、SEO问题限制了大规模应用低端设备兼容性挑战凸显。
React/Vue 的出现让 CSR 成为主流但也暴露了 SEO 与首屏性能的短板进而催生新一代解决方案。例如同构渲染框架Next.js/Nuxt.js的诞生。
后续如Next.js、Nuxt.js结合CSR的优势解决SEO和首屏加载问题通过标准化组件化开发减少对框架的依赖。
这一阶段奠定了现代Web应用如React、Vue的基础推动了前后端分离、API经济和前端工程化的浪潮同时也为后续技术如SSR优化、PWA、WebAssembly提供了演进方向。
四、服务端渲染SSR复兴与现代化演进
如前面所说客户端渲染CSR虽然提升了交互体验但暴露了不少问题。
搜索引擎爬虫难以解析JavaScript动态生成的内容如早期SPA需等待JS下载、解析、执行后才能渲染内容用户体验差大体积JS框架在低性能设备上执行缓慢。
很多网站之所以使用SSR主要目的是做搜索引擎优化SEO。
由于所处的国家和利益不同谷歌很早就支持对使用Ajax技术异步渲染内容的网站进行爬取它们洞见了这种技术将会被广泛利用不过谷歌在服务端的开销也要增加很多因为这依赖于一个模拟的浏览器环境。
百度至今仍不支持爬取动态渲染内容为主的网站可能是国内目前需营销的网站大多还是静态内容站吧。因此是否需要SSR最主要的因素就是是否需要SEO换句话说你的产品是面向大众用户的还是面向企业的。如果是面向企业那可能只有首页、信息页和一些营销页面需要SEO与主产品分离。
使用SSR的第二原因是客户端的网络可能是不稳定的有的地方很快有的地方会很慢。
这种情况下通过SSR减少请求量和客户端渲染可以相对快速地看到内容。
因此人们想到需要结合服务端能力如SSR与客户端动态交互的优势形成新的技术演进。
一 同构渲染Isomorphic SSR
现代的技术框架可以通过同一套代码实现服务端渲染SSR与客户端交互CSR兼顾SEO、首屏性能与动态交互。
React生态的Next.js自动处理SSR与HydrationVue生态的Nuxt.js提供SSR模板与生命周期钩子。
原理为前后端共享组件与业务逻辑减少重复开发服务端渲染时同步获取所需数据避免客户端二次请求。
搜索引擎可直接抓取服务器生成的HTML用户无需等待JS执行即可看到内容Hydration后页面具备CSR的交互能力。
缺点是每次请求需动态渲染HTML高并发场景下压力较大需处理服务端与客户端环境差异如全局变量、DOM操作。
1.工作原理
1服务端渲染首屏HTML
使用Node.js运行React/Vue等框架在服务器端将首屏内容渲染为完整的HTML字符串。
当用户发起请求时服务器根据路由和请求参数动态生成 HTML 内容。服务器使用前端框架如 Vue、React、Angular将组件渲染为 HTML 字符串。服务器将生成的 HTML、初始数据以及客户端所需的 JavaScript 一并发送给浏览器。
// 服务端代码Node.js
import React from react;
import { renderToString } from react-dom/server;
const App () divHello SSR!/div;
const html renderToString(App /);2客户端“注水”Hydration
浏览器加载HTML后注入JavaScript代码激活页面交互逻辑如事件绑定、状态管理。
浏览器接收到完整的 HTML 后直接展示内容。客户端的 JavaScript 会“水合”Hydration页面将静态 HTML 转换为动态交互的单页应用SPA。
// 客户端代码Browser
import React from react;
import { hydrate } from react-dom;
const App () divHello SSR!/div;
hydrate(App /, document.getElementById(root));2.解决的问题
1更快的首屏加载
用户无需等待 JavaScript 下载和执行页面内容可以直接显示显著提升首屏加载速度。对于网络较差或低端设备效果尤为明显。
2 更好的 SEO
搜索引擎爬虫可以直接抓取服务器生成的完整 HTML 内容无需执行 JavaScript有利于提高搜索引擎排名。特别适合内容密集型网站如新闻、博客、电商商品页。
3用户体验优化
避免首屏白屏问题用户能快速看到页面内容对低性能设备更友好减少客户端的计算压力。
4兼容性更强
即使浏览器禁用 JavaScriptSSR 生成的 HTML 也能正常显示内容。
3.痛点
1 SSR的服务器压力问题
高并发场景下动态渲染HTML会导致服务器资源紧张。
当然也有解决办法可以对高频访问页面启用HTTP缓存如ETag、Cache-Control在CDN边缘节点预渲染动态内容如Cloudflare Workers通过Kubernetes等工具水平扩展服务端实例。
2交互延迟
页面首次加载后需要客户端“水合”过程可能稍显延迟。
二静态站点生成SSG
在构建时预渲染所有页面为静态HTML文件托管至CDN实现极速加载。
使用工具如Gatsby、Next.js将Markdown、CMS数据或API响应编译为HTML。
// pages/index.js
export async function getStaticProps() {const res await fetch(https://api.example.com/data);const data await res.json();return { props: { data } };
}将生成的HTML、CSS、JS文件托管到CDN如Cloudflare利用边缘节点加速分发。
CDN缓存静态HTML全球用户访问速度一致静态HTML可被搜索引擎直接抓取仅需托管静态文件无需服务器动态渲染。
就是页面内容需在构建时确定实时数据如股票行情无法更新大规模站点需较长的构建时间。
2. 局限和痛点
1SSG的实时性限制
静态页面无法实时更新如新闻、电商价格。
当然可以仅重新生成受影响的页面如Next.js的Incremental Static Regeneration对动态内容使用SSR静态内容使用SSG通过WebSocket或Server-Sent EventsSSE在客户端更新数据。
服务端渲染Server-Side RenderingSSR是一种在服务器端生成完整 HTML 页面并直接返回给客户端浏览器的技术。
五、边缘计算与流式演进2020s至今ESR与增量渲染
传统服务端渲染SSR需将请求从用户浏览器发送到中心服务器再由服务器生成HTML并返回。
这一过程受“用户-服务器”物理距离影响导致首屏时间TTFB较长尤其在跨国访问或网络不稳定场景下表现不佳。
动态内容如用户个性化推荐、实时数据需服务器实时查询数据库或API进一步增加延迟。
一 边缘渲染Edge Streaming Rendering, ESR
边缘渲染模式是通过CDN边缘节点将页面拆分为静态内容与动态内容分别处理并流式返回显著缩短首屏时间。
静态内容通过HTML框架和基础资源由CDN直出而动态内容通过边缘节点请求源站数据并以流式方式返回。
还可以CDN节点全球部署就近服务用户动态数据请求分散至边缘节点减轻中心服务器压力。
1.核心原理
1静态内容优先返回
CDN边缘节点缓存HTML框架、CSS、JS等静态资源直接返回给用户避免“白屏”等待。
示例导航栏、页脚等通用部分可立即加载用户无需等待动态数据。
2动态内容并行加载
边缘节点同时向源站请求动态数据如用户信息、实时推荐并将结果以流式方式Transfer-Encoding: chunked追加到响应中。
流式传输Chunked Encoding将动态数据分块发送每块数据包含十六进制长度标识如A\r\n…客户端可逐步解析并渲染。
3边缘计算能力
利用CDN节点的轻量级计算能力对动态数据进行预处理如过滤、聚合减少回源请求。
客户端逐步接收静态和动态内容分阶段渲染页面如先展示导航栏再加载列表内容。
页面骨架快速呈现用户感知流畅动态内容边加载边展示减少焦虑感。
2.解决的问题
1SSR的地域延迟问题
传统SSR服务端渲染依赖中心服务器生成HTML用户与服务器的物理距离导致首屏时间TTFB较长。
ESR将页面拆分为静态内容如HTML框架、CSS和动态内容如用户数据、推荐列表由CDN边缘节点直接返回静态部分动态部分通过流式传输Transfer-Encoding: chunked逐步加载。
2动态数据回源慢
动态内容如实时推荐、用户画像需服务器查询数据库或API增加延迟。
ESR在CDN节点上缓存或预处理部分动态数据如聚合、过滤减少回源请求动态数据分块传输客户端逐步解析并渲染避免“白屏”等待。
3.本质边缘计算 流式传输
利用CDN节点的全球分布和轻量级计算能力将页面拆分为静态与动态部分通过流式传输实现“边生成边返回”优化首屏加载体验。
通过 Transfer-Encoding: chunked 实现分块响应客户端逐步接收并渲染内容。
二 增量静态再生Incremental Static Regeneration, ISR
在构建时预渲染关键页面为静态HTML其余页面按需生成或定时重建平衡实时性与构建成本。
构建阶段生成高流量页面如首页、产品列表页的静态HTML托管至CDN。
当用户请求未预渲染的页面时服务器动态生成并缓存该页面可以设置时间间隔如1小时定期更新静态页面内容。
export async function getStaticProps() {const data await fetchData();return {props: { data },revalidate: 60 // 每60秒重新生成页面};
}该模式将核心页面静态化首屏加载极快非核心页面按需或定时更新确保数据新鲜度无需全站静态化仅对高频页面预渲染降低存储和计算开销。
1.解决的问题
1SSG的静态化局限性
SSG静态站点生成在构建时预渲染所有页面为静态HTML无法实时更新动态数据如电商库存、新闻时效性。
ISR在构建时生成高流量页面的静态HTML托管至CDN加速访问然后对非核心页面按需生成或定时重建通过 revalidate 配置时间间隔确保数据新鲜度。
2构建成本与实时性的平衡
全站静态化需频繁重建资源浪费全动态渲染SSR则牺牲性能。
ISR使用混合模式核心页面静态化SSG非核心页面动态更新SSR兼顾性能与实时性。
2.本质SSG 动态更新
ISR模式结合静态生成的性能优势与动态渲染的灵活性通过后台异步更新页面内容避免全站重建。
在框架如Next.js中通过 getStaticProps 配置 revalidate 参数触发页面的增量更新。
六、技术总结
1.技术代表
Next.js支持SSR、SSG、CSR自由切换内建服务端API接口简化前后端分离开发自动压缩图片并适配设备分辨率。
Nuxt.js通过插件系统扩展功能如SEO优化、国际化默认启用SSR同时支持静态导出。
SvelteKit通过adapter-static生成纯静态文件对动态路由页面自动缓存预渲染结果。
Cloudflare Workers / Cloudflare Pages提供轻量级 JS 运行环境适合执行 ESR 中的流式 HTML 拆分逻辑。用于缓存静态片段或动态数据提高 ESR 渲染效率。结合静态托管和边缘函数构建高性能 Web 应用。可无缝配合 SSG 构建流程在部署时注入边缘逻辑。
2.各渲染模式的对比
1SSR的特点
首屏加载快直接返回 HTMLSEO 友好搜索引擎可抓取完整 HTML支持动态内容如实时数据。
服务器压力大每次请求需渲染开发复杂需处理服务器与客户端的 Hydration交互延迟需客户端“水合”页面。
2CSR的特点
交互性强SPA 动态更新无需刷新服务器负载低仅返回静态资源 前后端分离部署简单。
首屏加载慢需下载 JS 并执行 SEO 不友好需额外优化 白屏时间JS 加载期间可能空白。
3SSG的特点
性能极致静态文件可 CDN 缓存SEO 友好预生成 HTML服务器无压力无动态处理。
内容更新需重新构建除非支持 ISR动态内容支持弱需结合 API。
4ESR的特点
HTML 分块返回边缘节点直出流式传输Transfer-Encoding: chunked。
所以首屏极速加载动态内容逐步呈现减轻中心服务器负载。但是边缘逻辑复杂流式传输有兼容要求。
适合全球化电商平台、个性化推荐、高并发动态内容展示。
5ISR的特点
构建时预渲染后台异步更新可配置更新频率。
性能与更新平衡无需全站重建SEO 友好。
更新有延迟非实时数据场景。
3.关键差异总结 SSR vs ESR SSR所有内容由中心服务器动态生成受地域延迟影响大。ESR静态内容由 CDN 直出动态内容通过边缘节点流式返回TTFB≈CDN 速度。 SSG vs ISR SSG所有页面构建时静态生成无法实时更新。ISR核心页面预渲染非核心页面按需/定时更新兼顾性能与实时性。 ESR vs ISR ESR解决“首次加载延迟”问题适合动态内容实时渲染。ISR解决“静态化内容更新”问题适合大规模内容站点。 CSR 的局限性 首屏加载依赖 JS 执行SEO 和首屏性能较差但交互体验灵活。 4.SSR、CSR、SSG、ESR、ISR 对比
特性SSR服务端渲染CSR客户端渲染SSG静态站点生成ESR边缘流式渲染ISR增量静态再生HTML 生成时机请求时动态生成浏览器执行 JS 动态生成构建时静态生成边缘节点动态生成静态动态分块返回构建时静态生成 按需/定时增量更新性能服务器负载高响应时间长首屏加载慢需下载 JS后续交互快极速加载静态文件可 CDN 缓存首屏≈CDN速度动态内容流式加载核心页面 CDN 加速非核心页面按需更新SEO 友好性优秀直接返回 HTML较差需 JS 渲染优秀预生成 HTML优秀静态动态内容均返回 HTML优秀静态 HTML 动态内容可抓取动态内容支持强实时数据强完全由 JS 控制弱需结合 API 或 ISR强动态数据边缘节点实时请求中预渲染后需 API 补充支持按需更新开发复杂度高需处理服务器逻辑中前端框架即可低静态生成工具简化流程高需边缘计算配置 流式传输逻辑中需框架支持如 Next.js 的 ISR 功能服务器压力高每次请求需渲染低仅返回静态资源低无动态处理低动态请求分散到边缘节点低增量更新异步执行适用场景电商、论坛、实时数据页面SPA单页应用、内部管理系统博客、文档、企业官网全球化电商、动态推荐如用户画像匹配内容型站点博客、电商详情页、高并发场景核心优势实时数据支持SEO 友好交互流畅前后端解耦性能极致CDN 加速首屏极速加载动态内容逐步呈现平衡性能与实时性支持大规模内容更新技术实现服务器动态渲染 HTML浏览器执行 JS 构建 DOM构建工具生成静态 HTMLCDN 边缘节点拆分静态/动态内容 流式传输构建时生成 按需/定时更新 动态 API典型框架/工具Node.js、Express、Nuxt.jsReact、Vue、AngularNext.js、GatsbyCloudflare Workers、阿里云边缘计算Next.jsgetStaticProps revalidate
适用场景建议
SSR需要实时数据如电商订单、论坛评论。CSR单页应用SPA或内部系统如管理后台。SSGSEO 优先的静态内容如博客、文档。ESR全球化业务 动态内容如跨国电商推荐系统。ISR内容型站点需平衡性能与更新如新闻、商品详情页。
