SPA简单总结

• 单页应用与多页应用的区别
  • 组成 一个主页面和多个页面片段 多个主页面
• 刷新方式 局部刷新 整页刷新
• url模式 哈希模式 历史模式
• SEO搜索引擎优化 难实现，可使用SSR方式改善 容易实现
• 数据传递 容易 通过url、cookie、localStorage等传递
• 页面切换 速度快，用户体验良好 切换加载资源 速度慢，用户体验差
• 维护成本 相对容易 相对复杂
• 优点：
  • 具有桌面应用的即时性、网站的可移植性和可访问性
  • 用户体验好、快，内容的改变不需要重新加载整个页面
  • 良好的前后端分离，分工更明确
• 缺点：
  • 不利于搜索引擎的抓取
    • SSR服务端渲染：
      将组件或页面通过服务器生成html，再返回给浏览器，如nuxt.js
    • 静态化：
      （1）一种是通过程序将动态页面抓取并保存为静态页面，这样的页面的实际存在于服务器的硬盘中
      （2）另外一种是通过WEB服务器的 URL Rewrite的方式，它的原理是通过web服务器内部模块按一定规则将外部的URL请求转化为内部的文件地址，一句话来说就是把外部请求的静态地址转化为实际的动态页面地址，而静态页面实际是不存在的。
    • 使用phantomjs针对爬虫处理
      原理是通过Nginx配置，判断访问来源是否为爬虫，如果是则搜索引擎的爬虫请求会转发到一个node server，再通过PhantomJS来解析完整的HTML，返回给爬虫。
  • 首次渲染速度相对较慢
    • 原因：
      1. 网络延时问题
      2. 资源文件体积是否过大
      3. 资源是否重复发送请求去加载了
      4. 加载脚本的时候，渲染内容堵塞了
    • 解决方案
      1. 减小入口文件体积（路由懒加载）
      2. 静态资源本地缓存（后端http设置响应头缓存，前端localStorage）
      3. UI框架按需加载
      4. 图片资源的压缩
      5. 组件重复打包（在webpack的config文件中，修改CommonsChunkPlugin的配置，minChunks: 3 ，minChunks为3表示会把使用3次及以上的包抽离出来，放进公共依赖文件，避免了重复加载组件）
      6. 开启GZip压缩
      7. 使用SSR
    • 以上解决方案即为两大类：资源加载优化 和 页面渲染优化

• 实现原理
  监听地址栏中hash变化驱动界面变化
  用pushsate记录浏览器的历史，驱动界面发送变化
  SSR 技术优点：
• 更快的响应时间，相对于客户端渲染，服务端渲染在浏览器请求URL之后已经得到了一个带有数据的HTML文本，浏览器只需要解析HTML，直接构建DOM树就可以。
• 有利于 SEO ，可以将 SEO 的关键信息直接在后台就渲染成
• HTML，而保证搜索引擎的爬虫都能爬取到关键数据，然后在别人使用搜索引擎搜索相关的内容时，你的网页排行能靠得更前，这样你的流量就有越高。

缺点：

• 相对于仅仅需要提供静态文件的服务器，SSR中使用的渲染程序自然会占用更多的CPU和内存资源。
• 一些常用的浏览器API可能无法正常使用，比如window、docment和alert等，如果使用的话需要对运行的环境加以判断。
• 开发调试会有一些麻烦，因为涉及了浏览器及服务器，对于SPA的一些组件的生命周期的管理会变得复杂。
• 可能会由于某些因素导致服务器端渲染的结果与浏览器端的结果不一致。
  SSR 提高 SPA 应用的首屏响应速度，有利于 SEO 优化。
  SSR 最适用于静态展示页面，如果页面动态数据较多时需要谨慎使用。