<h2 id="はじめに">はじめに</h2>
年末年始にこの技術ブログを GatsbyJS から Next.js にリプレースを行っていました。その影響でLighthouseのパフォーマンス結果が低下してしまったので、原因の調査と改善を実施しました。
<img src="/images/posts/nextjs-perf-improvement/lighthouse-result.jpg" alt="改善前のLighthouseの結果" width="1522" height="676" />
<h2 id="原因調査">原因調査</h2>
<h3 id="Lighthouseの結果を考察">Lighthouseの結果を考察</h3>
Lighthouseの詳細を見てみると 722.4kb という巨大なJSファイルが配信されていました。「Potential Saving 99.8kb」とあるように、このJFファイルの中の大部分が未使用コードになっています。
<img src="/images/posts/nextjs-perf-improvement/lighthouse-unused-js.png" alt="未使用なJavaScript" width="735" height="385" />
また巨大なjsファイルによりJavaScriptの「Script Evaluation」が 1,835ms と、長時間のレンダリングブロッキングが発生していました。
<img src="/images/posts/nextjs-perf-improvement/lighthouse-thread-work.png" alt="メインスレッドの実行時間" width="717" height="406" />
<h3 id="Webpack Bundle Analyzer">Webpack Bundle Analyzer</h3>
先ほどのLighthouseの結果で問題になっていた、巨大なjsファイルは chunks/pages/post/[slug]-xxx.js でした。これは記事の詳細ページでNext.jsのビルドにより生成されたファイルです。このファイルにバンドルされているモジュールを調査して、jsファイルが巨大化している原因を特定します。
Next.jsは内部でビルドにWebpackを利用しているので、<a href="https://github.com/webpack-contrib/webpack-bundle-analyzer" target="_blank">webpack-contrib/webpack-bundle-analyzer</a> を使うことで、生成されたJSファイルのバンドル情報を可視化することができます。
Next.js のプラグインとして <a href="https://github.com/vercel/next.js/tree/canary/packages/next-bundle-analyzer" target="_blank">@next/bundle-analyzer</a> が提供されているので、今回はこちらを導入していきます。
最初にパッケージをインストールします。
<pre class="language-bash"><code class="language-bash">$ yarn add -D @next/bundel-analyzer
</code></pre>
続いて Next.config.js にプラグインを利用する設定を書いていきます。 
環境変数として <code>ANALYZE=true</code> が指定されていた時だけ、bundle-analyzer を実行するようにしています。
<pre class="language-javascript"><code class="language-javascript">const withBundleAnalyzer = require('@next/bundle-analyzer')({
 enabled: process.env.ANALYZE === 'true',
});

const config = {
 // 省略
};

module.exports = withBundleAnalyzer(config);
</code></pre>
次のように実行することで確認ができます。
<pre class="language-bash"><code class="language-bash">$ ANALYZE=true next build
</code></pre>
今後のことも考えて実行コマンドは package.json に登録しておきます。
<pre class="language-json"><code class="language-json">{
 "scripts": {
 "bundle-analyzer": "ANALYZE=true next build"
 }
}
</code></pre>
<h3 id="Webpack Bundle Analyzer の結果を考察">Webpack Bundle Analyzer の結果を考察</h3>
webpack-bundle-analyzer を実行することで、ビルド中にブラウザに可視化された情報が表示されます。 
可視化された結果をみてみると <a href="https://github.com/wooorm/refractor" target="_blank">refractor</a> というモジュールが大部分を占めており、このモジュールの読み込みが今回の問題の原因となっていそうです。
<img src="/images/posts/nextjs-perf-improvement/bundle-analyzer-result.png" alt="bundle-analyzerの結果" width="2876" height="1532" />
<code>yarn.lock</code> を参照すると、 <code>refractor</code> は <a href="https://github.com/react-syntax-highlighter/react-syntax-highlighter" target="_blank">react-syntax-highlighter/react-syntax-highlighter</a> から読み込まれていることが分かりました。
<pre class="language-yaml"><code class="language-yaml">react-syntax-highlighter@^15.4.3:
 version "15.4.3"
 resolved "https://registry.yarnpkg.com/react-syntax-highlighter/-/react-syntax-highlighter-15.4.3.tgz#fffe3286677ac470b963b364916d16374996f3a6"
 integrity sha512-TnhGgZKXr5o8a63uYdRTzeb8ijJOgRGe0qjrE0eK/gajtdyqnSO6LqB3vW16hHB0cFierYSoy/AOJw8z1Dui8g==
 dependencies:
 "@babel/runtime" "^7.3.1"
 highlight.js "^10.4.1"
 lowlight "^1.17.0"
 prismjs "^1.22.0"
 refractor "^3.2.0"
</code></pre>
これでパフォーマンス問題の原因が特定できたので、残りはこの問題を改修していきます。
<h2 id="パフォーマンス改善">パフォーマンス改善</h2>
<code>reflactor</code> には、シンタックスハイライトで利用する言語ごとのjsファイルが含まれており、それらが初回レンダリングのタイミングで全て読み込まれることで、パフォーマンス低下を引き起こしていました。<code>react-syntax-highlighter</code> は動的インポートにも対応しているので、今回は動的インポートによりレンダリングブロックをしないように修正をします。
ただ、最終的に読み込むファイルの転送量が多いことに変わりないので、将来的には別のアプローチで解決したいです。
<pre class="language-typescript"><code class="language-typescript">// import { Prism as SyntaxHilighter } from 'react-syntax-highlighter';
import { PrismAsync as SyntaxHilighter } from 'react-syntax-highlighter';
</code></pre>
動的インポートに変更した後の bundle anlyzer の結果をみると、 <code>refractor-import.xxx.js</code> として <code>refractor</code> の読み込みが新しいチャンクとして切り出されています。<code>[slug]-xxx.js</code> のファイルサイズ も 722.4kb から 216.54kb に削減されています。
<img src="/images/posts/nextjs-perf-improvement/dynamic-import-bundle-analyzer-result.png" alt="動的インポートのbundle-analyzerの結果" width="1514" height="1356" />
修正後の <code>[slug]-xxx.js</code> の中身を見てみると、新たに別の問題が見えてきました。<code>react-syntax-highlighter</code>が全てのテーマファイルを読み込んでいます。
<img src="/images/posts/nextjs-perf-improvement/bundle-analyzer-result-slug.png" alt="[slug]-xxx.jsのbundle-analyzerの結果" width="2876" height="1530" />
この読み込みも不要なので、必要なテーマファイルだけを読み込むように修正します。
<pre class="language-typescript"><code class="language-typescript">// import { vscDarkPlus as defaultVscDarkPlus } from 'react-syntax-highlighter/dist/cjs/styles/prism';
import defaultVscDarkPlus from 'react-syntax-highlighter/dist/cjs/styles/prism/vsc-dark-plus';
</code></pre>
最終的に <code>[slug]-xxx.js</code> のファイルサイズが 722.kb から 106.5kb と1/7のサイズ削減できました🎉 
これでレンダリングブロッキングの時間が大幅に削減されるので、Ligthouseのパフォーマンス結果も改善されます。
<img src="/images/posts/nextjs-perf-improvement/bundle-analyzer-finally.png" alt="最終的なbundle-analyzerの結果" width="1698" height="1492" />
<h2 id="さいごに">さいごに</h2>
今回は1番大きな問題を対象として改善策を実施しましたが、画像の最適化や画像の遅延ロード、その他の不要なJavaScriptファイルの削除と改善項目はまだまだ沢山あります。また、Next.jsのリプレースによって新しく導入したライブラリにより意図せずにパフォーマンス低下が起きてしまったので、今後は <a href="https://github.com/GoogleChrome/lighthouse-ci" target="_blank">GoogleChrome/lighthouse-ci</a> などを導入して継続的にパフォーマンスなどを計測する仕組みを用意していきたいです。

年末年始にこの技術ブログを GatsbyJS から Next.js にリプレースを行っていました。レプレースを実施した結果、Lighthouseのパフォーマンス結果が低下してしまったので、原因の調査と改善を実施しました。

Next.jsで作ったブログのパフォーマンス改善

神奈川の田舎で働いてるフロントエンドエンジニアのブログ