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

總喜歡在前面囉嗦一些...
如題，在平常緊急開發中，完成需求當然排在前面(畢竟產品會追着你打🙄)，可是需求完成以後仍是頗有必要去優化咱們的項目的！
花一兩個月去作了一個項目，需求評審、原型評審、開發排期、測試用例評審、設計圖評審(感受不斷的在開會)、開發、聯調、提測、上線...大功告成，告辭！
固然這期間的流程每一個公司都會不一樣，可能還會有需求變動什麼的...
咱們今天只談上線以後...
上線以後，各類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實際操做一波仍是很不錯的選擇，畢竟聽別人叨叨似懂非懂的，換成本身的東西還能吹上一番