前端性能優化總結
原因:最近公司一個專案即將上線,作為它的主要構建者之一(親爸爸)
一直在思考如何能給它更好的性能優化
于是博主開始了網上大量的學習,集百家之所長,試圖把這些騷操作應用在自己的專案中,
完事之后記錄一下自己的心得感悟(好記性不如爛筆頭)
文章目錄
- 前端性能優化總結
- 前言
- 一、對于一個前端來說,性能優化是什么?
- 二、可感知性能優化
- 1.用戶體驗(所有用戶)
- 2.甜甜圈,骨架屏,懶加載等一些視覺騙術
- 三、性能構建優化
- 1.去除 console.log
- 2.去除 SourceMap
- 3.Gzip 壓縮
- 4.Css可優化之處
- 5.Js可優化之處
- 總結
- 明天,又是充滿希望的一天!
前言
最近花了一些時間和精力在專案的性能優化上,做了很多作業 雖然最后結果不是特別理想,但還是想記錄一下自己所使用過的優化方案,避免以后踩坑,一、對于一個前端來說,性能優化是什么?
對于一個前端來說,我覺得性能的優化可以分為兩類:
- 站在用戶的角度去觀察(用戶可以明顯感知到的性能優化)
- 站在開發者的角度去觀察(開發人員對代碼層面可以客觀度量的性能優化)
二、可感知性能優化
1.用戶體驗(所有用戶)
幾個月前曾在某博客論壇上看到一篇令人稱奇的所謂的前端性能優化的文章,感觸很大
在此之前,一直把頁面渲染的快慢,介面里面一個邏輯的優化處理(公司沒有后端,用的是云函式,介面也是我來寫的),資料庫里冗余欄位的清除,當做性能優化的唯一標準,直到看了那篇文章,
方才大徹大悟,
"優化"二字無非就是用著舒服,一個真正好的PC端專案——應當讓盲人用著也舒服
也就是所謂的能全通過鍵盤來完成一系列的操作,讓所謂的盲人/五六歲的孩子也能簡單的進行專案的操作
讓它就算離開了滑鼠,只有鍵盤仍然能瀟灑運行的專案~
2.甜甜圈,骨架屏,懶加載等一些視覺騙術
-
甜甜圈 loading圖,經久不衰的技術,核心是在介面資料拿到并賦值成功之前,先用一個loading圖進行占位,讓用戶的視覺重點轉移到別的地方,讓用戶感覺你的頁面非常快~

-
骨架屏 個人覺得是甜甜圈的豪華版,只不過看起來更加的絲滑,更加容易接受,因為它沒有過多的切換影片

-
懶加載 實作頁面的按需加載,只有對應的標簽或者圖片等到了用戶的可視區域才進行資料的一個渲染

三、性能構建優化
由于我們使用的是@vue/cli,絕大部分的webpack手腳架已經幫你完成了,我們需要在意的是一些優化配置
1.去除 console.log
俗話說得好,蚊子腿也是肉,少一句算一句,同時為了安全也不應當讓用戶看到這些日志,
//npm i -D terser-webpack-plugin
configureWebpack: config => {
const Terser = require('terser-webpack-plugin')
config.optimization.minimizer.push(
new Terser({
extractComments: false, //編譯時候配置是否提取對應備注,即log日志
terserOptions: { compress: { drop_console: true } },
})
)
}
2.去除 SourceMap
之所以專案要加SourceMap,主要用于除錯,現在代碼都會經過壓碩訓淆,如果代碼報錯,對應的代碼行數資訊將是不對稱的,而sourcemap就是一個資訊檔案,里面存盤著代碼位置資訊,轉換之后報錯和實際代碼位置將會對應,
module.exports = {
productionSourceMap: false,
}
關閉SourceMap的代碼如上所示
3.Gzip 壓縮
此功能壓縮效率非常高,一般來說可以達到三分之二左右的壓縮率(10K變3K),提升非常可觀,一般來說是服務端來做,需要Tomcat或者Nginx等來配合進行使用
專案過大的時候效果顯著,配合Nginx使用Gzip的代碼如下所示
首先是手腳架的配置:
//手腳架搭的專案會有對應的配置,啟動一下就好了
<!--config/index.js-->
productionGzip: true, //是否開啟Gzip壓縮
productionGzipExtensions: ["js", "css"],
然后是打包檔案的配置:
<!--build/webpack.prod.conf.js-->
// 如果在組態檔中開啟了Gzip,則必須要執行對應命令安裝對應插件
// npm install compression-webpack-plugin --save-dev
// 溫馨提示:安裝的時候建議安裝低版本的,防止報錯或不兼容
if (config.build.productionGzip) {
const Compression = require('compression-webpack-plugin')
webpackConfig.plugins.push(
new Compression({
filename: '[path].gz[query]', // 之前這屬性是asset,防止報錯 改成filename
algorithm: 'gzip',
test: new RegExp(
'\\.(' + config.build.productionGzipExtensions.join('|') + ')$'
),
threshold: 10240,
minRatio: 0.8
})
)
}
Nginx:找到Nginx組態檔在 Http 配置里面添加如下代碼,然后重啟Nginx;
http:{
gzip on;
gzip_static on;
gzip_buffers 4 16k;
gzip_comp_level 5;
gzip_types text/plain application/javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg
image/gif image/png;
}
4.Css可優化之處
謹慎使用一些屬性(影片,位移)和選擇器(減少層數嵌套)避免使用text-indent等屬性
因為這些屬性會導致頁面進行大量的回流和重繪,需要很多性能,
- 加載的時候盡量讓其cdn異步加載,盡量不要使用import加載,
因為此種加載方式會阻塞行程,必須加載完畢之后才能繼續向下執行 - 最少量同時正確的使用Css影片:
- 合理使用網路字體(建議部署到Cdn上或者存在本地,防止每次進頁面都請求,可以加載加載速度)
5.Js可優化之處
與css一樣,js的優化也有很多處可以優化的點,只是它比css要更加的繁瑣
- css放在head標簽,js放在body結尾(H5)
- 進行計算的時候要避免使用eval 這種消耗性能的演算法(需要消費相當性能進行轉換型別再進行計算)
- 避免使用js影片 canvas和css3影片的性能要比js優秀得多
- 使用requestAnimationFrame來代替setTimeout和setIntervval,因為requestAnimationFrame可以在正確的時間進行渲染,setTimeout和setInterval無法保證渲染時機,最好不要在定時器里面系結事件,
- 能快取的地方可以考慮用js進行一個暫時快取,優化頁面的回應速度
- 為了減少頁面的回流和重繪,可以把dom操作然后進行統一修改.
總結
總結:
簡單的說了一下前端一些對于性能優化比較大的點,給自己長個記性,便于以后應用這些技術點,
明天,又是充滿希望的一天!
轉載請註明出處,本文鏈接:https://www.uj5u.com/qianduan/274077.html
標籤:其他
