vueマルチページトップページロード最適化

やはり、自分のマルチページブログを例にとると、npm run buildを実行し、パッケージコードをオンラインに配置した後、プロジェクトにアクセスすると、パフォーマンスが悪く、ページが長い間空白になることがわかります.下図に示すように、総負荷時間は12 s近くに達し、これは耐えられない性能問題であり、解決が切実である.
クライアント・ロードの概略図:
管理側ロード概略図
CDN導入vue、vuex、vue-router、vue-momentに対してcdn導入を採用し、またクライアントはhighlightのcdnを導入することもできるが、管理側は必要ない.そのため、2つの異なるテンプレートhtmlが必要で、それぞれ以下のように構成されています.
tpl/index.html
tpl/admin.html

externals: {
    'vue': 'Vue',
    'vue-router': 'VueRouter',
    'vuex': 'Vuex',
    'vue-moment': 'VueMoment',
    'highlight.js': 'hljs',
},

コード分割
Webpackでprod.conf.jsで、CommonsChunkPluginの構成を以下のように変更します.

new webpack.optimize.CommonsChunkPlugin({
      name: 'vendor',
      minChunks (module) {
        return (

          module.resource &&
          /\.js$/.test(module.resource) &&
          module.resource.indexOf(
            path.join(__dirname, '../node_modules')
          ) === 0 && module.resource.indexOf('mavon-editor') < 0
           && module.resource.indexOf('marked') < 0
        )
      }
}),

非同期ロードルーティング
上記の問題では、ルーティング導入方式を非同期導入に変更すると、webpackがパッケージ化されると、非同期ファイルが新しいchunkとして個別にパッケージされ、必要に応じてページにロードされます.管理側を例にとると、修正ルーティング導入方式は非同期導入であり、以下のようになる.

const Catagory = () => import('../pages/Catagory');
const Avator = () => import('../pages/Avator')
const Comment = () => import('../pages/Comment')
const Detail = () => import('../pages/Detail')
const Article = () => import('../pages/Article')

gzip圧縮

    gzip_static on;
    gzip_min_length  5k;
    gzip_buffers     4 16k;
    gzip_comp_level 4;
    gzip_types       text/plain application/javascript text/css application/xml text/javascript application/x-httpd-php;
    gzip_vary on;
    keepalive_timeout  65;

このうちgzip_staticがオンになると、nginxは予め圧縮されたgzファイルを読み出し、gzip圧縮を要求するたびにCPUリソースの消費を減らすことができる.これは、webpackがファイルを圧縮する必要がある理由である.すべての構成の説明は、Nginx Gzipモジュールの有効化と構成命令の詳細を参照してください.nginx;
キャッシュの高速化
プリレンダリング
以上の解決策では、jsリソースのボリュームを縮小してロード速度を速めることが問題となっています.このようなスキームは、ネットワークが良好な場合には、最初のスクリーンレンダリングの速度が十分に速くなりますが、結局、レンダリングはjsロードが完了した後の実行ロジックに依存し、SEOに不利です.では、最初のスクリーンロードをさらに向上させるには2つあります.1つはプリレンダリングです.1つはSSRです.つまり、サービス側レンダリングです.後者のスキームは複雑です.後で分析します.サービス側レンダリングの方法はプリレンダリングよりも、データを動的に接続し、ドキュメントの一部として返すことができ、より友好的なSEOやダイナミックな共有などの機能を実現することができます.私のブログでは、これらの要件がなく、サーバの状況(シングルコア1 GB)を考慮してサーバに負荷をかけたくないため、SSRを考慮せずに、プリレンダリング方式でヘッダ画面のロードをさらに高速化します.プリレンダリングはprerender-spa-pluginプラグインに依存し、まずwebpackで行う.prod.conf.jsでは、次のようにプラグインを導入します.

const PrerenderSPAPlugin = require('prerender-spa-plugin')

次にpluginsに次のプラグイン構成を追加します.

 new PrerenderSPAPlugin(

      path.join(__dirname, '../nginx/blog'),
      ['/'],
      {
        //             ，            
          captureAfterTime: 50000,
          //      
          ignoreJSErrors: true,
          phantomOptions: '--web-security=false',
          maxAttempts: 10,
        }
)

このように構成することで、生成したindexをパッケージ化する.htmlにはプリレンダリングされたdom構造が含まれているため、ファーストスクリーンのレンダリング速度が向上します.ただし、ここでは、非同期ロードされたルーティングパッケージ後のchunkファイルがheadラベルに挿入され、以下のようにasyncのプロパティが付いているという問題に注意してください.

のmanifestファイルはbodyの にあり、asyncは のドキュメント のロードとレンダリングのプロセスと のscriptスクリプトのロードと を に う( )ため、manifestより にscriptスクリプトが され、webpackJsonp is not definedエラーが します.したがって、 にasyncを でdeferに する があります. は、 のドキュメント をロードする で のscriptスクリプトのロードと して われます( です).しかし、 のscriptスクリプトの は、すべての の が した 、DOMContentLoadedイベントがトリガーされる に する があります.これにより、スクリプト のmanifestでの が されます.ここまで して、オンラインに すると、 なトップ を ぶ ができます.
​