この記事は<a href="https://qiita.com/advent-calendar/2022/yamap-engineers" target="_blank">YAMAP エンジニア アドベントカレンダー2022</a> 14日目の記事です。
業務でReactで実装されたフォームのパフォーマンス改善をしたので、その時の問題を一般化してパフォーマンス改善を体験できる練習問題を作ってみました。
<h2 id="練習問題">練習問題</h2>
Reactで<code>&lt;input&gt;</code>要素がリストで表示されており、<code>&lt;input&gt;</code>要素にテキストを入力してみると非常にレスポンスが遅い状態になっています。このレスポンス速度を改善するのが今回の問題です。
<iframe src="https://stackblitz.com/edit/react-ts-evcw6y?embed=1&file=src/App.tsx" style="width: 100%; height: 400px"></iframe>
ソースコードを眺めてみるとApp.tsxでTodoの一覧を管理しており<code>TotoList</code>コンポーネントを描画しています。 
<code>onChange</code>propsには<code>setTodos</code>を渡しておりTodoの一覧を更新します。
<pre class="language-tsx"><code class="language-tsx">// App.tsx
const initialTodos: TodoModel[] = [...Array(100)].map((_, i) => ({
 id: i,
 text: 'aaa',
}));

const App = () => {
 const [todos, setTodos] = useState(initialTodos);

 return (
 &lt;div>
 &lt;button
 onClick={() => {
 alert(todos[0].text);
 }}
 >
 保存
 &lt;/button>
 &lt;TodoList todos={todos} onChange={setTodos} />
 &lt;/div>
 );
};
</code></pre>
次に<code>TodoList</code>コンポーネントの実装を見てみます。
<code>TodoList</code>では<code>&lt;input&gt;</code>要素として<code>Todo</code>コンポーネントを描画しており、変更があったときに新しい<code>Todo</code>のオブジェクトを受け取り新しいTodoリストを引数としてpropsで渡された<code>onChange</code>コールバック関数を実行して、親要素に新しいTodoリストを渡しています。
<pre class="language-tsx"><code class="language-tsx">export const TodoList: FC&lt;TodoListProps> = ({ todos, onChange }) => {
 const handleChange = useCallback(
 (updatedTodo: TodoModel) => {
 const index = todos.findIndex((todo) => todo.id === updatedTodo.id);
 onChange?.([
 ...todos.slice(0, index),
 updatedTodo,
 ...todos.slice(index + 1),
 ]);
 },
 [onChange, todos]
 );

 return (
 &lt;ul>
 {todos.map((todo) => {
 return (
 &lt;li key={todo.id}>
 &lt;Todo todo={todo} onChange={handleChange} />
 &lt;/li>
 );
 })}
 &lt;/ul>
 );
};
</code></pre>
最後に<code>Todo</code>コンポーネントの実装を見てみます。
<code>Todo</code>コンポーネントではpropsで受け取った<code>todo</code>のテキストの内容を<code>&lt;input&gt;</code>要素のvalueとして表示しています。テキストが変更された時に新しいテキストでTodoオブジェクトを作成して<code>onChange</code>関数を実行して親要素に新しいTodoオブジェクトを渡しています。
<code>[...Array()]</code>はコンポーネントの描画速度を疑似的に遅くするために仕込んでいます。は問題を作成するための疑似コードなので、ここを削除しないでください。
<pre class="language-tsx"><code class="language-tsx">export const Todo: FC&lt;TodoProps> = memo(({ todo, onChange }) => {
 [...Array(100000)].forEach(() => 1 + 1);

 return (
 &lt;input
 type="text"
 defaultValue={todo.text}
 onChange={(evt) => {
 onChange({
 ...todo,
 text: evt.target.value,
 });
 }}
 />
 );
});
</code></pre>
このコンポーネント単体の描画速度は約10msほどになっており、実際の実装でも再現し得る問題になっています。
<img src="/images/posts/react-performance-question/profile.png" alt="プロファイルの結果" width="1136" height="462" />
<h2 id="解説">解説</h2>
問題の解答は別の記事で書こうと思います。 
興味があれば解いてみてください。

業務でReactのパフォーマンス改善をする機会があったので問題を一般化して練習問題を作ってみました

Reactのパフォーマンス改善を体験できる練習問題を作ってみた

<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で作ったブログのパフォーマンス改善

とあるフロントエンドエンジニアのブログ

パフォーマンスの記事一覧

Reactのパフォーマンス改善を体験できる練習問題を作ってみた

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