前端性能優化的經常使用手段

時間 2019-11-09

原文原文鏈接

反正，前端性能優化就是很重要，很差好學習怎麼進階到20K+的薪水啊？！javascript

性能優化方面一直有所關注，但若是不去對本身所負責的項目進行一下回鍋，實踐實踐，優化優化，總會有點「書上得來終覺淺」的感受吧！css

從最開始的CSS放到<head>裏面、js放到</body>前面、使用雪碧圖等，到後面的靜態資源壓縮、合併以及使用iconfont代替小圖標，再到最近實踐的gzip壓縮、設置HTTP Header緩存字段...前端

gzip壓縮、設置ETag等，早就在《高性能網站建設指南》那兩本書中看過，但我一直認爲這都是後端小夥伴幹得事，就沒有怎麼留意過。直到最近，對先後端分離的理解愈來愈充分，對整個項目的部署愈來愈清晰，對項目裏面的資源請求愈來愈明白，才恍然意識到：先後端分離了，這他媽就是前端本身乾的事啊！！！java

從如下幾個方面來講一說本身實踐過的優化方法：node

瀏覽器渲染頁面的過程

所謂優化，第一個要弄明白的就是：優化什麼、從哪裏優化。前端作出來的頁面是在瀏覽器裏面呈現的，那瀏覽器是怎麼渲染這個頁面的呢？遇到CSS、js靜態資源，瀏覽器是怎麼處理的？具體的過程這裏再也不贅述，網上資源一大堆，我本身以前也寫過一篇，《網站性能優化—CRP》，算是谷歌文檔的翻譯版吧。 webpack

理解了瀏覽器渲染頁面的過程，也就明白了：CSS爲何要放到<head>裏面、js放到</body>前面，以及js的異步加載（async、defer）等優化。web

減小HTTP請求

CSS/JS 合併打包
小圖標等用iconfont代替：做爲單個DOM節點使用，能夠設置大小、顏色等，很是便利。我的建議前端來維護這個字體包，每次有新增的圖標，讓設計師給咱們對應的svg文件便可，前端本身去 icomoon.io/ 這個網站，導入原來的selection.json文件，增量生成新的css，無比方便。以前，我一直覺得iconfont只能是單色的呢，其實也能夠是多色的，svg裏面多一些path而已，設計師會搞定的。生成字體後，前端正常引用便可（引用的時候，多色字體會多一些標籤）
使用base64格式的圖片：有些小圖片，可能色彩比較複雜，這個時候再用iconfont就有點不合適了，此時能夠將其轉化爲base64格式（不能緩存），直接嵌在src中，好比webpack的url-loader設置limit參數便可
~~使用雪碧圖：設置背景圖尺寸大小，感受很麻煩，並且雪碧圖的維護也不怎麼便利，好像使用率愈來愈低了，都被iconfont取代了~~

減小靜態資源的體積

壓縮靜態資源：合併打包的js、css文件體積通常會比較大，一些圖片也會比較大，這個時候必需要壓縮處理。先後端分離項目，不管是gulp仍是webpack，都有相應的工具包。針對個別圖片，有時候也能夠單獨拿出來處理，我我的常用這個網站 tinypng.com/ 在線壓縮
編寫高效率的CSS：涉及到代碼層面的優化比較多也比較細，不一樣水平的技術人員寫出來的確定不同，這裏不作進一步的分析。可是爲何要把CSS拿出來講一說呢？由於如今項目裏面基本上都在使用CSS預處理器，Less、SaaS、Stylus等等，這致使了某些初級前端的濫用：嵌套五、6層，甚者能達到七、8層，嚇死我的！嵌套這麼深，影響瀏覽器查找選擇器的速度不說，這也必定程度上產出了不少冗餘的字節，這個要改、要提醒，通常建議嵌套3層便可。關於編寫高效率的CSS，推薦一篇文章，《Writing efficient CSS selectors》
服務端開啓gzip壓縮：大招，最近剛知曉，真是太牛逼了，通常的css、js文件能壓縮60、70%，固然，這個比率能夠設定的。先後端分離，若是前端部署用node、express做服務器的話，使用中間件compression便可開啓gzip壓縮：express
```
// server.js
var express = require('express');
var compress = require('compression');
var app = express();
app.use(compress());複製代碼
```
對於通常的SPA項目，若是node服務器的做用比較簡單，好比只是作個接口轉發之類的，不少人更傾向用Nginx做服務器，Nginx在轉發接口、壓縮、緩存等功能上更勝一籌。不過，大部分前端對Nginx應該陌生一些，爲了實踐技術，用熟悉的node便可，真正的項目部署，有專業的實施人員來搞。json