完成需求很重要，优化好更重要

总喜欢在前面啰嗦一些...
如题，在平常紧急开发中，完成需求当然排在前面(毕竟产品会追着你打🙄)，可是需求完成以后仍是颇有必要去优化咱们的项目的！
花一两个月去作了一个项目，需求评审、原型评审、开发排期、测试用例评审、设计图评审(感受不断的在开会)、开发、联调、提测、上线...大功告成，告辞！
固然这期间的流程每一个公司都会不一样，可能还会有需求变动什么的...
咱们今天只谈上线以后...
上线以后，各类bug如期而至，正如你所料，需求所涉及的功能都作了，为何还遭到用户投诉，这里很差那里又有问题？
对于用户而言，你的首页加载速度，很考验他(她)的耐心，so,首页加载优化得作
最简单易见的就是图片了，关于图片的优化：

图片优化(一)——大图片的优化

压缩上传，已附连接，还蛮好用的，去各大网站看一下，首页总共的资源
x宝

x东

能够看到，电商类的首页才只有不到2M的图片，还有你会发现，图片懒加载和预加载也起了相当重要的做用,预加载就是在网页所有加载以前提早加载图片。当用户须要查看时可直接从本地缓存中渲染以提供给用户更好的体验减小等待的时间，懒加载就是滑到可视区再加载(或知足条件再加载)

图片优化(二)——小图片的优化(icon)

精灵图 （请css喝雪碧）

老生常谈了，就是将不少的小图标集合到一个图片中去，目的是减小资源请求(网页的缓存机制是会略去本地已经有的资源),这个让设计师把一些简单的小图标集成到一张图给到前端就行了，前端设置

background-image: url('../../img/jlt.png');
        background-size: 4.34rem;//根据大图算出来的
        background-position: 0.2rem 0.3rem;//位置拿photoshop量或者手动试也能够(😂)

还有一些小icon,要会变色(不是根据眼睛变化那个..),根据网站主题色去变(或者就是迭代需求只是变色，图标不变)，那再让设计师把带颜色的加到精灵图中，相信你俩都不爽，这时候能够考虑用

svg

---

svg明显能知足变色需求，改fill属性就行了，无论你是主题色仍是需求变动，并且svg是矢量级的图标，占位也很小，你要是变换3个颜色，精灵图里面就得给你三个不一样颜色图标，因此从空间上也有优点

@font-face

还有一个比较棒的网站，阿里矢量图标库，里面存放了不少小的icon,格式支持也不少，jpg、png、svg等等
让设计师建个项目，把对应的小图标上传到这里，而后会生成一个unicode,就是font-face的线上地址，复制到项目里就好
用法和本地下载好字体库是同样的，

@font-face {
  font-family: 'icon';
  src: url('https://。。。.eot');
}
.icon{
  font-family:"icon" !important;
  font-style:normal;
}

具体页面使用加上icon这个类名，改颜色，就是直接改color,也是灰常的好用

静态资源的抽取

项目中依赖的一些json、css、js等都抽取到cdn
浏览器是根据域(Domain)来缓存内容资源的，只要域不同，即便是同一个资源，也须要重复下载，且使用一样的方式缓存起来，这须要须要占用带宽和本地缓存空间，cdn详解

路由懒加载(vue+webpack)

前提是vue+webpack
都知道，若是不作，在首页会加载全部的页面资源，因而出了个解决方案：到哪一个页面再去加载对应的资源
写法一：const abc = r => require.ensure([], () => r(require('../pages/acb/abc.vue')), 'abc');
写法二：

{
          path: 'abc',
          component: () => import('@/pages/abc/abc.vue'),
          meta: {
            title: 'abc'
          }
        },

把网速调慢，会发现，第一种写法会有很长的白屏时间(页面title变了，页面未变)，第二种快了一些，并且第二种写法也更简洁

公有组件抽取

开发中，可能有点小摩擦，‘你的组件比较偏向于你，我要本身重新写一个’
组件的设计必定要知足大众口味，这样才能节省一些空间出来
好比load、弹框等等，主体结构复用，style在我的页面调整

还有一些大而广的东西：
减小请求(只能说尽可能，业务须要该少的少不了)
减小DOM操做(如今都是虚拟DOM，还在讲DOM操做...)
避免使用CSS表达式(不多有人写吧，尽可能用rem替换calc吧)
函数防抖和函数节流(小红书函数部分明确有些，load也能够替代功能)
首屏服务端渲染(还不错，接口直接返回page)
...

总结：

只有真正的在完成需求后，才会遇到种种问题，才能想到去优化哪些东西，因此实践真的是检验真理的惟一标准有时间新建个demo实际操做一波仍是很不错的选择，毕竟听别人叨叨似懂非懂的，换成本身的东西还能吹上一番