效能提公升：
又拍雲針對html/css/js，預設開啟gzip壓縮，壓縮比率大約70%（這裡也可以自行設定，畢竟gz解析也耗時），cdn快取時間可自行配置；這一點就解決了前兩項；
有關資源合併和壓縮多是為了減少http請求和減少傳輸量，這個視專案設定；
用的是webpack配置好的模板：
assetspublicpath：「」//你的cdn伺服器複製**new webpack.optimize.commonschunkplugin(複製**output: ,複製**複製**懶載入比較簡單就不說了；
重點說一下js的懶載入，也就是webpack的**分割；
這裡webpack將spa頁面的template和script還有style轉換成js；
個人理解：js引擎的執行速度比內容引擎執行速度快；
在即將進入spa頁面才會請求js，這裡僅需要更改路由就可以完成；
其他的小點：css公共部分提取，js共同部分提取我就不寫了；
這樣大致的前端架構
圖只畫了一半
大致是首次請求：客戶端輸入url---》服務區查詢html---》返回html到客戶端---》客戶端構建dom樹---》客戶端請求cdn伺服器---》cdn伺服器查詢js/css/img---》返回js/css/img到客戶端---》客戶端重新構建dom樹/css樹---》客戶端js傳送資料請求---》伺服器查詢資料庫---》伺服器返回資料到客戶端---》客戶端js接收資料---》客戶端構建css樹---》客戶端檢視更新
非首次請求：客戶端輸入url---》伺服器查詢html---》返回html到客戶端---》客戶端構建dom樹--》命中快取？使用客戶端js/css/img：使用cdn上img---》客戶端重新構建dom樹/css樹---》客戶端傳送資料請求---》命中快取？
快取這塊，js/css/img的etag和過期時間導致了是否重新請求
現在突然發現，沒有考慮cdn快取和http快取，不過這個在我專案不存在，在某些jsp混亂的專案中存在。。。
看了一下公司使用裝置的統計資料；超大屏手機佔據多大多數；
看了一下公司裝置的統計資料，各款產品android和ios各有千秋；
對了還有相容性設定，推薦使用npx檢視，這裡我設定的是；
"browserslist": [ "last 7 version", "> 1%", "ios >= 7", "android >= 3.2" ]複製**也就是說，命令列輸入npx browserslist可以檢視自己對哪些瀏覽器做了相容性設定；
複製**
我最早有個坑就跳到了這裡，最後沒跳出去，當時專案廢了，僅設定了幾款瀏覽器。。。。（??????）
不過警惕，這裡僅僅是針對css加了相容頭和相容寫法，而且是針對常見特性；
其實開發相容性很重要，js相容性雖然越來越少，但是不容小覷，當然更重要的是要有款測試機，能隨時除錯，我當時苦逼到上線才見到產品，所以一定要學會自己打包和除錯；
抽空寫篇除錯的文章。。。
抽空會把圖給完善一下。。。
希望能有美食能給我動力。。。
提公升軟體效能
提高系統的安全性和健壯性，資料庫伺服器和應用伺服器,就要考慮冗餘設計。保證系統的高可用和高可靠以及高併發。保證系統在出現故障時,及時切換正常工作,使用雙機熱備份。使用redis快取伺服器提高系統的效能。使用讀寫分離技術減輕資料訪問的壓力,提公升系統的使用者體驗。在資料庫的設計上來使用分庫 分表 分割...
提公升頁面效能
1.資源壓縮合併，減少http請求 2.非核心 非同步載入 非同步載入的方式 a.動態指令碼載入 b.defer c.async defer 在html解析完成之後才會執行，並按照載入順序執行 async 在載入完成之後立即執行，和載入順序無關。3.利用瀏覽器快取 快取的分為強快取和協商快取 強快取...
效能繼續提公升
嘿嘿，今天改bug，又發現了乙個效能問題。在顯示所有bug列表的列印頁面下，顯示800個bug居然要花26s的時間，看上去已經是另人難於忍受了。在顯示測試報告頁面，由於不需要顯示bug列表，因此，成績從18s一下子提公升到了0.8s，現在這個列印頁面需要將所有的bug都列印出來，需要顯示所有的bug...