服务端渲染（SSR）
简述：
又称为后端渲染，服务器端在返回html之前，在html特定的区域特定的符号里用数据填充，再给客户端，客户端只负责解析HTML。
鼠标右击点击查看源码时，页面代码可以在源代码中看到。
性能消耗在服务器端，用户达到一定程度的时候，后端会考虑缓存
部分数据，避免消耗过多的资源重复渲染。
优点：
前端耗时少，首次渲染快，更快的内容到达时间
利于SEO
缺点：
网络传输数据量大，占用部分服务器运算资源
用户体验差
不容易维护，前端修改部分html/css后端也要改
客户端渲染
简述：
又称为前端渲染，起源于js的兴起，ajax让前端渲染更加成熟
前端专注于ui，后端专注于逻辑，真正意义上实现了前后端的分离
通过约定好的API来交互，后端提供数据，前端根据数据生成DOM插入HTML页面。
初次渲染大都是将原html中的数据标记{{}}替换
鼠标右击查看源码，页面代码不可以在源代码中看到
性能消耗在客户端
优点：
减少服务器压力
可以实现局部刷新，无需每次都请求完整的页面，体验更好
缺点：
前端耗时较多，首屏渲染慢，渲染前要下载一堆js和css文件
不利于SEO，爬虫看不到完整的代码
难点：
数据变更后，页面响应式变更如何节省资源？直接DOM的读写是很慢的
SPA
简述：
single page application单页面应用，只有一张Web页面的应用
加载单个html页面并在用户与应用程序交互时动态更新该页面的Web应用程序
页面初始化时加载必须的htm,js,css，所有操作都在此页面完成，通过js控制
MVVM：经典的MVVM开发模式，前后端各负其责
ajax：重前端，业务逻辑在本地操作，数据通过ajax同步提交
优点：
只需要处理#后面的字符，页面并不会重载，实现局部刷新
缺点：
不容易管理，也不够安全
不利于SEO，SEO需花费额外的功夫
预渲染
简述：
核心：prerender-spa-plugin
无需服务器实时动态编译，采用预渲染，在构建时针对特定路由简单的生成静态HTML文件
优点：
几乎可以获得服务端渲染的所有优点，没有缺点
加载应用程序的路由，将结果保存在一个静态的HTML文件中
无需更改代码或添加服务器端
缺点：
若网站有成百上千条路线，预编译会非常的慢
虽每次更新只需要一次但会需要更长的时间
适用场景：
只需改善少数页面的SEO，可以采用预渲染
// webpack配置
new PrerenderSPAPlugin({
staticDir: path.join(__dirname, 'dist'),
routes: [ '/', '/home', '/infomation', '/ticket', '/scenery', '/about' ],
renderer: new Renderer({
headless: false,
renderAfterDocumentEvent: 'render-event'
})
}),
如何选择？
1.注重SEO的新闻网站，非强交互的页面，建议采用服务器端渲染
2.对于强交互的页面，不注重SEO，采用客户端渲染
3.只需改善少数页面的SEO，采用预渲染
网友评论