Nodejs in Visual Studio Code 11.前端工程優化

時間 2019-11-24

標籤 nodejs visual studio code 前端工程優化欄目 Visual Studio 简体版

原文原文鏈接

1.開始javascript

　　隨着互聯網技術的發展，企業應用裏處處都是B/S設計，我有幸經歷了不少項目有Asp.Net的，有Html/js的，有Silverlight的，有Flex的。很遺憾這些項目不多關注前端優化的問題，而將全部的100%的對性能關注集中於業務設計、第三方平臺、數據庫等方面，然而我想說只要拿出1%的精力，作一些前端優化的工做，也能夠極大提高系統訪問效率。css

我見過一些項目加載html,js,css,xap等靜態資源用了1~2秒，核心服務2~3秒，最後嘔心瀝血半個月僅能將核心服務優化0.5S，互聯網早已有方案可以一天以內將靜態資源加載優化至0.2S之內。html

　　當掌握這一技能，運用起來又是如此簡單，我只能說在Node.js的幫助下，前端工程師真是碉堡了。前端

2.前端優化java

304 : 當再次訪問一樣資源時，經常返回資源是304的狀態碼，表示資源沒有修改，同時Body爲空，減小了傳輸中使用的帶寬。jquery

　　FromCached ：某些資源會設置MaxAge，這樣瀏覽器會將此資源保存在瀏覽器緩存文件夾中，當再次訪問一樣資源時就再也不訪問。git

　　前端優化的核心就是緩存，首次訪問時將全部靜態資源（js,css）緩存在客戶端，用戶再次訪問站點時，直接從緩存中加載靜態資源，減小HTTP請求，從而加快系統加載的速度。github

304是什麼？數據庫

　　不用有這種擔憂，IIS已經默認幫咱們作好了304規則，打開Fiddler監視IIS下的站點，刷新一下網頁，全部發布在IIS中的靜態文件都是304請求.後端

FromCached是什麼？

　　是一個HTTP響應標頭，在IIS裏面直接設置一下就行了。

304仍是FromCached？

　　FromCached更快，304仍是要訪問網絡，如今網絡帶寬是增長了，可是咱們TCP協議最怕丟包，在丟包率很難繼續優化下去的時候，FromCached簡直打爆304。

開了FromCached如何更新代碼？

　　全部的HTML頁都不該該FromCached緩存，僅緩存js,css。有更新時在HTML中修改引用的地址如

<link href="Assets/Default_5a33cd6.css" rel="stylesheet">

　　因爲每次更新都使用不一樣的靜態資源地址，因此低版本的靜態資源就自動失效了。

　　更進一步的解釋：https://github.com/fouber/blog/issues/6

有沒有自動化的構建工具？

　　咱們系統有幾十個HTML，若是要手動一個個改，這更新頻率，設計這方案會被開發人員噴死啊。幸虧有了FIS。

3.FIS

　　FIS表明一個體系，首先要知足其目錄規範，再進行下一步。

FIS的目錄規範是什麼？

　　開發一個站點通常會引用第三方類庫（jQuery,Bootstrap之類），本身寫一些項目上用的js,css,jpg之類，這些靜態資源須要按照FIS的規範來劃分目錄。

　　不推薦使用FIS來管理第三方類庫，第三方的類庫發佈在統一的靜態站點下。

因此建議你的目錄看起來應該是這樣子的：

　　Assets用來存儲全部本身爲項目寫的css,js,jpg等靜態資源文件，Libs用來存儲第三方的類庫

　　Index.Html應該長這樣

<!DOCTYPE html>
<html>
<head>
    <title></title>
	<meta charset="utf-8" />
    <link href="/Libs/jquery-1.12.3.min.js" rel="stylesheet" />
    <link href="/Assets/Index.css" rel="stylesheet">   
    <link href="/Assets/Index.js" rel="stylesheet"/>    
</head>
<body>

</body>
</html>

配置FIS發佈程序

　　將站點發布出來，並配置fis-conf.js文件

fis.config.init({
    project: {
        md5Length: 7
    }
});

fis.config.merge({
    roadmap: {
        path: [
            {
                //查找全部Assets目錄下的全部文件
                reg: /^\/Libs\/(.*)/i,
                //生成新的url '/Static/xxxx'
                url: '/Static/$1',
                //指定文件不產出MD5戳
                useHash: false,
                release: '/Static/$1'
            },
            {
                //查找全部Assets目錄下的js,css,png文件
                reg: /^\/Assets\/(.*\.(?:js|css|png))/i,
                //生成新的url '/myappAssets/xxxx'
                url: '/myappAssets/$1',
                //js/css/png打上md5標記生成到/myappAssets/xxx目錄下
                release: '/myappAssets/$1'
            },            
            {
                //全部根目錄下的.html文件
                reg : /^(.*\.html)/i,
                //發佈到/myapp/xxx目錄下
                release : '/myapp/$1'
            },
            {
                //前面規則未匹配到的其餘文件
                reg: /.*/,
                //編譯的時候不要產出了
                release: false
            }
        ]
    }
});

　　打開CMD定位到目錄並執行命令

fis release --md5 --dest ../output

　　項目被輸出到../output目錄中

　　url地址自動改好了，本身寫的index.js和index.css的MD5碼已自動加好，第三方類庫並無加上MD5碼，一切OK，發佈吧。

　　如今能夠爲全部動態文件創建緩存而不用擔憂更新問題了。

4.結束

　　FIS很好用，然而咱們項目面臨的問題仍然複雜，項目上系統加載框架使用iframe了，將致使第三方類庫反覆加載，爲了不反覆加載這種狀況須要將其重構爲多頁HTML的SOE框架，然而使用多頁總不能反覆Copy header和menu的html代碼吧，固然你可使用後端渲染引擎如swig，幸運的是grunt+FIS能夠輕鬆的幫你搞定這個問題並避免使用後端渲染引擎，如何使用Swig+Grunt來重構iframe項目能夠參考我之前的一篇博文：