原文链接: https://interview.poetries.top/docs/excellent-docs/5-%E6%B5%8F%E8%A7%88%E5%99%A8%E6%A8%A1%E5%9D%97.html

1 跨标签页通讯

不同标签页间的通讯，本质原理就是去运用一些可以 共享的中间介质，因此比较常用的有以下方法:

• 通过父页面window.open()和子页面postMessage
  • 异步下，通过 window.open('about: blank') 和 tab.location.href = '*'
• 设置同域下共享的localStorage与监听window.onstorage
  • 重复写入相同的值无法触发
  • 会受到浏览器隐身模式等的限制
• 设置共享cookie与不断轮询脏检查(setInterval)
• 借助服务端或者中间层实现

2 浏览器架构

• 用户界面
• 主进程
• 内核
  • 渲染引擎
  • JS 引擎
    • 执行栈
• 事件触发线程
  • 消息队列
    • 微任务
    • 宏任务
• 网络异步线程
• 定时器线程

3 渲染机制

3.1 浏览器的渲染机制一般分为以下几个步骤

• 处理 HTML 并构建 DOM 树。
• 处理 CSS 构建 CSSOM 树。
• 将 DOM 与 CSSOM 合并成一个渲染树。
• 根据渲染树来布局，计算每个节点的位置。
• 调用 GPU 绘制，合成图层，显示在屏幕上

• 在构建 CSSOM 树时，会阻塞渲染，直至 CSSOM 树构建完成。并且构建 CSSOM 树是一个十分消耗性能的过程，所以应该尽量保证层级扁平，减少过度层叠，越是具体的 CSS 选择器，执行速度越慢。
• css 是阻塞渲染的资源。需要将它尽早、尽快地下载到客户端，以便缩短首次渲染的时间
• 当 HTML 解析到 script 标签时，会暂停构建 DOM，完成后才会从暂停的地方重新开始。也就是说，如果你想首屏渲染的越快，就越不应该在首屏就加载 JS 文件。并且 CSS 也会影响 JS 的执行，只有当解析完样式表才会执行 JS，所以也可以认为这种情况下，CSS 也会暂停构建 DOM

3.2 图层

一般来说，可以把普通文档流看成一个图层。特定的属性可以生成一个新的图层。不同的图层渲染互不影响，所以对于某些频繁需要渲染的建议单独生成一个新图层，提高性能。但也不能生成过多的图层，会引起反作用

• 通过以下几个常用属性可以生成新图层
  • 3D变换：translate3d、translateZ
  • will-change
  • video、iframe 标签
  • 通过动画实现的 opacity 动画转换
  • position: fixed

3.3 重绘与回流

当元素的样式发生变化时，浏览器需要触发更新，重新绘制元素。这个过程中，有两种类型的操作，即重绘与回流。

• 重绘(repaint): 当元素样式的改变不影响布局时，浏览器将使用重绘对元素进行更新，此时由于只需要UI层面的重新像素绘制，因此 损耗较少
• 回流(reflow): 当元素的尺寸、结构或触发某些属性时，浏览器会重新渲染页面，称为回流。此时，浏览器需要重新经过计算，计算后还需要重新页面布局，因此是较重的操作。会触发回流的操作:

• 页面初次渲染
• 浏览器窗口大小改变
• 元素尺寸、位置、内容发生改变
• 元素字体大小变化
• 添加或者删除可见的 dom 元素
• 激活 CSS 伪类（例如：:hover）
• 查询某些属性或调用某些方法
  • clientWidth、clientHeight、clientTop、clientLeft
  • offsetWidth、offsetHeight、offsetTop、offsetLeft
  • scrollWidth、scrollHeight、scrollTop、scrollLeft
  • getComputedStyle()
  • getBoundingClientRect()
  • scrollTo()

回流必定触发重绘，重绘不一定触发回流。重绘的开销较小，回流的代价较高。

回流的优化

对树的局部甚至全局重新生成是非常耗性能的，所以要避免频繁触发回流

• 现代浏览器已经帮我们做了优化，采用队列存储多次的回流操作，然后批量执行，但获取布局信息例外，因为要获取到实时的数值，浏览器就必须要清空队列，立即执行回流。
• 编码上，避免连续多次修改，可通过合并修改，一次触发
• 减少dom的增删次数，可使用 字符串 或者 documentFragment 一次性插入
• 对于大量不同的 dom 修改，可以先将其脱离文档流，比如使用绝对定位，或者 display:none，在文档流外修改完成后再放回文档里中
• 将动画效果应用到position属性为absolute或fixed的元素上
• 动画实现的速度的选择，动画速度越快，回流次数越多，也可以选择使用 requestAnimationFrame
• 通过节流和防抖控制触发频率
• css3 硬件加速，transform、opacity、filters，开启后，会新建渲染层

另外，可以借助 DevTools Performance 面板来查看产生回流重绘任务占用主线程的情况和调用代码

开启GPU加速的方法

开启后，会将 dom元素提升为独立的渲染层，它的变化不会再影响文档流中的布局。

• transform: translateZ(0)
• opacity
• filters
• Will-change

很多人不知道的是，重绘和回流其实和Event loop 有关

• 当 Event loop 执行完 Microtasks 后，会判断 document 是否需要更新。因为浏览器是 60Hz的刷新率，每 16ms才会更新一次。
• 然后判断是否有 resize 或者 scroll ，有的话会去触发事件，所以 resize 和 scroll 事件也是至少 16ms 才会触发一次，并且自带节流功能。
• 判断是否触发了media query
• 更新动画并且发送事件
• 判断是否有全屏操作事件
• 执行 requestAnimationFrame 回调
• 执行 IntersectionObserver 回调，该方法用于判断元素是否可见，可以用于懒加载上，但是兼容性不好
• 更新界面
• 以上就是一帧中可能会做的事情。如果在一帧中有空闲时间，就会去执行 requestIdleCallback 回调

3.4 JavaScript 会阻塞 DOM 生成

JavaScript 会阻塞 DOM生成，而样式文件又会阻塞 JavaScript 的执行，所以在实际的工程中需要重点关注 JavaScript 文件和样式表文件，使用不当会影响到页面性能的

当渲染进程接收 HTML 文件字节流时，会先开启一个预解析线程，如果遇到 JavaScript 文件或者 CSS 文件，那么预解析线程会提前下载这些数据

• 如果代码里引用了外部的 CSS 文件，那么在执行 JavaScript 之前，还需要等待外部的 CSS 文件下载完成，并解析生成 CSSOM 对象之后，才能执行 JavaScript 脚本。
• 而 JavaScript 引擎在解析 JavaScript 之前，是不知道 JavaScript 是否操纵了 CSSOM 的，所以渲染引擎在遇到 JavaScript 脚本时，不管该脚本是否操纵了 CSSOM，都会执行 CSS 文件下载，解析操作，再执行 JavaScript 脚本。
• 不管 CSS 文件和 JavaScript 文件谁先到达，都要先等到 CSS 文件下载完成并生成 CSSOM，然后再执行 JavaScript 脚本，最后再继续构建 DOM，构建布局树，绘制页面

3.5 缩短白屏时长，可以有以下策略

• 通过内联 JavaScript、内联 CSS 来移除这两种类型的文件下载，这样获取到 HTML 文件之后就可以直接开始渲染流程了。
• 但并不是所有的场合都适合内联，那么还可以尽量减少文件大小，比如通过 webpack 等工具移除一些不必要的注释，并压缩 JavaScript 文件。
• 还可以将一些不需要在解析 HTML 阶段使用的 JavaScript 标记上 sync 或者 defer
• 对于大的 CSS 文件，可以通过媒体查询属性，将其拆分为多个不同用途的 CSS 文件，这样只有在特定的场景下才会加载特定的 CSS 文件。

4 跨域

因为浏览器出于安全考虑，有同源策略。也就是说，如果协议、域名、端口有一个不同就是跨域，Ajax 请求会失败。

我们可以通过以下几种常用方法解决跨域的问题

4.1 JSONP

JSONP 的原理很简单，就是利用 <script>标签没有跨域限制的漏洞。通过 <script>标签指向一个需要访问的地址并提供一个回调函数来接收数据

涉及到的端

JSONP 需要服务端和前端配合实现。

    <script src="http://domain/api?param1=a&param2=b&callback=jsonp"></script>
    <script>
        function jsonp(data) {
        	console.log(data)
    	}
    </script>    

JSONP 使用简单且兼容性不错，但是只限于get 请求

具体实现方式

• 在开发中可能会遇到多个 JSONP 请求的回调函数名是相同的，这时候就需要自己封装一个 JSONP，以下是简单实现

    function jsonp(url, jsonpCallback, success) {
      let script = document.createElement("script");
      script.src = url;
      script.async = true;
      script.type = "text/javascript";
      window[jsonpCallback] = function(data) {
        success && success(data);
      };
      document.body.appendChild(script);
    }
    jsonp(
      "http://xxx",
      "callback",
      function(value) {
        console.log(value);
      }
    );

4.2 CORS

CORS （Cross-Origin Resource Sharing，跨域资源共享） 是目前最为广泛的解决跨域问题的方案。方案依赖服务端/后端在响应头中添加 Access-Control-Allow-* 头，告知浏览器端通过此请求

涉及到的端

CORS 只需要服务端/后端支持即可，不涉及前端改动

• CORS需要浏览器和后端同时支持。IE 8 和 9 需要通过 XDomainRequest 来实现。
• 浏览器会自动进行 CORS 通信，实现CORS通信的关键是后端。只要后端实现了 CORS，就实现了跨域。
• 服务端设置 Access-Control-Allow-Origin 就可以开启 CORS。 该属性表示哪些域名可以访问资源，如果设置通配符则表示所有网站都可以访问资源。

CORS 实现起来非常方便，只需要增加一些 HTTP 头，让服务器能声明允许的访问来源

只要后端实现了 CORS，就实现了跨域

以 koa框架举例

添加中间件，直接设置Access-Control-Allow-Origin请求头

    app.use(async (ctx, next)=> {
      ctx.set('Access-Control-Allow-Origin', '*');
      ctx.set('Access-Control-Allow-Headers', 'Content-Type, Content-Length, Authorization, Accept, X-Requested-With , yourHeaderFeild');
      ctx.set('Access-Control-Allow-Methods', 'PUT, POST, GET, DELETE, OPTIONS');
      if (ctx.method == 'OPTIONS') {
        ctx.body = 200; 
      } else {
        await next();
      }
    })

具体实现方式

CORS 将请求分为简单请求（Simple Requests）和需预检请求（Preflighted requests），不同场景有不同的行为

• 简单请求 ：不会触发预检请求的称为简单请求。当请求满足以下条件时就是一个简单请求：
  • 请求方法：GET、HEAD、POST。
  • 请求头：Accept、Accept-Language、Content-Language、Content-Type。
    • Content-Type 仅支持：application/x-www-form-urlencoded、multipart/form-data、text/plain
• 需预检请求 ：当一个请求不满足以上简单请求的条件时，浏览器会自动向服务端发送一个 OPTIONS 请求，通过服务端返回的Access-Control-Allow-* 判定请求是否被允许

CORS 引入了以下几个以 Access-Control-Allow-* 开头：

• Access-Control-Allow-Origin 表示允许的来源
• Access-Control-Allow-Methods 表示允许的请求方法
• Access-Control-Allow-Headers 表示允许的请求头
• Access-Control-Allow-Credentials 表示允许携带认证信息

当请求符合响应头的这些条件时，浏览器才会发送并响应正式的请求

4.3 nginx反向代理

反向代理只需要服务端/后端支持，几乎不涉及前端改动，只用切换接口即可

nginx 配置跨域，可以为全局配置和单个代理配置(两者不能同时配置)

1. 全局配置 ，在nginx.conf文件中的 http 节点加入跨域信息

    http {
      # 跨域配置
      add_header 'Access-Control-Allow-Origin' '$http_origin' ;
      add_header 'Access-Control-Allow-Credentials' 'true' ;
      add_header 'Access-Control-Allow-Methods' 'PUT,POST,GET,DELETE,OPTIONS' ;
      add_header 'Access-Control-Allow-Headers' 'Content-Type,Content-Length,Authorization,Accept,X-Requested-With' ;
    }

2. 局部配置 （单个代理配置跨域）, 在路径匹配符中加入跨域信息

    server {
      listen       8080;
      server_name  server_name;
    
      charset utf-8;
    
      location / {
        # 这里配置单个代理跨域，跨域配置
        add_header 'Access-Control-Allow-Origin' '$http_origin' ;
        add_header 'Access-Control-Allow-Credentials' 'true' ;
        add_header 'Access-Control-Allow-Methods' 'PUT,POST,GET,DELETE,OPTIONS' ;
        add_header 'Access-Control-Allow-Headers' 'Content-Type,Content-Length,Authorization,Accept,X-Requested-With' ;
    
        #配置代理 代理到本机服务端口
        proxy_pass http://127.0.0.1:9000;
        proxy_redirect   off;
        proxy_set_header Host $host:$server_port;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      }
    }

4.4 Node 中间层接口转发

    const router = require('koa-router')()
    const rp = require('request-promise');
    
    // 通过node中间层转发实现接口跨域
    router.post('/github', async (ctx, next) => {
      let {category = 'trending',lang = 'javascript',limit,offset,period} = ctx.request.body 
      lang = lang || 'javascript'
      limit = limit || 30
      offset = offset || 0
      period = period || 'week'
      let res =  await rp({
        method: 'POST',
        // 跨域的接口
        uri: `https://e.juejin.cn/resources/github`,
        body: {
          category,
          lang,
          limit,
          offset,
          period
        },
        json: true
      })
      
      ctx.body = res
    })
    
    module.exports = router

4.5 Proxy

如果是通过vue-cli脚手架工具搭建项目，我们可以通过webpack为我们起一个本地服务器作为请求的代理对象

通过该服务器转发请求至目标服务器，得到结果再转发给前端，但是最终发布上线时如果web应用和接口服务器不在一起仍会跨域

在vue.config.js文件，新增以下代码

    module.exports = {
        devServer: {
          host: '127.0.0.1',
          port: 8080,
          open: true,// vue项目启动时自动打开浏览器
          proxy: {
            '/api': { // '/api'是代理标识，用于告诉node，url前面是/api的就是使用代理的
                target: "http://xxx.xxx.xx.xx:8080", //目标地址，一般是指后台服务器地址
                changeOrigin: true, //是否跨域
                pathRewrite: { // pathRewrite 的作用是把实际Request Url中的'/api'用""代替
                    '^/api': "" 
                }
            }
          }
        }
    }

通过axios发送请求中，配置请求的根路径

    axios.defaults.baseURL = '/api'

此外，还可通过服务端实现代理请求转发，以express框架为例

    var express = require('express');
    const proxy = require('http-proxy-middleware')
    const app = express()
    app.use(express.static(__dirname + '/'))
    app.use('/api', proxy({ target: 'http://localhost:4000', changeOrigin: false
                          }));
    module.exports = app

4.6 websocket

webSocket本身不存在跨域问题，所以我们可以利用webSocket来进行非同源之间的通信

原理：利用webSocket的API，可以直接new一个socket实例，然后通过open方法内send要传输到后台的值，也可以利用message方法接收后台传来的数据。后台是通过new WebSocket.Server({port:3000})实例，利用message接收数据，利用send向客户端发送数据。具体看以下代码：

    function socketConnect(url) {
        // 客户端与服务器进行连接
        let ws = new WebSocket(url); // 返回`WebSocket`对象，赋值给变量ws
        // 连接成功回调
        ws.onopen = e => {
          console.log('连接成功', e)
          ws.send('我发送消息给服务端'); // 客户端与服务器端通信
        }
        // 监听服务器端返回的信息
        ws.onmessage = e => {
          console.log('服务器端返回：', e.data)
          // do something
        }
        return ws; // 返回websocket对象
    }
    let wsValue = socketConnect('ws://121.40.165.18:8800'); // websocket对象

4.7 document.domain（不常用）

• 该方式只能用于二级域名相同的情况下，比如 a.test.com 和 b.test.com 适用于该方式。
• 只需要给页面添加 document.domain = 'test.com' 表示二级域名都相同就可以实现跨域
• 自 Chrome 101 版本开始，document.domain 将变为可读属性，也就是意味着上述这种跨域的方式被禁用了

4.8 postMessage（不常用）

在两个 origin 下分别部署一套页面 A 与 B，A 页面通过 iframe 加载 B 页面并监听消息，B 页面发送消息

这种方式通常用于获取嵌入页面中的第三方页面数据。一个页面发送消息，另一个页面判断来源并接收消息

    // 发送消息端
    window.parent.postMessage('message', 'http://test.com');
    // 接收消息端
    var mc = new MessageChannel();
    mc.addEventListener('message', (event) => {
        var origin = event.origin || event.originalEvent.origin;
        if (origin === 'http://test.com') {
            console.log('验证通过')
        }
    });

4.9 window.name（不常用）

主要是利用 window.name 页面跳转不改变的特性实现跨域，即 iframe 加载一个跨域页面，设置 window.name，跳转到同域页面，可以通过 $('iframe').contentWindow.name 拿到跨域页面的数据

实例说明

比如有一个www.example.com/a.html页面。需要通过a.html页面里的js来获取另一个位于不同域上的页面www.test.com/data.html中的数据。

data.html页面中设置一个window.name即可,代码如下

    <script>
      window.name = "我是data.html中设置的a页面想要的数据";
    </script>

• 那么接下来问题来了，我们怎么把data.html页面载入进来呢，显然我们不能直接在a.html页面中通过改变window.location来载入data.html页面（因为我们现在需要实现的是a.html页面不跳转,但是也能够获取到data.html中的数据）
• 具体的实现其实就是在a.html页面中使用一个隐藏的iframe来充当一个中间角色，由iframe去获取data.html的数据，然后a.html再去得到iframe获取到的数据。
• 充当中间人的iframe想要获取到data.html中通过window.name设置的数据，只要要把这个iframe的src设置为www.test.com/data.html即可,然后a.html想要得到iframe所获取到的数据，也就是想要得到iframe的widnow.name的值，还必须把这个iframe的src设置成跟a.html页面同一个域才行，不然根据同源策略，a.html是不能访问到iframe中的window.name属性的

    <!-- a.html中的代码 -->
    <iframe id="proxy" src="http://www.test.com/data.html" style="display: none;" onload = "getData()"> 
    
    <script>
      function getData(){
        var iframe = document.getElementById('proxy);
        iframe.onload = function(){
          var data = iframe.contentWindow.name;
          //上述即为获取iframe里的window.name也就是data.html页面中所设置的数据；
        }
        iframe.src = 'b.html'; //这里的b为随便的一个页面，只有与a.html同源就行，目的让a.html等访问到iframe里的东西，设置成about:blank也行
      }
    </script>

上面的代码只是最简单的原理演示代码，你可以对使用js封装上面的过程，比如动态的创建iframe,动态的注册各种事件等等，当然为了安全，获取完数据后，还可以销毁作为代理的iframe

4.10 扩展阅读

跨域与监控

前端项目在统计前端报错监控时会遇到上报的内容只有 Script Error 的问题。这个问题也是由同源策略引起。在 <script> 标签上添加 crossorigin="anonymous" 并且返回的 JS 文件响应头加上 Access-Control-Allow-Origin: * 即可捕捉到完整的错误堆栈

跨域与图片

前端项目在图片处理时可能会遇到图片绘制到 Canvas 上之后却不能读取像素或导出 base64 的问题。这个问题也是由同源策略引起。解决方式和上文相同，给图片添加 crossorigin="anonymous" 并在返回的图片文件响应头加上 Access-Control-Allow-Origin: * 即可解决

5 浏览器缓存

我们经常需要对业务中的一些数据进行存储，通常可以分为 短暂性存储 和 持久性储存。

• 短暂性的时候，我们只需要将数据存在内存中，只在运行时可用
• 持久性存储，可以分为 浏览器端 与 服务器端
  • 浏览器:
    • cookie: 通常用于存储用户身份，登录状态等
      • http 中自动携带， 体积上限为 4K， 可自行设置过期时间
    • localStorage / sessionStorage: 长久储存/窗口关闭删除， 体积限制为 4~5M
    • indexDB
  • 服务器:
    • 分布式缓存 redis
    • 数据库

提示：如果平常有遇到过缓存的坑或者很好的利用缓存，可以讲解一下自己的使用场景。如果没有使用注意过缓存问题你也可以尝试讲解一下和我们息息相关的Webpack构建（每一次构建静态资源名称的hash值都会变化），它其实就跟缓存相关

缓存分为强缓存和协商缓存。强缓存不过服务器，协商缓存需要过服务器，协商缓存返回的状态码是304。两类缓存机制可以同时存在，强缓存的优先级高于协商缓存。当执行强缓存时，如若缓存命中，则直接使用缓存数据库中的数据，不再进行缓存协商。

6.1 强缓存

Expires(HTTP1.0) ：Exprires的值为服务端返回的数据到期时间。当再次请求时的请求时间小于返回的此时间，则直接使用缓存数据。但由于服务端时间和客户端时间可能有误差，这也将导致缓存命中的误差。另一方面，Expires是HTTP1.0的产物，故现在大多数使用Cache- Control替代

缺点：使用的是绝对时间，如果服务端和客户端的时间产生偏差，那么会导致命中缓存产生偏差。

Cache-Control(HTTP1.1) ：有很多属性，不同的属性代表的意义也不同

• private：客户端可以缓存
• public：客户端和代理服务器都可以缓存
• max-age=t：缓存内容将在t秒后失效
• no-cache：需要使用协商缓存来验证缓存数据，可以在客户端存储资源，每次都必须去服务端做新鲜度校验，来决定从服务端获取新的资源（200）还是使用客户端缓存（304）
• no-store：所有内容都不会缓存，永远都不要在客户端存储资源，永远都去原始服务器去获取资源

请注意no-cache指令很多人误以为是不缓存，这是不准确的，no-cache的意思是可以缓存，但每次用应该去向服务器验证缓存是否可用。no- store才是不缓存内容。当在首部字段Cache-Control 有指定 max-age 指令时，比起首部字段 Expires，会优先处理 max-age 指令。命中强缓存的表现形式：Firefox浏览器表现为一个灰色的200状态码。Chrome浏览器状态码表现为200 (from disk cache)或是200 OK (from memory cache)

6.2 协商缓存（对比缓存）

协商缓存需要进行对比判断是否可以使用缓存。浏览器第一次请求数据时，服务器会将缓存标识与数据一起响应给客户端，客户端将它们备份至缓存中。再次请求时，客户端会将缓存中的标识发送给服务器，服务器根据此标识判断。若未失效，返回304状态码，浏览器拿到此状态码就可以直接使用缓存数据了

• Last-Modified：服务器在响应请求时，会告诉浏览器资源的最后修改时间
• if-Modified-Since：浏览器再次请求服务器的时候，请求头会包含此字段，后面跟着在缓存中获得的最后修改时间。服务端收到此请求头发现有if-Modified-Since，则与被请求资源的最后修改时间进行对比，如果一致则返回304和响应报文头，浏览器只需要从缓存中获取信息即可
• 如果真的被修改：那么开始传输响应一个整体，服务器返回：200 OK
• 如果没有被修改：那么只需传输响应header，服务器返回：304 Not Modified
• Etag：服务器响应请求时，通过此字段告诉浏览器当前资源在服务器生成的唯一标识（生成规则由服务器决定）
• If-Match：条件请求，携带上一次请求中资源的ETag，服务器根据这个字段判断文件是否有新的修改
• If-None-Match： 再次请求服务器时，浏览器的请求报文头部会包含此字段，后面的值为在缓存中获取的标识。服务器接收到次报文后发现If-None-Match则与被请求资源的唯一标识进行对比。

但是实际应用中由于Etag的计算是使用算法来得出的，而算法会占用服务端计算的资源，所有服务端的资源都是宝贵的，所以就很少使用Etag了

• 浏览器地址栏中写入URL，回车浏览器发现缓存中有这个文件了，不用继续请求了，直接去缓存拿（最快）
• F5就是告诉浏览器，别偷懒，好歹去服务器看看这个文件是否有过期了。于是浏览器就胆胆襟襟的发送一个请求带上If-Modify-since
• Ctrl+F5告诉浏览器，你先把你缓存中的这个文件给我删了，然后再去服务器请求个完整的资源文件下来。于是客户端就完成了强行更新的操作

总结

• 服务端判断客户端资源，是否和服务端资源一样。
• 一致则返回 304，否则返回 200 和最新的资源

资源标识：

• 在 Response Headers 中，有两种。
• Last-Modified：资源的最后修改时间。
• Etag：资源的唯一标识（一个字符串，类似于人类的指纹）

服务端拿到 if-Modified-Since 之后拿这个时间去和服务端资源最后修改时间做比较，如果一致则返回 304 ，不一致（也就是资源已经更新了）就返回 200 和新的资源及新的 Last-Modified

其实 Etag 和 Last-Modified 一样的，只不过 Etag 是服务端对资源按照一定方式（比如 contenthash）计算出来的唯一标识，就像人类指纹一样，传给客户端之后，客户端再传过来时候，服务端会将其与现在的资源计算出来的唯一标识做比较，一致则返回 304，不一致就返回 200 和新的资源及新的 Etag

两者比较：

• 优先使用 Etag。
• Last-Modified 只能精确到秒级。
• 如果资源被重复生成，而内容不变，则 Etag 更精确。

三种刷新操作对 http 缓存的影响

• 正常操作：地址栏输入 url，跳转链接，前进后退等
• 手动刷新：f5，点击刷新按钮，右键菜单刷新
• 强制刷新：ctrl + f5，shift+command+r

• 正常操作 ：强制缓存有效，协商缓存有效
• 手动刷新 ：强制缓存失效，协商缓存有效
• 强制刷新 ：强制缓存失效，协商缓存失效

6.3 缓存场景

对于大部分的场景都可以使用强缓存配合协商缓存解决，但是在一些特殊的地方可能需要选择特殊的缓存策

• 对于某些不需要缓存的资源，可以使用 Cache-control: no-store ，表示该资源不需要缓存
• 对于频繁变动的资源，可以使用 Cache-Control: no-cache 并配合 ETag 使用，表示该资源已被缓存，但是每次都会发送请求询问资源是否更新
• 对于代码文件来说，通常使用 Cache-Control: max-age=31536000 并配合策略缓存使用，然后对文件进行指纹处理，一旦文件名变动就会立刻下载新的文件

6.4 讲讲304

如果客户端发送了一个带条件的 GET 请求且该请求已被允许，而文档的内容(自上次访问以来或者根据请求的条件)并没有改变，则服务器应当返回这个 304 状态码

6.5 强缓存、协商缓存什么时候用哪个

因为服务器上的资源不是一直固定不变的，大多数情况下它会更新，这个时候如果我们 还访问本地缓存，那么对用户来说，那就相当于资源没有更新，用户看到的还是旧的资 源;所以我们希望服务器上的资源更新了浏览器就请求新的资源，没有更新就使用本地 的缓存，以最大程度的减少因网络请求而产生的资源浪费。

6.6 缓存总结

缓存分为两种:强缓存和协商缓存，根据响应的 header 内容来决定。

| 获取资源形式 | 状态码 | 发送请求到服务器
---|---|---|---
强缓存 | 从缓存取 | 200(from cache) | 否，直接从缓存取
协商缓存 | 从缓存取 | 304(not modified) | 是，通过服务器来告知缓存是否可 用

• 强缓存相关字段有 expires，cache-control。如果 cache-control 与 expires 同时存在的话， cache-control 的优先级高于 expires。
• 协商缓存相关字段有 Last-Modified/If-Modified-Since，Etag/If-None-Match

6.7 cookie和localSrorage、session、indexDB 的区别

特性	cookie	localStorage	sessionStorage	indexDB
数据生命周期	一般由服务器生成，可以设置过期时间	除非被清理，否则一直存在	页面关闭就清理	除非被清理，否则一直存在
数据存储大小	4K	5M	5M	无限
与服务端通信	每次都会携带在 header 中，对于请求性能影响	不参与	不参与	不参与

从上表可以看到，cookie 已经不建议用于存储。如果没有大量数据存储需求的话，可以使用 localStorage和 sessionStorage 。对于不怎么改变的数据尽量使用 localStorage 存储，否则可以用 sessionStorage 存储。

对于cookie，我们还需要注意安全性

属性	作用
value	如果用于保存用户登录态，应该将该值加密，不能使用明文的用户标识
http-only	不能通过 JS访问 Cookie，减少 XSS攻击
secure	只能在协议为 HTTPS 的请求中携带
same-site	规定浏览器不能在跨域请求中携带 Cookie，减少 CSRF 攻击

6.8 什么是 Cookie

• HTTP 是无状态的协议 （对于事务处理没有记忆能力，每次客户端和服务端会话完成时，服务端不会保存任何会话信息）：每个请求都是完全独立的，服务端无法确认当前访问者的身份信息，无法分辨上一次的请求发送者和这一次的发送者是不是同一个人。所以服务器与浏览器为了进行会话跟踪（知道是谁在访问我），就必须主动的去维护一个状态，这个状态用于告知服务端前后两个请求是否来自同一浏览器。而这个状态需要通过 cookie 或者 session 去实现
• cookie 存储在客户端 ： cookie 是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上
• cookie 是不可跨域的 ： 每个 cookie 都会绑定单一的域名，无法在别的域名下获取使用，一级域名和二级域名之间是允许共享使用的 （靠的是 domain）

属性	说明
name=value	键值对，设置 Cookie 的名称及相对应的值，都必须是字符串类型。如果值为 Unicode 字符，需要为字符编码。如果值为二进制数据，则需要使用 BASE64 编码。
domain	指定 cookie 所属域名，默认是当前域名
path	指定 cookie 在哪个路径（路由）下生效，默认是 '/'。如果设置为 /abc，则只有 /abc 下的路由可以访问到该 cookie，如：/abc/read。
maxAge	cookie 失效的时间，单位秒。如果为整数，则该 cookie 在 maxAge 秒后失效。如果为负数，该 cookie 为临时 cookie ，关闭浏览器即失效，浏览器也不会以任何形式保存该 cookie 。如果为 0，表示删除该 cookie 。默认为 -1。- 比 expires 好用。
expires	过期时间，在设置的某个时间点后该 cookie 就会失效。一般浏览器的 cookie 都是默认储存的，当关闭浏览器结束这个会话的时候，这个 cookie 也就会被删除
secure	该 cookie 是否仅被使用安全协议传输。安全协议有 HTTPS，SSL等，在网络上传输数据之前先将数据加密。默认为false。当 secure 值为 true 时，cookie 在 HTTP 中是无效，在 HTTPS 中才有效
httpOnly	如果给某个 cookie 设置了 httpOnly 属性，则无法通过 JS 脚本 读取到该 cookie 的信息，但还是能通过 Application 中手动修改 cookie，所以只是在一定程度上可以防止 XSS 攻击，不是绝对的安全

6.9 什么是 Session

• session 是另一种记录服务器和客户端会话状态的机制
• session 是基于 cookie 实现的，session 存储在服务器端，sessionId 会被存储到客户端的cookie 中

session 认证流程：

• 用户第一次请求服务器的时候，服务器根据用户提交的相关信息，创建对应的 Session
• 请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器
• 浏览器接收到服务器返回的 SessionID 信息后，会将此信息存入到 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名
• 当用户第二次访问服务器的时候，请求会自动判断此域名下是否存在 Cookie 信息，如果存在自动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的 Session 信息，如果没有找到说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面操作。

根据以上流程可知，SessionID 是连接 Cookie 和 Session 的一道桥梁，大部分系统也是根据此原理来验证用户登录状态。

6.10 Cookie 和 Session 的区别

• 安全性 ： Session 比 Cookie 安全，Session 是存储在服务器端的，Cookie 是存储在客户端的。
• 存取值的类型不同 ：Cookie 只支持存字符串数据，想要设置其他类型的数据，需要将其转换成字符串，Session 可以存任意数据类型。
• 有效期不同 ： Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭（默认情况下）或者 Session 超时都会失效。
• 存储大小不同 ： 单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie，但是当访问量过多，会占用过多的服务器资源。

6 内存泄露

• 意外的全局变量: 无法被回收
• 定时器: 未被正确关闭，导致所引用的外部变量无法被释放
• 事件监听: 没有正确销毁 (低版本浏览器可能出现)
• 闭包: 会导致父级中的变量无法被释放
• dom 引用: dom 元素被删除时，内存中的引用未被正确清空

可用 chrome 中的 timeline 进行内存标记，可视化查看内存的变化情况，找出异常点。

7 浏览器API

7.1 Web Worker

现代浏览器为JavaScript创造的 多线程环境。可以新建并将部分任务分配到worker线程并行运行，两个线程可 独立运行，互不干扰，可通过自带的 消息机制 相互通信。

基本用法:

    // 创建 worker
    const worker = new Worker('work.js');
    
    // 向主进程推送消息
    worker.postMessage('Hello World');
    
    // 监听主进程来的消息
    worker.onmessage = function (event) {
      console.log('Received message ' + event.data);
    }

限制:

• 同源限制
• 无法使用 document / window / alert / confirm
• 无法加载本地资源

7.2 Service Worker

service worker

Service workers 本质上充当Web应用程序与浏览器之间的代理服务器，也可以在网络可用时作为浏览器和网络间的代理。它们旨在（除其他之外）使得能够创建有效的离线体验，拦截网络请求并基于网络是否可用以及更新的资源是否驻留在服务器上来采取适当的动作。他们还允许访问推送通知和后台同步API

目前该技术通常用来做缓存文件，提高首屏速度

    // index.js
    if (navigator.serviceWorker) {
      navigator.serviceWorker
        .register("sw.js")
        .then(function(registration) {
          console.log("service worker 注册成功");
        })
        .catch(function(err) {
          console.log("servcie worker 注册失败");
        });
    }
    // sw.js
    // 监听 `install` 事件，回调中缓存所需文件
    self.addEventListener("install", e => {
      e.waitUntil(
        caches.open("my-cache").then(function(cache) {
          return cache.addAll(["./index.html", "./index.js"]);
        })
      );
    });
    
    // 拦截所有请求事件
    // 如果缓存中已经有请求的数据就直接用缓存，否则去请求数据
    self.addEventListener("fetch", e => {
      e.respondWith(
        caches.match(e.request).then(function(response) {
          if (response) {
            return response;
          }
          console.log("fetch source");
        })
      );
    });

打开页面，可以在开发者工具中的 Application 看到 Service Worker 已经启动了

在 Cache 中也可以发现我们所需的文件已被缓存

当我们重新刷新页面可以发现我们缓存的数据是从 Service Worker 中读取的

7.3 requestAnimationFrame用法

在Web应用中，实现动画效果的方法比较多，Javascript 中可以通过定时器 setTimeout 来实现，css3 可以使用 transition 和 animation 来实现，html5 中的 canvas 也可以实现。除此之外，html5 还提供一个专门用于请求动画的API，那就是 requestAnimationFrame，顾名思义就是请求动画帧

1.页面可见

当页面被最小化或者被切换成后台标签页时，页面为不可见，浏览器会触发一个 visibilitychange事件,并设置document.hidden属性为true；切换到显示状态时，页面为可见，也同样触发一个 visibilitychange 事件，设置document.hidden属性为false

2.动画帧请求回调函数列表

每个Document都有一个动画帧请求回调函数列表，该列表可以看成是由<handlerId, callback>元组组成的集合。其中handlerId是一个整数，唯一地标识了元组在列表中的位置；callback是回调函数

3.屏幕刷新频率

即图像在屏幕上更新的速度，也即屏幕上的图像每秒钟出现的次数，它的单位是赫兹(Hz)。 对于一般笔记本电脑，这个频率大概是60Hz， 这个值的设定受屏幕分辨率、屏幕尺寸和显卡的影响

4.动画原理

根据上面的原理我们知道，你眼前所看到图像正在以每秒60次的频率刷新，由于刷新频率很高，因此你感觉不到它在刷新。而动画本质就是要让人眼看到图像被刷新而引起变化的视觉效果，这个变化要以连贯的、平滑的方式进行过渡。 那怎么样才能做到这种效果呢

刷新频率为60Hz的屏幕每16.7ms刷新一次，我们在屏幕每次刷新前，将图像的位置向左移动一个像素，即1px。这样一来，屏幕每次刷出来的图像位置都比前一个要差1px，因此你会看到图像在移动；由于我们人眼的视觉停留效应，当前位置的图像停留在大脑的印象还没消失，紧接着图像又被移到了下一个位置，因此你才会看到图像在流畅的移动，这就是视觉效果上形成的动画

5.requestAnimationFrame用法

异步，传入的函数在重绘之前调用

1. 写法：handlerId = requestAnimationFrame(callback)

• 传入一个callback函数，即动画函数
• 返回值handlerId为浏览器定义的、大于0的整数，唯一标识了该回调函数在列表中位置

2. 浏览器执行过程

• 首先要判断document.hidden属性是否为true,即页面处于可见状态下才会执行
• 浏览器清空上一轮的动画函数
• 这个方法返回的handlerId 值会和动画函数callback，以<handlerId , callback> 进入到动画帧请求回调函数列
• 浏览器会遍历动画帧请求回调函数列表，根据handlerId 的值大小，依次去执行相应的动画函数

3. 取消动画函数的方法

    cancelAnimationFrame(handlerId)

6.与setTimeout对比

理解了上面的概念以后，我们不难发现，setTimeout 其实就是通过设置一个间隔时间来不断的改变图像的位置，从而达到动画效果的。但利用seTimeout实现的动画在某些低端机上会出现卡顿、抖动的现象。 这种现象的产生有两个原因

• setTimeout的执行时间并不是确定的。在Javascript中， setTimeout 任务被放进了异步队列中，只有当主线程上的任务执行完以后，才会去检查该队列里的任务是否需要开始执行，因此 setTimeout 的实际执行时间一般要比其设定的时间晚一些
• 刷新频率受屏幕分辨率和屏幕尺寸的影响，因此不同设备的屏幕刷新频率可能会不同，而 setTimeout只能设置一个固定的时间间隔，这个时间不一定和屏幕的刷新时间相同。

以上两种情况都会导致setTimeout的执行步调和屏幕的刷新步调不一致，从而引起丢帧现象。 那为什么步调不一致就会引起丢帧呢

首先要明白，setTimeout的执行只是在内存中对图像属性进行改变，这个变化必须要等到屏幕下次刷新时才会被更新到屏幕上。如果两者的步调不一致，就可能会导致中间某一帧的操作被跨越过去，而直接更新下一帧的图像。假设屏幕每隔16.7ms刷新一次，而setTimeout每隔10ms设置图像向左移动1px， 就会出现如下绘制过程：

• 第0ms: 屏幕未刷新，等待中，setTimeout也未执行，等待中；
• 第10ms: 屏幕未刷新，等待中，setTimeout开始执行并设置图像属性left=1px；
• 第16.7ms: 屏幕开始刷新，屏幕上的图像向左移动了1px， setTimeout 未执行，继续等待中；
• 第20ms: 屏幕未刷新，等待中，setTimeout开始执行并设置left=2px;
• 第30ms: 屏幕未刷新，等待中，setTimeout开始执行并设置left=3px;
• 第33.4ms: 屏幕开始刷新，屏幕上的图像向左移动了3px， setTimeout未执行，继续等待中； …

从上面的绘制过程中可以看出，屏幕没有更新left=2px的那一帧画面，图像直接从1px的位置跳到了3px的的位置，这就是丢帧现象，这种现象就会引起动画卡顿

与setTimeout相比，requestAnimationFrame最大的优势是由系统来决定回调函数的执行时机。具体一点讲，如果屏幕刷新率是60Hz,那么回调函数就每16.7ms被执行一次，如果刷新率是75Hz，那么这个时间间隔就变成了1000/75=13.3ms，换句话说就是，requestAnimationFrame的步伐跟着系统的刷新步伐走。它能保证回调函数在屏幕每一次的刷新间隔中只被执行一次，这样就不会引起丢帧现象，也不会导致动画出现卡顿的问题。

    var progress = 0;
    //回调函数
    function render() {  
      progress += 1; //修改图像的位置  
      if (progress < 100) {  //在动画没有结束前，递归渲染    
        window.requestAnimationFrame(render); 
      }
    }
    //第一帧渲染
    window.requestAnimationFrame(render)

除此之外，requestAnimationFrame还有以下两个优势

• CPU节能：使用setTimeout实现的动画，当页面被隐藏或最小化时，setTimeout 仍然在后台执行动画任务，由于此时页面处于不可见或不可用状态，刷新动画是没有意义的，完全是浪费CPU资源。而requestAnimationFrame则完全不同，当页面处理未激活的状态下，该页面的屏幕刷新任务也会被系统暂停，因此跟着系统步伐走的requestAnimationFrame也会停止渲染，当页面被激活时，动画就从上次停留的地方继续执行，有效节省了CPU开销
• 函数节流：在高频率事件(resize,scroll等)中，为了防止在一个刷新间隔内发生多次函数执行，使用requestAnimationFrame可保证每个刷新间隔内，函数只被执行一次，这样既能保证流畅性，也能更好的节省函数执行的开销。一个刷新间隔内函数执行多次时没有意义的，因为显示器每16.7ms刷新一次，多次绘制并不会在屏幕上体现出来

7.优雅降级

由于requestAnimationFrame目前还存在兼容性问题，而且不同的浏览器还需要带不同的前缀。因此需要通过优雅降级的方式对requestAnimationFrame进行封装，优先使用高级特性，然后再根据不同浏览器的情况进行回退，直至只能使用setTimeout的情况。下面的代码就是有人在github上提供的polyfill，详细介绍请参考github代码 requestAnimationFrame (opens new window)

    if (!Date.now)
        Date.now = function() { return new Date().getTime(); };
     
    (function() {
        'use strict';
         
        var vendors = ['webkit', 'moz'];
        for (var i = 0; i < vendors.length && !window.requestAnimationFrame; ++i) {
            var vp = vendors[i];
            window.requestAnimationFrame = window[vp+'RequestAnimationFrame'];
            window.cancelAnimationFrame = (window[vp+'CancelAnimationFrame']
                                       || window[vp+'CancelRequestAnimationFrame']);
        }
        if (/iP(ad|hone|od).*OS 6/.test(window.navigator.userAgent) // iOS6 is buggy
            || !window.requestAnimationFrame || !window.cancelAnimationFrame) {
            var lastTime = 0;
            window.requestAnimationFrame = function(callback) {
                var now = Date.now();
                var nextTime = Math.max(lastTime + 16, now);
                return setTimeout(function() { callback(lastTime = nextTime); },
                                  nextTime - now);
            };
            window.cancelAnimationFrame = clearTimeout;
        }
    }())

8 页面加载执行

8.1 浏览器事件循环

事件循环是指: 执行一个宏任务，然后执行清空微任务列表，循环再执行宏任务，再清微任务列表

• 微任务 microtask(jobs): promise / process.nextTick / MutationObserver
• 宏任务 macrotask(task): setTimout / setInterval / setImmediate / script / IO / UI Rendering

宏任务中包括了 script ，浏览器会先执行一个宏任务，接下来有异步代码的话就先执行微任务

8.2 怎么判断页面是否加载完成

• Load 事件触发代表页面中的 DOM，CSS，JS，图片已经全部加载完毕。
• DOMContentLoaded 事件触发代表初始的 HTML 被完全加载和解析，不需要等待 CSS，JS，图片加载

8.3 css 加载会造成阻塞吗 ？

• DOM 和 CSSOM 通常是并行构建的,所以 CSS 加载不会阻塞 DOM 的解析。
• 然而,由于 Render Tree 是依赖于 DOM Tree 和 CSSOM Tree 的,
• 所以他必须等待到 CSSOM Tree 构建完成,也就是 CSS 资源加载完成(或者 CSS 资源加载失败)后,才能开始渲染。
• 因此,CSS 加载会阻塞 Dom 的渲染。
• 由于 JavaScript 是可操纵 DOM 和 css 样式的,如果在修改这些元素属性同时渲染界面（即 JavaScript 线程和 UI线程同时运行）,那么渲染线程前后获得的元素数据就可能不一致了。
• 因此为了防止渲染出现不可预期的结果,浏览器设置 GUI 渲染线程与 JavaScript 引擎为互斥的关系。因此,样式表会在后面的 js 执行前先加载执行完毕,所以css 会阻塞后面 js 的执行

8.4 为什么 JS 阻塞页面加载 ?

• 由于 JavaScript 是可操纵 DOM 的,如果在修改这些元素属性同时渲染界面（即 JavaScript 线程和 UI 线程同时运行）,那么渲染线程前后获得的元素数据就可能不一致了
• 因此为了防止渲染出现不可预期的结果,浏览器设置 GUI 渲染线程与 JavaScript 引擎为互斥的关系
• 当 JavaScript 引擎执行时 GUI 线程会被挂起,GUI 更新会被保存在一个队列中等到引擎线程空闲时立即被执行
• 从上面我们可以推理出,由于 GUI 渲染线程与 JavaScript 执行线程是互斥的关系,
• 当浏览器在执行 JavaScript 程序的时候,GUI 渲染线程会被保存在一个队列中,直到 JS 程序执行完成,才会接着执行
• 因此如果 JS执行的时间过长,这样就会造成页面的渲染不连贯,导致页面渲染加载阻塞的感觉

8.5 DOMContentLoaded 与 load 的区别 ?

• 当 DOMContentLoaded 事件触发时,仅当 DOM 解析完成后,不包括样式表,图片。我们前面提到 CSS 加载会阻塞 Dom 的渲染和后面 js 的执行,js 会阻塞 Dom 解析,所以我们可以得到结论:
• 当文档中没有脚本时,浏览器解析完文档便能触发 DOMContentLoaded 事件。如果文档中包含脚本,则脚本会阻塞文档的解析,而脚本需要等 CSSOM 构建完成才能执行。在任何情况下,DOMContentLoaded 的触发不需要等待图片等其他资源加载完成
• 当 onload 事件触发时,页面上所有的 DOM,样式表,脚本,图片等资源已经加载完毕
• DOMContentLoaded -> load

8.6 什么是 CRP,即关键渲染路径? 如何优化

关键渲染路径是浏览器将 HTML CSS JavaScript 转换为在屏幕上呈现的像素内容所经历的一系列步骤。也就是我们上面说的浏览器渲染流程 。

为尽快完成首次渲染,我们需要最大限度减小以下三种可变因素:

• 关键资源的数量: 可能阻止网页首次渲染的资源。
• 关键路径长度: 获取所有关键资源所需的往返次数或总时间。
• 关键字节: 实现网页首次渲染所需的总字节数,等同于所有关键资源传送文件大小的总和

1. 优化 DOM

• 删除不必要的代码和注释包括空格,尽量做到最小化文件。
• 可以利用 GZIP 压缩文件。
• 结合 HTTP 缓存文件

2. 优化 CSSOM

缩小、压缩以及缓存同样重要,对于 CSSOM 我们前面重点提过了它会阻止页面呈现,因此我们可以从这方面考虑去优化。

• 减少关键 CSS 元素数量
• 当我们声明样式表时,请密切关注媒体查询的类型,它们极大地影响了 CRP 的性能

3. 优化 JavaScript

当浏览器遇到 script标记时,会阻止解析器继续操作,直到 CSSOM 构建完毕,JavaScript 才会运行并继续完成 DOM 构建过程。

• async: 当我们在 script 标记添加 async 属性以后,浏览器遇到这个 script 标记时会继续解析 DOM,同时脚本也不会被 CSSOM 阻止,即不会阻止 CRP。
• defer: 与 async 的区别在于,脚本需要等到文档解析后（ DOMContentLoaded 事件前）执行,而 async 允许脚本在文档解析时位于后台运行（两者下载的过程不会阻塞 DOM,但执行会）
• 当我们的脚本不会修改 DOM 或 CSSOM 时,推荐使用 async
• 预加载 —— preload & prefetch
• DNS 预解析 —— dns-prefetch

总结

• 分析并用 关键资源数 关键字节数 关键路径长度 来描述我们的 CRP
• 最小化关键资源数:消除它们（内联）、推迟它们的下载（defer）或者使它们异步解析（async）等
• 优化关键字节数（缩小、压缩）来减少下载时间 优化加载剩余关键资源的顺序:
• 让关键资源（CSS）尽早下载以减少 CRP 长度

9 history路由和hash路由

hash 路由

hash 路由，在 html5 前，为了解决单页路由跳转问题采用的方案， hash 的变化不会触发页面渲染，服务端也无法获取到 hash 值，前端可通过监听 hashchange 事件来处理hash值的变化

    window.addEventListener('hashchange', function(){ 
        // 监听hash变化，点击浏览器的前进后退会触发
    })

history 路由

history 路由，是 html5 的规范，提供了对history栈中内容的操作，常用api有：

    window.history.pushState(state, title, url) 
    // let currentState = history.state; 获取当前state
    // state：需要保存的数据，这个数据在触发popstate事件时，可以在event.state里获取
    // title：标题，基本没用，一般传 null
    // url：设定新的历史记录的 url。新的 url 与当前 url 的 origin 必须是一樣的，否则会抛出错误。url可以是绝对路径，也可以是相对路径。
    //如 当前url是 https://www.baidu.com/a/,执行history.pushState(null, null, './qq/')，则变成 https://www.baidu.com/a/qq/，
    //执行history.pushState(null, null, '/qq/')，则变成 https://www.baidu.com/qq/
    
    window.history.replaceState(state, title, url)
    // 与 pushState 基本相同，但她是修改当前历史记录，而 pushState 是创建新的历史记录
    
    window.addEventListener("popstate", function() {
        // 监听浏览器前进后退事件，pushState 与 replaceState 方法不会触发              
    });

10 performance相关

window.performance.getEntries()

浏览器获取网页时，会对网页中每一个对象（脚本文件、样式表、图片文件等等）发出一个HTTP请求。而通过window.performance.getEntries方法，则可以以数组形式，返回这些请求的时间统计信息，每个数组成员均是一个PerformanceResourceTiming对象！

用它小玩儿一下，统计页面上的静态资源加载耗时：

    (function () {
        // 浏览器不支持，就算了！
        if (!window.performance && !window.performance.getEntries) {
            return false;
        }
    
        var result = [];
        // 获取当前页面所有请求对应的PerformanceResourceTiming对象进行分析
        window.performance.getEntries().forEach(function (perf) {
            result.push({
                'url': perf.name,
                'entryType': perf.entryType,
                'type': perf.initiatorType,
                'duration(ms)': perf.duration
            });
        });
    
        // 控制台输出统计结果
        console.table(result);
    })();

阅读全文