前言
前端随着node等JavaScript运行时平台的出现，逐渐向工程化方向发展。项目开发也越来越规范化，但是随着项目的体积越来越大，依赖库越来越多，项目的运行，热更新和打包发布也是越来越慢，甚至卡顿。这个时候就需要对项目进行“瘦身”（性能优化）了。本文就围绕着如何给前端项目进行性能优化等技术点一一展开讨论
为什么
为什么要进行项目性能优化，其实这个问题我在前言中已经简单阐述过了。优化的目的是为了改善用户的使用体验，提高用户的留存率，你的产品页面和功能的响应的速度越快，交互更加的人性化，对用户更加的友好，那自然而然的就会收到用户的青睐啦。所以对项目的优化不仅仅是要从技术思维去作为出发点，同时也要从产品思维出发站在用户的角度(也就是一个使用者的角度)作为出发点。这样的优化才是有效优化，否则就是东施效颦了，乱搞一通，随大流。。。
Web 性能
这里声明一下，本文只阐述web项目的性能优化。其他平台的项目是否适用，自行斟酌！
在对web项目优化之前先了解一下web的性能指标，这里引用MDN中的一段描述。
Web 性能是客观的衡量标准，是用户对加载时间和运行时的直观体验。Web 性能指页面加载到可交互和可响应所消耗的时间，以及页面在交互时的流畅度——滚动是否顺滑？按钮能否点击？弹窗能否快速打开，动画是否平滑？Web 性能既包括客观的度量如加载时间，每秒帧数和到页面可交互的时间；也包括用户的对页面内容加载时间的主观感觉。
页面响应时间越长，越多的用户就会放弃该网站。重要的是，通过使体验尽可能早地变得可用和交互，同时异步地加载长尾体验部分，来最大程度地减少加载和响应时间，并添加其他功能以降低延迟。
Web性能指标模型
RAIL 是 Response、Animation、Idle 和 Load 的首字母缩写，是一种由 Google Chrome 团队于 2015 年提出的性能模型，用于提升浏览器内的用户体验和性能。
- Response(响应) ：在50ms内处理事件 目标：在 100 ms内完成由用户输入发起的转换，让用户感觉交互是即时的。
- Animatio(动画) : 在10ms内生成一帧，目的为流畅的视觉效果 在 10 毫秒或更短的时间内生成动画的每一帧。从技术上来讲，每帧的最大预算为 16 ms（1000 ms/每秒 60 帧≈16 ms） ，但是，浏览器需要大约 6 ms速来渲染一帧，因此，准则为每帧 10ms。
- Idle(空闲) ：最大限度增加空闲时间 最大限度增加空闲时间以提高页面在 50 ms内响应用户输入的几率
- Load(加载) ：在5s内交付并实现可交互 目前对于首次加载，在使用速度较慢 3G 连接的中端移动设备上，理想的目标是在5s或更短的事件内实现交互对于后续加载，理想的目标是在2s内加载页面。
优化方向
所以综上所述，所以我们优化的项主要是集中在：
- http的请求的响应
- 动画的视觉和流畅效果
- 交互的响应速度
- 页面加载的时间
这四个大的方向
当然除了这四个方向以为我觉得还可以有其他的途径去进一步的优化，当然了，这肯定也是要看应用场景的，根据业务的需要去具体问题具体分析的，不能够为了优化而去优化。
也可以换个说法：
- 传输资源的优化：比如图像资源，不同的格式类型会有不同的使用场景，在使用过程中判断是否恰当；
- 加载过程的优化：比如加载延迟，是否有不需要在首屏展示的非关键信息，占用了页面的加载时间；
- JavaScript的优化：JavaScript代码是否进行了压缩，书写是否规范，有无考虑内存泄漏等；
- 关键渲染路径优化：比如是否存在不必要的回流与重绘等；
- 本地存储和浏览器缓存。
举个栗子
