題主，你可以透過build設定先不做壓縮，看看裡面的程式碼長啥樣。

你標籤寫著vue，從我接觸過的vue demo來說吧。 首先一個vue項目，肯定要用到vue的，其次是這個項目頁面的js，也就是怎麼實例化vue並寫出業務來。

如果是傳統的jquery開發模式，一個頁面至少也是要包含兩個js，一個是jquery的，一個是頁面業務的。

回到app，vendor，manifest這三者，貼一下之前vue腳手架的webpack配置

new webpack.optimize.CommonsChunkPlugin({
      name: 'vendor',
      minChunks: function (module, count) {
        // any required modules inside node_modules are extracted to vendor
        return (
          module.resource &&
          /\.js$/.test(module.resource) &&
          module.resource.indexOf(
            path.join(__dirname, '../node_modules')
          ) === 0
        )
      }
    }),
    // extract webpack runtime and module manifest to its own file in order to
    // prevent vendor hash from being updated whenever app bundle is updated
    new webpack.optimize.CommonsChunkPlugin({
      name: 'manifest',
      chunks: ['vendor']
    })

app.js是入口js，vendor則是透過提取公共模組插件來提取的程式碼區塊（webpack本身帶的模組化程式碼部分），而manifest則是在vendor的基礎上，再抽取出要經常變動的部分，例如關於非同步載入js模組部分的內容。

從截圖來看也看出，vendor的檔案大小最大，因為其包含了vue整一個框架的程式碼，以及webpack的模組化程式碼。

至於manifest的話，主要是一些非同步載入的實作方法（透過建立script方式動態引入js），內容上包含非同步js的檔案名稱和路徑。

之前查過一些資料，主要是js的改動會改變異步加載裡面的js檔名，頻繁的變動，而相對來說vue庫之類的程式碼，實際上只要編譯打包一次就夠了，如果只是打包成一個vendor的話，經常變動js會導致vendor重複編譯，有點浪費，所以把會重複跟著變動的部分抽離出來當作manifest檔。

這是我的個人理解，有問題請指正哈

@Dont 說的大部分都對,有幾個點覺得要改改:1，CommonsChunkPlugin 抽取的是公共部分而不是"經常變動的部分";2,觀察了一下，webpack應該是會在最後一個CommonsChunkPlugin產出的chunk注入webpackJsonp的定義,以及非同步載入相關的定義,而就是這個會涉及到所有entry及chunk的md5,所以會"經常變動"，同時vue-cli默認的vendor是打包node_module下的所有依賴，會很大，在生產環境，過大的文件要盡量利用緩存來加快載入速度，但「經常變動」不利於緩存，所以為了將entry(這裡可認為是app.js )的變動隔離在vendor之外，vue-cli在vendor之後多做了一個manifest的chunk,這樣entry只要不引入新的node_modules裡的包就不會影響到vendor了.ps:所以其實跟編譯次數沒什麼關係,所有文件每次打包都會再編譯一次的,重點是大文件，緩存，變動代碼的拆分.

以下說明僅依照vue-cli全家桶預設設定解讀，如有錯誤，請指出：
app.js：基本上就是你實際寫的那個app.vue(.vue或.js?),沒這個頁面跑不起來.
vendor.js:vue-cli全家桶預設要配置裡面這個chunk就是將所有從node_modules/裡require(import)的依賴都打包到這裡，所以這個就是所有node_modules/下的被require(import)的js檔
manifest.js: 最後一個chunk，被注入了webpackJsonp的定義及異步加載相關的定義(webpack調用CommonsChunkPlugin處理後模組管理的核心,因為是核心,所以要第一個進行加載,不然會報錯).

精簡:由於預設的vendor的打包策略導致這個chunk很大,按照預設配置這基本沒什麼好精簡了,要精簡的話基本要針對項目實際來修改各個chunk的打包策略(盡量減少包的大小來提速首螢幕加載)

優化:單頁面基本上就跟精簡同個道理吧,多頁面的話感覺還是自定義一下vendor的打包策略,畢竟不一定所有頁面都會用到全量的第三方依賴，適當減少vendor的體積能提高不少加載速度.