跟你們聊一下前端性能怎麼優化

過完年了也是一直拖到了如今纔有時間補交一下做業，去年出差出了一年，是時候好好沉澱一下了

目錄

• 前言
• 設計角度
• UI   角度
• 開發角度

1、前言

我一直對我負責的項目成員講，項目交付給客戶的前提是不卡，以後是對用戶的友好度必需要高。由於不管你的項目作的有多好，若是用着卡，用戶終究會不承認，你們估計也是深有體會。隨着時代節奏加快，人們趨向於快速便捷，容易上手的事物。

一、優質的用戶體驗

這一點很重要然而又讓用戶在通常狀況下感受不到，在產品界有一句話，最好的用戶體驗就是讓用戶沒感受，信手拈來。

就你們手機裏的app來講，大多數的用戶體驗都是極好的，產品團隊天天都在維護調研，時時刻刻監測着用戶需求的走向。

那麼有沒有反例呢：

某網購app你好：我買了一款榨汁機，並不表明我須要更多的榨汁機。

相信你也有這種體會，我雖然逛了很長時間爲了買臺榨汁機，可是在我買了以後，仍是會鋪天蓋地的給我「智能」推送榨汁機的產品，我看了這些推送產品以後，總會讓我糾結。

後悔買內臺了，我應該買這臺

一種人工智能離咱們愈來愈遠的感受。

二、簡潔明瞭的界面

前端發展到如今，大多數客戶端都已趨近於扁平化界面，還有不少公司的logo也設計成了扁平化，就是由於簡潔明瞭。

隨着顯示屏的發展，可視區域能夠展現的內容愈來愈多，用戶找到本身須要的東西的花費的時間會愈來愈長，因此如何設計簡潔明瞭的界面成爲了大勢所趨。

若是打開一個網站看幾分鐘以爲刺眼，那麼就可能就不夠簡潔

三、方便快捷的操做流程

這一點也是每一個產品必須考慮的一部，能用兩步完成的步驟就不要讓用戶操做三步，能讓用戶少點一下是一下，除非你開發的是掃雷。

舉個例子：

如今大多數登陸系統，都是註冊完直接登陸系統，而後慢慢引導用戶完善我的信息，若是反過來的話。註冊完，還須要填寫一堆我的信息才能登入系統，用戶已經在崩潰的邊緣了是吧，默默罵着街，你爲何要查我戶口。

中心思想是簡化用戶操做

2、設計角度

表面上的性能問題，本質上是用戶反饋的體驗差

一、數據加載等待

• loading效果
  
  在我看來，每一個請求數據接口，加載loading效果是必不可少的，絕對不可能讓用戶默默的看着一片空白愣神幾秒鐘，至少得盯着一個antd的菊花。別說用戶了，你家產品經理也受不了。
• 預加載
  
  在開發中，可能會遇到這樣的狀況。有些資源不須要立刻用到，可是但願儘早獲取，這時候就可使用預加載。
  預加載實際上是聲明式的 fetch ，強制瀏覽器請求資源，而且不會阻塞 onload 事件，可使用如下代碼開啓預加載
  
  <link rel="preload" href="http://example.com" />
  
  預加載能夠必定程度上下降首屏的加載時間，由於能夠將一些不影響首屏但重要的文件延後加載，惟一缺點就是兼容性很差。

二、首頁加載等待

• 首頁單獨維護
  
  我曾經作過一個設備商城可下單的系統，首頁作的很炫酷，可是身後的管理系統十分龐大，因此會拖延首頁加載時間。這時咱們給出瞭解決方案就是首頁單獨維護，首頁單獨用原生html編寫，採用雙頁面應用的結構，讓用戶訪問首頁的時候能夠秒進，配合系統路由入口處作攔截認證
• 首頁加載動畫
  
  這個場景也很廣泛，這時候就得找一個就算系統加載很慢，可是讓用戶看3分鐘這個加載動畫也不會感受到焦慮的效果。例如：
  

• 骨架屏
  
  京東慣用方式，針對一下網速過慢的狀況，先弄了個「假」界面。

  

  大概這個樣子，減小用戶焦慮

三、頁面切換過渡

業務跟業務之間切換時候加上過場動畫效果，會給用戶一種很絲滑的感受，要調試出一種下雨天跟angelababy一塊兒吃巧克力的感受。

曾經有個項目中，由於時間比較富裕，也是產品展現類網站，我作了全套的頁面切換過渡效果，在項目路由切換的時候封裝一層，跳轉以前，讓當前組件淡出，跳轉以後讓下一個組件淡入。最終效果很好，無縫銜接。

四、適當的動畫效果

每一個項目或多或少都會添加動畫效果用來當作操做的過渡，一個很經典的案例，購物車拋物線問題，想當初淘寶天貓的購物車 點擊商品右下角購物車圖標的時候會有一個圓球，以一條優美的拋物線落在頁面右下角購物車tab上，效果很是好，讓人忍不住想多買幾個產品，就想多看幾回動畫。極大的提高了用戶體驗。

3、UI角度

咱們得知道咱們能壓榨UI多少資源

一、大型圖片

減小像素點 減小每一個像素點可以顯示的顏色

• png8
  
  這裏我就直接推薦png8質量格式，直接讓UI把圖片壓縮爲png8 像素點64便可，而後注意一點，咱們開發時候用的圖片都是須要200%大小的，由於須要適配高清屏，可是UI的宗旨呢是越大越高清越好，若是UI給你的圖片尺寸大於200%，須要提出圖片尺寸的問題。
  
  固然，UI沒時間的時候，推薦fireworks，操做及其簡單，爲前端而生的photoShop。只需幾步，UI就會愛上你。

• webp
  
  見怪不怪，剛出webp的時候本身吹的大小縮小了60%，圖片效果上沒有變化，純算法壓縮。由於兼容性不夠好沒有流行起來，最近我又查了一下，網上不少跨瀏覽器兼容解決方案有不少，好比webp.js。已經很好的解決了兼容性問題，能夠投入使用。

二、中小型圖片

• sprite
  
  北方稱 精靈圖，南方叫
  雪碧圖，經過請求一次大照片，經過background—position定位小圖片的位置，節省帶寬，一種經久不衰的方式。

• iconfont
  
  很少解釋了，感謝iconfont

• base64
  
  這個頗有爭議，爭議在於多大的圖片用base64纔好，爭論着爭論着後來就沒人用了。。。，webpack中能夠配置多大如下的圖片編碼成base64打進js中。module中配置的limit爲大小控制
  { test: /\.(png|jpg)$/, loader: "url?limit=0" }

• svg
  
  小技巧之：當你用到一張gif的時候，UI能夠導成svg格式的給你。我說的是線性的。

三、UI不讓動的圖片

這種狀況也是很常見的，產品渲染圖之類的，例如剛出的米酒手機，官網上的海報

這種圖片你壓縮減小個像素點吶，減小每一個像素點展現的顏色啊，UI不來砍你，TF粉絲也會來砍你，是吧。

這時候果斷：「老闆，給我拿錢我去買個CDN」。

CDN 內容分發網絡，這個我聽過一個通俗的例子。

之前買火車票你們都只能去火車站買，後來咱們買火車票就能夠在樓下的火車票代售點買了。

你們本身悟一下就懂了。

這裏注意一下，註冊CDN的帳號用老闆的不要用本身的，否則很差離職（我就是）

四、圖片渲染

• 懶加載
  
  老生常談，只加載可視窗口的圖片。
• 預加載
  
  新生沒談，提早加載下一個可視窗口的圖片，並不是所有，只是下一個可視窗口。作過瀑布流的應該知道。沒作過的能夠按照這個思路本身探索一下。

4、開發角度

一、選擇適合項目成本的架構

爲何這麼說呢，通常來講pc站的項目架構對於移動站來講就顯得沉重，越往前追憶越注重這一點，尤爲在jquery年代。爲了解決此問題，不少框架都會出一款mobile版本、輕量版本。如今的UI框架大多都沒有此問，例如antd，打包的時候只會把你引用到的組件打包到文件中，沒引用到的組件不會被打包到文件中。bootstrap就正好相反。

我想這也是響應式項目逐漸gg的緣由，並無抗住2G 3G時代，我相信若是5G普及了，移動端項目也不用考慮框架大小的問題了。

然而，成本一說，還有一個比較基礎的概念，按照開發週期來講，理論上開發週期短的項目，咱們採用一些高度封裝的開源組件高效完成。缺點就是，高度封裝的開源組件引用以後不方便之後需求更新迭代。反之，較長的開發週期是咱們正想要的。

二、下降算法複雜度

我身邊大多數人對算法的理解：

沒有我兩遍循環處理不了的數組！

最終咱們處理1w條數據的時候，底層一些組件render了100w+次，致使瀏覽器間歇性崩潰。

這種狀況首先從組件角度來講，並無作好攔截render的處理。相似於react的shouldComponentUpdate。

以後則是算法複雜度的問題。並無優化。

就比如最基礎的查找算法，你們應該也該瞭解窮舉法和二分法哪個好一些

算法複雜度是指算法在編寫成可執行程序後，運行時所須要的資源，資源包括時間資源和內存資源。

這個值得單拿出一篇文章來說，可是我這邊暫時直接給出一個如今不少大公司的招人規範，leetcode算法題庫，騰訊前端要求leetcode easy難度。你們能夠去刷刷題，頗有幫助。

三、按需加載

注意一下：這個並非每一個項目都適合

那麼，什麼樣的項目才適合按需加載呢？

展現類項目，例如小米官網，每次發佈一款手機後，我都須要加個菜單，加一個獨立的展現類業務。

那麼，什麼樣的項目不適合按需加載呢？

管理系統，系統爲一個總體，中間參數串聯太狠，本地開發沒什麼問題，按需打包以後扔到測試環境就各類undefined。

四、數據的預加載

在開發中，可能會遇到這樣的狀況。有些資源不須要立刻用到，可是但願儘早獲取，這時候就可使用預加載。

預加載實際上是聲明式的 fetch ，強制瀏覽器請求資源，而且不會阻塞 onload 事件，可使用如下代碼開啓預加載

<link rel="preload" href="http://example.com" />

預加載能夠必定程度上下降首屏的加載時間，由於能夠將一些不影響首屏但重要的文件延後加載，惟一缺點就是兼容性很差。

還有一種，好比說我有兩個tab頁籤。一般狀況，用戶點擊第二個tab的時候纔會去獲取數據。其實當用戶鼠標放上去的時候就能夠獲取數據了，點擊操做結束後，數據已經請求回來了。這種方式也是很是不錯，可是注意一下節流，鼠標來回晃，發起一萬個請求，後臺會覺得誰攻擊服務器了。

五、緩存

資源文件走緩存，見怪不怪，用得好是利器。

個人項目統一，萬年不變的文件通通走緩存，放在public中手動加hash，其餘src下面的自動hash。

webpack能夠配置，能夠控制哪些文件加hash，哪些不加，也能夠控制哪些文件的hash須要變，哪些不須要變。你們能夠了解一下。

END

今年還沒安排出差的任務，可是有預感也快了，有人就問了，爲何你出差不寫文章呢？ 有時間都出去玩了好嘛，哈哈。 沉澱了一波，我這邊3月底以前會寫4篇文章，分別爲

• 《前端性能優化交流》
• 《前端代碼質量優化交流》
• 《前端code監控交流》
• 《前端安全問題交流》

沉澱一下去年在開發流程方面的一些知識。 謝謝各位。