Progress是一个轻量级的进度条组件，在Github上已经2.4万star数了，虽然这个组件已经好久没有更新了，最近一次更新是20年4月份，改了jQuery的版本，但是该组件的使用频率还是很高的。

插件安装

 $ npm install --save nprogress 
 $ yarn add nprogress

插件使用

App.vue

<script lang="ts">
import NProgress from "nprogress";
import "nprogress/nprogress.css";
import { useRouter } from "vue-router";
export default {
  setup() {
    const router=useRouter();
    router.beforeEach((to, from, next)=> {
      NProgress.start();
      next();
    });
    router.afterEach(()=> {
      NProgress.done();
    });
  },
};
</script>

axios中使用

main.ts

import 'nprogress/nprogress.css'

axios.ts

import NProgress from 'nprogress'

axios.interceptors.request.use(
  function (config: any) {
   // 在发送请求之前做某件事
    NProgress.start() //开始
    return config
  },
  (error: { data: { error: { message: any } } })=> {
    return Promise.reject(error.data.error.message)
  }
)


axios.interceptors.response.use(
  function (config: any) {
    aspShow.value=false
    NProgress.done() //结束
    if (config.status===200 || config.status===204) {
      return Promise.resolve(config)
    }
    return Promise.reject(config)
  },
  function (error: any) {
    aspShow.value=false
    NProgress.done() //结束
    if (error.response.status) {
      switch (error.response.status) {
        // 401: 未登录
        // 未登录则跳转登录页面，并携带当前页面的路径
        // 在登录成功后返回当前页面，这一步需要在登录页操作。
        case 401:
          router.replace({
            path: '/login',
            query: {}
          })
          break
       
        // 其他错误，直接抛出错误提示
        default:
          message.error(`${error.response.status}:${error.response.statusText}`)
      }
     
      NProgress.done()////结束
      return Promise.reject(error)
    }
    
  }
)

路由中使用

import NProgress from 'nprogress'

// 页面切换之前取消上一个路由中未完成的请求
router.beforeEach((_to: any, _from: any, next: ()=> void)=> {
  NProgress.start()
  next()
})
router.afterEach(()=> {
  // 进度条
  NProgress.done()
})

全局配置

//全局进度条的配置
NProgress.configure({
  easing: 'ease', // 动画方式
  speed: 1000, // 递增进度条的速度
  showSpinner: false, // 是否显示加载ico
  trickleSpeed: 200, // 自动递增间隔
  minimum: 0.3, // 更改启动时使用的最小百分比
  parent: 'body', //指定进度条的父容器
})

TS的项目，还需要安装其类型声明文件，命令如下：

npm i @types/nprogress -D

或者如下声明

declare module 'nprogress';

代前端应用逻辑日趋复杂，在平衡性能和数据实效性方面，前端也逐渐开始承担一些责任。

最近我们在项目中就碰到了这样一个场景。我们的项目只是一个非常传统的数据看板类项目，用户打开页面，通过调用API读取数据，渲染页面，完成任务。

但是这个项目有几个特点，我需要特别说明一下：

• 公司高管们每天都会使用，并且非常关注
• 高管们在手机上使用，网络条件不定
• 高管们查看数据时通常都比较焦躁

于是乎，一个本来看似简单的项目，就逐渐变成性能优化的急先锋。

version alpha

最开始我们的策略非常简单，就是给把数据存储到indexedDB中，并设置一个过期时间。整体流程如下：

关于indexedDB的初始版本代码大致包含如下几个部分

获取indexedDB链接

const TABLE_NAME='xhr_cache'
export const getDBConnection=()=> {
  const request=window.indexedDB.open(DB_NAME)
  request.onupgradeneeded=function (event) {
    const db=event.target.result
    if (!db.objectStoreNames.contains(TABLE_NAME)) {
      const table=db.createObjectStore(TABLE_NAME, {
        keyPath: 'uid'
      })
      table.createIndex('uid', 'uid', { unique: true })
    }
  }
  return new Promise((resolve, reject)=> {
    request.onsuccess=function () {
      resolve(request.result)
    }
  })
}
const dbConn=await getDBConnection()

根据request生成唯一key

import MD5 from 'crypto-js/md5'
getKey(config) {
  const hashedKey=MD5( `${config.url}_${JSON.stringify(config.payload)}` ).toString()
  return hashedKey
}

根据一个请求的URL + payload，我们可以识别一个唯一的请求。

对其值进行md5哈希之后得到一个唯一的键，代表一个请求，并将其作为存储在indexedDB中的主键。

读取数据和写入数据

/* 写入API response数据 */

const response={
  uid: key,
  content: axiosRequest.response.data,
  created_at: new Date().getTime(),
  expired: expired_at
}
const addResponseToIndexedDB=function (response) {
  dbConn
    .transaction([TABLE_NAME], 'readwrite')
    .objectStore(TABLE_NAME)
    .put(response)
}
/* 读取缓存 */
const request=dbConn
  .transaction([TABLE_NAME], 'readonly')
  .objectStore(TABLE_NAME)
  .index('uid')
  .get(key)


const result=await new Promise((resolve=> {
    request.onsuccess=function () {
        resolve(request.result)
    }
})

清除过期缓存

虽然indexedDB可以存储远大于localStorage的数据，但我们也不希望indexedDB随着用户不断访问存储大量冗余数据。因此，会在每次应用加载的开始对于过期数据统一进行一次清理：

const isExpireded=(result, expired=60000)=> {
  const now=new Date().getTime()
  const created_at=result.created_at
  return !created_at || (now - created_at > expired) ? true : false
}
const delCacheByExpireded=()=> {
  var request=dbConn
    .transaction([TABLE_NAME], 'readwrite')
    .objectStore(TABLE_NAME)
    .openCursor();
  request.onsuccess=function (e) {
    var cursor=e.target.result;
    if (cursor && cursor !==null) {
      const key=cursor.key
      const expireded=isExpireded(cursor.value)
      if (expireded) {
        that.delCacheByKey(key)
      }
      cursor.continue();
    }
  }
}

Axios Request / Response Interceptor

有了上述这些能力，我们就可以在自己的Axios拦截器中使用indexedDB的缓存数据。

axios request 拦截器

...
const CACHED_URL_REGEX=[
  'somepath/data/version/123',
  'user/info/name',
  ...
]
Axios.interceptors.request.use(async function (config) {
  const r=new Regex(`${CACHED_URL_REGEX.join('|')}$`)
  if (r.test(config.url)) {
    const key=getKey()
    const request=dbConn
      .transaction([TABLE_NAME], 'readonly')
      .objectStore(TABLE_NAME)
      .index('uid')
      .get(key)
    const result=await new Promise((resolve)=> {
      request.onsuccess=function (event) {
        resolve(request.result)
      }
      request.onerror=function (event) {
        resolve()
      }
    })
    if (result && isExpired(result)) {
      config.adapter=function (config) {
        return new Promise((resolve)=> {
          const res={
            data: result.content,
            status: 200,
            statusText: 'OK',
            headers: { 'content-type': 'text/plain; charset=utf-8' },
            config,
            request: {}
          }
          return resolve(res)
        })
      }
    }
    return config
  }
})
...

可以看到，我们在request 拦截器中进行了以下操作：

• axios request interceptor的参数中包含URL和payload属性
• 根据URL判断当前资源是否需要缓存
• 如需要缓存，则根据URL和payload信息生成唯一的key
• 根据此key去indexedDB中查找是否已有缓存
• 如有则直接构建一个response并返回
• 如没有则返回原始config，继续进行axios默认行为

注意下面这段代码

const result=await new Promise((resolve)=> {
  request.onsuccess=function (event) {
    resolve(request.result)
  }
  request.onerror=function (event) {
    resolve()
  }
})

这里的代码使用了await，以此等待indexedDB的异步查询结束。异步查询结束之后才能根据其结果判断是否要直接返回还是继续axios默认行为。

axios response 拦截器

Axios.interceptors.response.use(function (response) {
  ...
  let success=response.status < 400
  const key=getKey(response.config)
  dbConn
    .transaction([TABLE_NAME], 'readwrite')
    .objectStore(TABLE_NAME)
    .put({
      uid: key,
      content: response.data,
      created_at: new Date().getTime()
    })
  ...
  return response
}

在response拦截器中，无需等待indexedDB的异步写入过程，因此不需要使用await。

截至目前，基于Axios + indexedDB的缓存方案已经大体可用，当然以上代码并不完全，如需使用还得根据自己的项目做一些修改。

IndexedDB不够快？

上述设计方案实现之后，我们发现在读取indexedDB的时候有时会很快，但有些时候却非常慢。根据观测，在某些手机上，读取一小段不超过100K的数据，有时候需要400ms以上。根据经验这是无法理解的。

进一步调查发现，在主线程繁忙时，初始化indexedDB事务到indexedDB返回数据就会比较慢；反之，在主线程空闲时，经过测量，同一过程耗时大约在5ms以下，这才在数据库读取速度的正常认知范围之内。

但众所周知，基于react + antd的前端应用，DOM结构复杂，主线程在渲染时会非常繁忙，这就造成了我们观察到的读取indexedDB耗时较长。

说到这里，还记得上边在Axios Request Interceptor中需要先等待读取到indexedDB数据，根据结果判断是否要请求API的代码吗？

于是尴尬的一幕出现了。假设一次请求叠加了如下因素：

• 主线程正在进行大范围的DOM渲染，造成CPU繁忙
• indexedDB读取耗时从若干毫秒跳级到几百毫秒
• 读取到的数据过期，经过判断需要请求API
• 请求API耗时200ms以上

本来应该提高性能的手段，在这种条件下不仅没有节省耗时，反而会增加耗时。更进一步，在我们自己的调试过程中，发现对于某些低级手机机型，渲染初始页面时CPU本就繁忙，此时即便从本地缓存获取到的数据没有过期，耗时也可能高达无法理解的一秒左右。这种结果表示，此场景下的缓存方式显然是得不偿失的。

下表为我们针对alpha版本缓存方案在Chrome浏览器上的性能做出的统计。其中每一列分别表示在React进行初始化渲染阶段的indexedDB请求耗时。

如果将Chrome的CPU throttle调低到1/4的效率，数据则更加无法理解

与之对应的，在CPU空闲的时候，也就是初始化渲染完毕之后的indexedDB请求耗时分别为：

Version BETA

由于上一节的结论，这样的缓存策略显然无法达到本来的目的。因此我们又设计了几个方案进行对比：

• 利用serviceWorker进行数据缓存
• 在应用开始之初将indexedDB数据dump到内存，之后的取用直接通过内存缓存。根据dump的时间点，又细分为
• 在react app初始化时进行dump
• 在html script标签中使用主线程执行dump代码
• 在html script标签中使用web worker执行dump代码

其中dump数据到内存中进行缓存取用的三种细分，我们分别命名为：

• ReactAPP初始化MemCache的方案
• HTML加载时初始化MemCache的方案
• webWorker初始化MemCache的方案

策略的对比如下：

由于以上方案相对于上一节中单次indexedDB调用增加了前置dump数据到内存的操作耗时，所以我们这次对测量方案增加了TOTAL一栏，表示从html页面载入到react app完全渲染完毕的耗时。

下表中包含共5种方案的性能对比：alpha版本，serviceWorker方案，以及MemCache的三种方案。每种方案测试十次，取四个阶段以及TOTAL耗时的平均值：

• HTML开始加载到静态资源加载完成的耗时
• 初始化渲染过程中的三次indexedDB调用耗时
• TOTAL耗时

评测数据见下表（细字体的部分为正常CPU负载情况下，粗体字的部分表示CPU效率降级为1/4时的情况）：

Finally!! We have a winner

根据数据显示，对于我们的场景来说，使用webworker启动MemCache的方案是最经济的。方案设计如下图所示：

0. HTML加载时就启动WebWorker，WebWorker内部执行dump操作
1. dump完成之后通过postMessage向主线程发送dump之后的数据
2. 主线程收到数据后会将其暂存在特定全局变量上
3. APP启动之后初始化MemCache，会先判断该全局变量是否已经被赋值，若还未赋值，则会在初始化MemCache之前自行执行一次dump数据，以保证indexedDB数据已全量dump出来
4. 在这之后，与alpha版本不同，Axios的请求/响应拦截器会通过MemCache类进行缓存的查询和添加
5. MemCache类负责返回和更新缓存，并将其同步回indexedDB

WebWorker 脚本 / APP内部的dump数据脚本

由于dump数据的操作基本一致，因此WebWorker脚本和APP内部用于dump数据的lib文件内容基本一致。大体代码可见：

const DB_NAME='db_name'
const TABLE_NAME='xhr_cache'
export const getDBConnection=()=> {
  const request=window.indexedDB.open(DB_NAME)
  request.onupgradeneeded=function (event) {
    const db=event.target.result
    if (!db.objectStoreNames.contains(TABLE_NAME)) {
      const table=db.createObjectStore(TABLE_NAME, {
        keyPath: 'uid'
      })
      table.createIndex('uid', 'uid', { unique: true })
    }
  }
  return new Promise((resolve, reject)=> {
    let completed=false
    request.onsuccess=function () {
      if (completed===false) {
        completed=true
        resolve(request.result)
      } else {
        request.result.close()
      }
    }
    request.onerror=function (err) {
      if (completed===false) {
        completed=true
        reject(err)
      }
    }
    setTimeout(()=> {
      if (completed===false) {
        completed=true
        reject(new Error('getDBConnection timeout after app rendered'))
      }
    }, 1000)
  })
}
export const dump2Memory=async (db)=> {
  const transaction=db.transaction([TABLE_NAME], 'readonly')
  const table=transaction.objectStore(TABLE_NAME)
  const request=table.index('uid').getAll()
  const records=await new Promise((resolve, reject)=> {
    request.onsuccess=function () {
      resolve(request.result)
    }
    request.onerror=function () {
      console.log('dump2Memory error')
      resolve()
    }
  })
  return records
}
export const delCacheByExpireded=async (records)=> {
  const validRecords=records.filter((record)=> !getExpireded(record))
  const objectStore=DBCache.conn
    .transaction(['xhr_cache'], 'readwrite')
    .objectStore('xhr_cache')
  const clearRequest=objectStore.clear()
  clearRequest.onsuccess=function () {
    validRecords.forEach((record)=> {
      objectStore.add(record)
    })
  }
  return validRecords
}

在这里定义了三个函数

• 获取indexedDB链接的函数
• 从indexedDB中dump所有数据到内存的函数
• 对内存中的全量数据进行过期筛查的函数，其中筛查出已过期的数据进行删除操作，留下来的有效缓存再次存回到indexedDB

注意在获取indexedDB链接的函数中，相对alpha版本增加了容错处理。如果一个浏览器多个tab同时打开同一个indexedDB的链接，可能会导致后面打开的indexedDB链接被block住。因此在这里做了超时处理。

如果新的链接打开超时则不初始化内存缓存，作为降级处理方案。

于此同时，MemCache类也需要对这种降级做出兼容。

MemCache类

DBCache.conn=null

DBCache.memCache={
  __memCache: null,
  initialize: function (records) {
    this.__memCache=new Map(records.map((record)=> [record.uid, record]))
  },
  get: function (key) {
    const result=this.__memCache.get(key)
    if (result) {
      return cloneDeep(result)
    } else {
      return null
    }
  },
  add: function (record) {
    this.__memCache.set(record.uid, record)
  }
}

DBCache.prepare=async function () {
  try {
    DBCache.conn=await getDBConnection()
    let dbRecordList=[]
    if (window.__db_cache_prepared_records__.length) {
      dbRecordList=cloneDeep(window.__db_cache_prepared_records__)
    } else {
      console.time('dump')
      dbRecordList=await dump2Memory(DBCache.conn)
      console.timeEnd('dump')
    }
    const validRecords=await delCacheByExpireded(dbRecordList)
    DBCache.memCache.initialize(validRecords || [])
  } catch (err) {
    DBCache.memCache.initialize([])
    console.error(err)
  }
}

DBCache.updateRecord=(record)=> {
  if (DBCache.conn) {
    DBCache.memCache.add(record)
    DBCache.conn
      .transaction(['xhr_cache'], 'readwrite')
      .objectStore('xhr_cache')
      .put(record)
  }
}

请注意，DBCache对象的prepare静态方法中：

由于获取链接超时会抛出异常，因此在getDBConnection方法外围添加了try{}catch{}块。

如果获取DB连接发生异常，则会给MemCache初始化为空数组，这样Axios拦截器在调用DBCache.memCache.get方法时则会永远返回缓存未命中，于是所有Axios请求全部降级为API调用。

另外一个需要注意的点是，DBCache.memCache.get的方法实现中对于内存中的数据进行深拷贝的操作。原因在于，如果直接向react业务代码传递该内存块的引用，很显然业务代码会对该内存引用的对象进行修改。那么下次再使用命中的缓存时，就会因为缓存数据与API返回的数据结构不一致导致报错。

初始化WebWorker

到现在为止，几乎所有必须模块的代码都已经实现了。整个流程只剩下最后一块砖：HTML里script标签内用于启动WebWorker以及WebWorker中通知主线程的代码。

<script>
  window.__db_cache_prepared_records__=[]
  if (window.Worker) {
    console.time('dump in html')
    const dbWorker=new Worker('./webworker.dump.prepare.js');
    dbWorker.onmessage=function(e) {
      if (e.data.eventName='onDBDump') {
        if (window.__db_cache_prepared_records__.length===0)
          window.__db_cache_prepared_records__=e.data.data
        console.timeEnd('dump in html')
      }
    }      
  }
</script>

PostMessage

// other codes in dump script section. 
// I'm not gonna repeat those. see it yourself please  
...
if (indexedDB) {
  console.time('dump2Memory')
  getDBConnection().then(conn=> {
    dump2Memory(conn).then(records=> {
      console.timeEnd('dump2Memory')
      postMessage({
        eventName: 'onDBDump',
        data: records
      })
    })
  }).catch(err=> {
    console.error(err)
  })
}

结论

截至目前，我们使用Axios + indexedDB + WebWorker实现的最高效的前端API缓存方案就到此为止了。

实话实说，现在还只是搭建了一个高效缓存的框架，至于各种适合不同应用场景的缓存策略还没有实现。

如果你有有意思的缓存场景或需要何种缓存策略，欢迎留言。

务端渲染（SSR）是什么

• 渲染：HTML + CSS + JS + DATA=> 渲染后的 HTML

服务端

• 所有模板等资源都存储在服务端
• 内网机器拉取数据更快（优势）
• 一个 HTML 返回所有数据 | | 客户端渲染 | 服务端渲染 | | :--- | :---: | :---: | | 请求 | 多个请求（HTML，数据等） | 1个请求 | | 加载过程 | HTML & 数据串行加载 | 1个请求返回 HTML & 数据 | | 渲染 | 前端渲染 | 服务端渲染 | | 可交互 | 图片等静态资源加载完成，JS 逻辑执行完成可交互 | 两端一样 |

优势

• 减少白屏时间
• 对于 SEO 友好

打包存在的问题

• 浏览器的全局变量（Node.js 中没有 window，document） 组件适配：将不兼容的组件根据打包环境进行适配请求适配：推荐使用 axios
• 样式问题（Node.js 无法解析 css） 服务端打包通过 ignore-loader 忽略掉 css 的解析将 style-loader 替换成 isomorphic-style-loader使用打包出来的浏览器端 html 为模板设置占位符，动态插入组件