前段时间项目中遇到性能相关的问题，用户反馈网页首屏加载时间过慢，操作点击反应迟钝，组内优化了一个星期，终于改善了很多，总结了几个比较重要的点
一、减少HTTP请求
改善响应时间最简单的途径就是减少HTTP请求的数量。
项目在首页的时候加载了太多的接口，真正的接口其实是有利有弊的，我们项目是react+redux的，首页加载的时候，把一些数据存在store里，后面直接从store里拿就行了，我们主要把一些使用量小的接口去掉，在用的时候再去请求接口。
另外一个就是图片合并，减少HTTP请求，假设导航栏上有五幅图片，点击每张图片都会进入一个链接，这样五张导航的图片在加载时会产生5个HTTP请求。然而，使用一个图片地图可以提高效率，这样就只需要一个HTTP请求。但是有些小的图片是直接打包到js文件中的，这个时候就不需要合并图片了，需要的话可以使用webpack中的插件webpack-spritesmith，详细可查看https://github.com/mixtur/webpack-spritesmith。
二、使用CDN
如果应用程序web服务器离用户更近，那么一个HTTP请求的响应时间将缩短。另一方面，如果组件web服务器离用户更近，则多个HTTP请求的响应时间将缩短。
CDN（内容发布网络）是一组分布在多个不同地理位置的Web服务器，用于更加有效地向用户发布内容。在优化性能时，向特定用户发布内容的服务器的选择基于对网络慕课拥堵的测量。例如，CDN可能选择网络阶跃数最小的服务器，或者具有最短响应时间的服务器。
CDN还可以进行数据备份、扩展存储能力，进行缓存，同时有助于缓和Web流量峰值压力。
CDN的缺点：
1、响应时间可能会受到其他网站流量的影响。CDN服务提供商在其所有客户之间共享Web服务器组。
2、如果CDN服务质量下降了，那么你的工作质量也将下降
3、无法直接控制组件服务器
在我们项目中应用的是将前端静态资源，拷贝到一个文件中，放到CDN服务中，在index.html中更改文件的引用。
因为我们CDN是测试环境没办法访问，就配置了两个入口， webpack里的默认配置是index.html, 在development模式下，配置start.html去覆盖默认的文件。
new HtmlWebpackPlugin({
template: `${__dirname}/html/index.html`, //源html
inject: 'body', //注入到哪里
filename: 'index.html', //输出后的名称
hash: true, //为静态资源生成hash值
showErrors:true,
}),development: [].concat(
new HtmlWebpackPlugin({
template: `${__dirname}/html/start.html`, //源html
inject: 'body', //注入到哪里
filename: 'index.html', //输出后的名称
hash: true, //为静态资源生成hash值
showErrors:true,
}),...})三、将样式表放在头部 js文件放在底部
这两个对于实际页面加载的时间并不能造成太大影响，但是这会减少页面首屏出现的时间，使页面内容逐步呈现，改善用户体验，防止“白屏”。
我们总是希望页面能够尽快显示内容，为用户提供可视化的回馈，这对网速慢的用户来说是很重要的。
将样式表放在文档底部会阻止浏览器中的内容逐步出现。为了避免当样式变化时重绘页面元素，浏览器会阻塞内容逐步呈现，造成“白屏”。这源自浏览器的行为：如果样式表仍在加载，构建呈现树就是一种浪费，因为所有样式表加载解析完毕之前务虚会之任何东西
js的下载和执行会阻塞Dom树的构建（严谨地说是中断了Dom树的更新），所以script标签放在首屏范围内的HTML代码段里会截断首屏的内容。下载脚本时并行下载是被禁用的——即使使用了不同的主机名，也不会启用其他的下载。因为脚本可能修改页面内容，因此浏览器会等待；另外，也是为了保证脚本能够按照正确的顺序执行，因为后面的脚本可能与前面的脚本存在依赖关系，不按照顺序执行可能会产生错误。
四、JS 和css的精简 组件的优化
这些就是项目中细节，在渲染的时候不要使用行内样式，以及js的使用规范等等。看实际项目，我们使用了一个antd的table,z自己封装了一个可拖拽的表格，在每个用到Dtable的页面都进行了很多计算，这样，每次渲染都会从父组件传到子组件遍历DOM树，效率就很低，后面把所有公共的计算都直接放到最终使用的那个组件上，有些参数都放在子组件内部进行赋值计算，优化一波之后，表格的操作速度也提高了不少。