こんにちは。鈴木商店の若林 (@itigoore01) です。
今回は鈴木商店で毎月行っている「リリース報告会&自慢大会」で、私が発表した「パフォーマンスチューニングのすゝめ」というスライドをコメントも付け加えながら公開します。
※「リリース報告会&自慢大会」そのものの詳細は、またブログで書きます。
ざっくり説明すると「リリース報告会」はプロジェクトでやっていることやリリースしたプロジェクトについての共有、「自慢大会」は「こんなの作ってみました〜」とかなんでもいいので、発表したい人が好きなことを発表する場です。
はじめに
鈴木商店ではフロントエンドフレームワークとして、Angularをメインで使っています。
なのでAngularを例に上げている箇所がありますが、別にAngularに限った話ではないです。
いい感じに読み替えてください。
パフォーマンスチューニングすべき場合とは？
パフォーマンスチューニングすべき場合とはなにか、ということでよくありそうなパフォーマンス問題をいくつか挙げてみました。
この例のように、使い勝手やユーザー体験に悪影響を与えているものはパフォーマンスチューニングを行うべきだと考えます。
なので、なんらかの対策を打たないといけないということで、対策例も挙げています。
ただこの対策例、正しそうには見えますが……。
上スライドのように、どのような文脈なのかにより、対策例の対策がベストとは言えないことになります。
（こじつけ感がすごいですが、ここは伝えたいことの本質ではないので流してください)
つまり何が言いたいかというと……。
ケースバイケースという、身も蓋もない結論になっちゃいます。
エンジニアにとって、パフォーマンス改善と聞くと、今パフォーマンスが悪い機能を技術力を使ってパフォーマンス改善することが思い浮かびがちですが、本当にそれがユーザーにとってのパフォーマンス改善となるのか？ という視点を持って、ヒアリングなどしていきましょう。
完。
となっちゃうとさすがに内容がペラペラなので、ちゃんとパフォーマンスチューニングのやり方を説明していきます。
前述の視点も含め、これを見ていただいている方が困っていることの助けになれば幸いです。
パフォチューのすゝめ
ちゃんと計測しましょう。
Lighthouseも名前を挙げていますが、ボトルネックとなっている部分を特定するためにはPerformanceを使うのが良いです。
Chromeのツールを挙げていますが、他のブラウザにも似たような機能はあります。
VSとしてますが、用途は全然違います。
先述したとおりボトルネックとなっている部分の特定などはPerformance、SEO向けのパフォーマンスチューニングはLighthouseがいいです。
見せません。
社内では実演して見せたのですが、動画を用意するのが面倒だったので用意できなかったので、公式のドキュメントをご覧ください。
パフォーマンスチューニングに本格的に手を付ける前に、効果計測をしましょう。
Angularに限らず、ReactなどもHTMLっぽく書けたとしてもそれらはDOM操作するコードになります。
それを意識して書きましょう。
特にAngularで言うところの *ngIf のようなものと、CSSの display: none は、見た目的にはほぼ一緒かもしれませんがDOM操作のパフォーマンスと言う意味では雲泥の差があります。
変更検知の話です。
ここはだいぶAngular寄りの話ですが、各フレームワークやライブラリごとにどうやって再レンダリングされるのかは知っておくべきです。
ここもAngular寄りの話ですが、他フレームワークでも通用します。
例えばスクロールやリサイズは大量にイベントが発生するので、イベントを間引くのが有効です。
また大量のリストでは、描画領域前後のみDOM生成を行うような仕組み (Angularだと *cdkVirtualFor) を使うとよいです。
なぜそうなるのかは他の方が説明されているブログを見てもらいたいですが、一般的にposition: absoluteでのアニメーションより transform を使ったほうが速いです。
ページロードの対策方法です。
特にSEOなどに有効ですが、当然ユーザーにとっても恩恵があります。
今度こそ本当に完。
以上です。
これからも公開できるものはブログにあげていこうと思っていますのでよろしくおねがいします。
また鈴木商店ではエンジニアを募集中です。
Wantedlyのページもぜひご覧ください！
