前端优化

不同视角 用户眼中的性能： 客户的机器，浏览器，网络状况，通信协议，服务器处理时间，浏览器解析时间。另外 1s左右 ，对用户来说是无区别的。 开发严重的性能：程序本身和相关子系统。响应延迟，系统吞吐量，并发处理能力，系统稳定性等。 运维人员：关注基础设施的资源和性能的利用率，合理利用，最优发挥（不浪费，不堵塞） 性能指标 响应时间 ：10000/n次时间和，除以10000/n。 并发数 吞吐量 ：TPS(每秒事务数),HPS(每秒请求数),QPS(每秒查询数) 。理论上讲 应该是个抛物线，峰值即为吞吐量值。 吞吐量，并发数，响应时间之间的关系 用高速公路形容很接近。车越少（并发数），资源越浪费（内存，硬盘，网络），车增多，开始吞吐量上升，到达峰值后会随之下降，直至瘫痪。 性能计数器：描述操作系统的性能指标（System Load，对象与线程数，内存使用，cpu使用，磁盘及网络io等指标） 测试方式 性能 测试：验证资源可接受范围 稳定性 测试：不均匀的施加压力，验证稳定性 压力 测试：超过安全负载的情况下，继续对系统施加压力，直至系统崩溃或者不能处理请求，来获取系统最大压力承受能力。 负载 测试：对系统不断增加并发，不断增加压力，直至系统或者应用多项指标达到临界值 性能优化 web前端，应用服务器，存储服务器性能优化。 Web前端优化 浏览器优化 1 减少http请求 2

这段时间对项目做了一次整体的优化，全站有了20%左右的提升（本来载入速度已经1.2S左右了，优化度很低），算一算已经做了四轮的全站性能优化了，回顾几次的优化手段，基本上几个字就能说清楚： 传输层面：减少请求数，降低请求量执行层面：减少重绘&回流 传输层面的从来都是优化的核心点，而这个层面的优化要对浏览器有一个基本的认识，比如： ① 网页自上而下的解析渲染，边解析边渲染，页面内CSS文件会阻塞渲染，异步CSS文件会导致回流 ② 浏览器在document下载结束会检测静态资源，新开线程下载（有并发上限），在带宽限制的条件下，无序并发会导致主资源速度下降，从而影响首屏渲染 ③ 浏览器缓存可用时会使用缓存资源，这个时候可以避免请求体的传输，对性能有极大提高 衡量性能的重要指标为首屏载入速度（指页面可以看见，不一定可交互），影响首屏的最大因素为请求，所以请求是页面真正的杀手，一般来说我们会做这些优化： 减少请求数 ① 合并样式、脚本文件 ② 合并背景图片 ③ CSS3图标、Icon Font 降低请求量 ① 开启GZip ② 优化静态资源，jQuery->Zepto、阉割IScroll、去除冗余代码 ③ 图片无损压缩 ④ 图片延迟加载 ⑤ 减少Cookie携带 很多时候，我们也会采用类似“时间换空间、空间换时间”的做法，比如： ① 缓存为王，对更新较缓慢的资源&接口做缓存（浏览器缓存

前端优化已经是一个被写烂的题材了。 虽千万人吾往矣，这里我仅分享我的一些实践经验。 欢迎一起交流 欢迎关注我的个人公众号，不定期更新自己的工作心得。 正文如下 前端性能 1. 模块化 严格来说，代码模块化并不能带来性能上的提升，但我还是将模块化提出来，因为它真的很重要，重要到几乎所有的优化都与它息息相关。 常见的模块化方案有：AMD、CMD、UMD、ES6 如何选择？ 团队习惯 个人偏好 业务需要 我靠！你怎么能把业务需要放在最后一个考虑？ 因为没有哪一块业务会因为使用了不同的模块化方案而产生不同的结果。 而且我觉得 软件开发中的以人为本 用在这里刚好合适，其他地方就只能 呵呵了。毕竟业务高于一切，这是操守。 2. 缓存 缓存一定要加！ 缓存一定要加！ 缓存一定要加！ 因为CDN真的很贵。。。 没有CDN？那就更得加缓存了！！！ 缓存有很多方式，最为常见的就是下面这两种了 浏览器304缓存 localstorage本地存储 业界，一直有关于304缓存与localstorage性能的争议，这里我们不讨论两者的差异，或性能问题。 我一向以业务导向选择方案，这里我选择的是localstorage，如果你愿意，你可以通过localstorage将缓存玩出一朵花出来。 你可以这么干： 通过localstorage存储js、css资源； 资源版本控制； 只要你愿意

最近接手了公司两个项目，一个PC端后台管理系统，一个app端项目，当然使用的依然是熟悉“Vue全家桶”那套！但是，当我打开项目时，里面的代码是这样的（路由模块）： 就是所有路由配置都放到一个index.js中，这多少还是让我有点惊呆的，显然，项目会越做越大，模块会越加越多，那这种不分模块的架构方式明显给以后带来很大维护困难，index.js文件会变得异常庞大... 所以，我便想趁现在代码量还在可控的情况下赶紧优化一下吧！于是，跟领导说明了用意，并很快得到了首肯！所以就开始动起来了~ 1. 分模块： 　　首先，当然是要把不同模块的路由分离开来了（本来想只把新加入的功能模块做处理，老模块保留现状，因为复制、粘贴也是很耗体力的。但是，想想所幸现在项目还不大，再加上目前虽然不年轻但还算力壮，且还稍微有点强迫症的催动下，所以还是决定将现在有代码拆开...）,心里小小斗争一下之后，就开干了！于是，就有了这样的结构： 同时，让index.js的全部代码缩减成了这样： 为啥你module里的文件名会是.routes.js 呢？这个嘛... 其实是个小技巧，并不是便性规定， 1. 为了方便正则匹配，2. 为了标识文件的功能，让人一看就是知道这是路由文件... 啥正则匹配？ 2. 自动导入： 　　为啥能将index.js缩减成这样呢？其实就是代码所示，利用了require

待优化项分析 打包项目资源分析 使用现在做主流的框架进行开发，大多都要经历打包这一过程,将核心代码和引入的第三方模块进行打包，但是往往会发现打包的结果不尽人意，在这里使用一个工具可以分析打包文件的构成. 可视化打包分析工具: webpack-bundle-analyzer 1.下载安装 npm install webpack-bundle-analyzer --save-dev vue.config.js 配置 const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin module.exports = { ... chainWebpack:(config)={ if(process.env.NODE_ENV === 'production'&&process.env.npm_config_report){ config .plugin('webpack-bundel-analyze') .use(BundleAnalyzerPlugin) .end() } } } 配置启动指令 package.josn { ... "scripts":{ "report":"npm_config_report= true npm run build " } } 使用 npm run

这段时间对项目做了一次整体的优化，全站有了20%左右的提升（本来载入速度已经1.2S左右了，优化度很低），算一算已经做了四轮的全站性能优化了，回顾几次的优化手段，基本上几个字就能说清楚： 传输层面：减少请求数，降低请求量 执行层面：减少重绘&回流 传输层面的从来都是优化的核心点，而这个层面的优化要对浏览器有一个基本的认识，比如： ① 网页自上而下的解析渲染，边解析边渲染，页面内CSS文件会阻塞渲染，异步CSS文件会导致回流 ② 浏览器在document下载结束会检测静态资源，新开线程下载（有并发上限），在带宽限制的条件下，无序并发会导致主资源速度下降，从而影响首屏渲染 ③ 浏览器缓存可用时会使用缓存资源，这个时候可以避免请求体的传输，对性能有极大提高 衡量性能的重要指标为首屏载入速度（指页面可以看见，不一定可交互），影响首屏的最大因素为请求，所以请求是页面真正的杀手，一般来说我们会做这些优化： 减少请求数 ① 合并样式、脚本文件 ② 合并背景图片 ③ CSS3图标、Icon Font 降低请求量 ① 开启GZip ② 优化静态资源，jQuery->Zepto、阉割IScroll、去除冗余代码 ③ 图片无损压缩 ④ 图片延迟加载 ⑤ 减少Cookie携带 很多时候，我们也会采用类似“时间换空间、空间换时间”的做法，比如： ① 缓存为王，对更新较缓慢的资源&接口做缓存（浏览器缓存

随着移动互联网的发展，我们越发要关注移动页面的性能优化，今天跟大家谈谈这方面的事情。 首先，为什么要最移动页面进行优化？ 纵观目前移动网络的现状， 移动页面布局越来越复杂，效果越来越炫，直接导致了文件越来越大，下载和运行速度越来越低，而速度低会造成不良影响，据统计： 71%的用户期望移动页面跟pc页面一样快，74%的用户能容忍的响应时间为5秒，所以我们必须保证移动端页面有足够的速度。 移动页面的速度跟三个因素有关，分别是：移动网络带宽速度，设备性能（CPU，GPU，浏览器），页面本身。 目前主流的移动网络制式为3g 今年，我们还看到了4g网络制式在快速发展，这再一次提升了移动页面的加载速度； 而移动设备本身，截止到目前，以iphong6三星Note4等设备为首，智能设备已经变得比以往屏幕更大，CPU、GPU、内存更靠谱 而与其同时，浏览器产商也为提升页面的速度做出了不可磨灭的努力，这里大家可以看一个视频（ http://www.iqiyi.com/w_19rsgfld99.html ） 网络制式供应商，手机制造商，浏览器产商如此给力，我们呢？我们能做什么。 我们能做得是对移动端页面本身优化，这也是我们专业价值的体现，所以我们必须做移动端页面性能优化。 该怎么做移动端页面优化呢？ 在说这个前，要提一下pc常用的优化手段： 代码优化（css、html、js优化） 减少HTTP请求

性能优化概述 从输入 URL 到页面加载完成，完整的链路 1.DNS 解析 2.TCP 连接 3.HTTP 请求抛出 4.服务端处理请求，HTTP 响应返回 5.浏览器拿到响应数据，解析响应内容，把解析的结果展示给用户 整个性能消化 http层面优化 DNS 解析: DNS 实现域名到IP的映射。通过域名访问站点，每次请求都要做DNS解析。目前每次DNS解析，通常在200ms以下。一般采用DNS Prefetch 一种DNS 预解析技术，当你浏览网页时，浏览器会在加载网页时对网页中的域名进行解析缓存，这样在你单击当前网页中的连接时就无需进行DNS的解析，减少用户等待时间，提高用户体验。 < link rel = "dns-prefetch" href = "www.baidu.com" /> 只有部分浏览器支持 TCP 连接： 采用http2.0，可以复用tcp通道，采用二进制格式而非文本格式，使用报头压缩，HTTP/2降低了开销， 支持cache push 浏览器并发 基于端口跟线程切换开销，浏览器不可能无限的并发请求。chrome的并发为6，超过限制数目的请求就会被阻塞； 对于某些静态资源，图片等等，我们可以对其URL分散处理 ，不同的资源域名(部署在cdn上)。 http请求次数 减少http的请求次数，将多个请求合并成同一个，减少http的开销 webpack

重复优化的思考 这段时间对项目做了一次整体的优化，全站有了20%左右的提升（本来载入速度已经1.2S左右了，优化度很低），算一算已经做了四轮的全站性能优化了，回顾几次的优化手段，基本上几个字就能说清楚： 传输层面：减少请求数，降低请求量执行层面：减少重绘&回流 传输层面的从来都是优化的核心点，而这个层面的优化要对浏览器有一个基本的认识，比如： ① 网页自上而下的解析渲染，边解析边渲染，页面内CSS文件会阻塞渲染，异步CSS文件会导致回流 ② 浏览器在document下载结束会检测静态资源，新开线程下载（有并发上限），在带宽限制的条件下，无序并发会导致主资源速度下降，从而影响首屏渲染 ③ 浏览器缓存可用时会使用缓存资源，这个时候可以避免请求体的传输，对性能有极大提高 衡量性能的重要指标为首屏载入速度（指页面可以看见，不一定可交互），影响首屏的最大因素为请求，所以请求是页面真正的杀手，一般来说我们会做这些优化： 减少请求数 ① 合并样式、脚本文件 ② 合并背景图片 ③ CSS3图标、Icon Font 降低请求量 ① 开启GZip ② 优化静态资源，jQuery->Zepto、阉割IScroll、去除冗余代码 ③ 图片无损压缩 ④ 图片延迟加载 ⑤ 减少Cookie携带 很多时候，我们也会采用类似“时间换空间、空间换时间”的做法，比如： ① 缓存为王，对更新较缓慢的资源&接口做缓存

来源： oschina 链接： https://my.oschina.net/u/2365986/blog/539330