效能優化是程式開發中乙個永恆的話題，在當前全民**的大環境下，低端機型、弱網環境、頻寬限制依然占有市場很大的份額，前端頁面的快速呈現，不僅影響使用者的使用體驗，對使用者的閱讀深度、停留時長等都有比較深遠的影響。而在前端渲染優化中最重要的乙個是首屏渲染優化。把內容最快的呈現給使用者，提供及時的可互動方式，對我們來說至關重要。
一、首屏效能檢測工具
1、lighthouse，你可以使用兩種方式執行lighthouse，作為 chrome 擴充套件程式執行，或作為命令列工具執行。執行結束會給你提供一些效能建議
2、puppeteer，無頭瀏覽器，是乙個沒有檢視層的谷歌瀏覽器，它暴露開發者工具的可程式設計介面，比如說網路狀況，模擬裝置，**覆蓋率。
二、首屏效能指標
可互動時間 (tti)：使用者第一次可以和介面進行互動的時間
慢會話 long tasks：rail有在100毫秒內相應使用者輸入的要求。如果響應超過這個時間就是慢會話
* 幀率的計算
*/var frame = 0;
var allframecount = 0;
var lasttime =date.now();
var lastfametime =date.now();
var loop = function
() ;
window.requestanimationframe(loop);}
loop();
**網頁用到的首屏優化策略：
1、cdn邊緣計算：rendertohtmlstring，cdn預渲染
2、資源請求優化：頁面預快取，利用了端側提供的靜態資源快取方案，將html和基礎js等資源，推送下發至客戶端；模組資源快取，模組的js+css資源，因為不同頁面所使用的模組不同（例如**會場和家裝會場），並且總計有上百個模組，無法做到全量的提前快取。這裡我們通過撈取top流量頁面的方式，僅將首屏相關的核心模組做了模組快取下發，較好的緩解了模組請求的耗時；模組按需載入，除了剛提到的模組快取下發，今年的618會場還通過「模組按需載入」的優化方式，最小化的控制了當前頁面的模組數量，這對首屏的js資源請求、資料請求都有一定的縮減。在實現方案上，通過在資料閘道器層先讀取服務端所快取的定向投放條件，判斷當前訪問的url引數、客戶端資訊等是否滿足模組的展示條件（例如，搜尋框模組僅在手淘內才展示）。不滿足條件時，則直接從頁面中移除這一模組。例如，在外部瀏覽器裡開啟618超酷數碼會場時，頁面所載入的js資源大小可因此減少40+%。
3、降級策略：低端機、老系統，適當減少一些模組
4、拆分頁面：首先載入關鍵模組、非關鍵模組放入lazyqueue，在onload再載入；懶執行（互動執行），tab模組在hover或click的時候再執行；更懶的執行，一些非關鍵的資訊在第一訪問請求，並快取，在第二次訪問的時候才顯示。
5、快取策略：低頻修改模組快取，設定過期時間；
7、其它
Vue首屏載入優化
vue首屏載入優化 單頁面應用的乙個問題就是首頁載入東西過多，載入時間過長。特別在移動端，單頁面應用的首屏載入優化更是繞不開的話題。下面我會寫出我在專案中做的一些優化，希望大家能夠相互討論，共同進步。分析載入慢問題 1.webpack bundle analyzer 分析 首頁我們來看看沒有經過任何...
App首屏介面效能優化
我們服務端rpc框架採用restful，其底層是curl實現的。curl採用http協議的，另外我們服務端的技術棧是php。我們都知道http協議相比較tcp而言，不僅多了http的報頭，php本身效能也是大問題。在不做大重構的情況下，怎麼做最小的修改，完成最大的效能提高。還是很有挑戰性的。針對首屏...
css vue 引入cdn VUE首屏優化方案
前言 我的專案是vue cli3構建的，vue vuex vue router axios element ui，隨著模組不斷增多，專案 越來越臃腫，打包上傳後，瀏覽器清除快取後開啟的速度變得很慢，對我這種急性子來說簡直不能忍。f12檢視network，發現有乙個chunk vendors.js的檔...