フロントエンドパフォーマンスチューニングのすすめ 【リリース報告会&自慢大会】

2020年09月25日
dougu_mark_spanner_hammer_cross

こんにちは。鈴木商店の若林 (@itigoore01) です。

今回は鈴木商店で毎月行っている「リリース報告会&自慢大会」で、私が発表した「パフォーマンスチューニングのすゝめ」というスライドをコメントも付け加えながら公開します。
※「リリース報告会&自慢大会」そのものの詳細は、またブログで書きます。
ざっくり説明すると「リリース報告会」はプロジェクトでやっていることやリリースしたプロジェクトについての共有、「自慢大会」は「こんなの作ってみました〜」とかなんでもいいので、発表したい人が好きなことを発表する場です。

スライド全体のPDFはこちら


はじめに

フロントエンド パフォーマンス チューニング - 公開用 (1)

鈴木商店ではフロントエンドフレームワークとして、Angularをメインで使っています。
なのでAngularを例に上げている箇所がありますが、別にAngularに限った話ではないです。
いい感じに読み替えてください。

パフォーマンスチューニングすべき場合とは?

フロントエンド パフォーマンス チューニング - 公開用 (2)

パフォーマンスチューニングすべき場合とはなにか、ということでよくありそうなパフォーマンス問題をいくつか挙げてみました。
この例のように、使い勝手やユーザー体験に悪影響を与えているものはパフォーマンスチューニングを行うべきだと考えます。

なので、なんらかの対策を打たないといけないということで、対策例も挙げています。
ただこの対策例、正しそうには見えますが……。

フロントエンド パフォーマンス チューニング - 公開用 (3)

上スライドのように、どのような文脈なのかにより、対策例の対策がベストとは言えないことになります。
(こじつけ感がすごいですが、ここは伝えたいことの本質ではないので流してください)
つまり何が言いたいかというと……。

フロントエンド パフォーマンス チューニング - 公開用 (4)

ケースバイケースという、身も蓋もない結論になっちゃいます。

フロントエンド パフォーマンス チューニング - 公開用 (5)

エンジニアにとって、パフォーマンス改善と聞くと、今パフォーマンスが悪い機能を技術力を使ってパフォーマンス改善することが思い浮かびがちですが、本当にそれがユーザーにとってのパフォーマンス改善となるのか? という視点を持って、ヒアリングなどしていきましょう。

フロントエンド パフォーマンス チューニング - 公開用 (6)

完。

フロントエンド パフォーマンス チューニング - 公開用 (7)

となっちゃうとさすがに内容がペラペラなので、ちゃんとパフォーマンスチューニングのやり方を説明していきます。
前述の視点も含め、これを見ていただいている方が困っていることの助けになれば幸いです。

パフォチューのすゝめ

フロントエンド パフォーマンス チューニング - 公開用 (8)

ちゃんと計測しましょう。
Lighthouseも名前を挙げていますが、ボトルネックとなっている部分を特定するためにはPerformanceを使うのが良いです。
Chromeのツールを挙げていますが、他のブラウザにも似たような機能はあります。

フロントエンド パフォーマンス チューニング - 公開用 (9)

VSとしてますが、用途は全然違います。
先述したとおりボトルネックとなっている部分の特定などはPerformance、SEO向けのパフォーマンスチューニングはLighthouseがいいです。

フロントエンド パフォーマンス チューニング - 公開用 (10)

見せません。
社内では実演して見せたのですが、動画を用意するのが面倒だったので用意できなかったので、公式のドキュメントをご覧ください。

フロントエンド パフォーマンス チューニング - 公開用 (11)

パフォーマンスチューニングに本格的に手を付ける前に、効果計測をしましょう。

フロントエンド パフォーマンス チューニング - 公開用 (12)

Angularに限らず、ReactなどもHTMLっぽく書けたとしてもそれらはDOM操作するコードになります。
それを意識して書きましょう。
特にAngularで言うところの *ngIf のようなものと、CSSの display: none は、見た目的にはほぼ一緒かもしれませんがDOM操作のパフォーマンスと言う意味では雲泥の差があります。

フロントエンド パフォーマンス チューニング - 公開用 (13)

変更検知の話です。
ここはだいぶAngular寄りの話ですが、各フレームワークやライブラリごとにどうやって再レンダリングされるのかは知っておくべきです。

フロントエンド パフォーマンス チューニング - 公開用 (14)

ここもAngular寄りの話ですが、他フレームワークでも通用します。

例えばスクロールやリサイズは大量にイベントが発生するので、イベントを間引くのが有効です。

また大量のリストでは、描画領域前後のみDOM生成を行うような仕組み (Angularだと *cdkVirtualFor) を使うとよいです。

フロントエンド パフォーマンス チューニング - 公開用 (15)

なぜそうなるのかは他の方が説明されているブログを見てもらいたいですが、一般的にposition: absoluteでのアニメーションより transform を使ったほうが速いです。

フロントエンド パフォーマンス チューニング - 公開用 (16)

ページロードの対策方法です。
特にSEOなどに有効ですが、当然ユーザーにとっても恩恵があります。

フロントエンド パフォーマンス チューニング - 公開用 (17)

今度こそ本当に完。


以上です。
これからも公開できるものはブログにあげていこうと思っていますのでよろしくおねがいします。

また鈴木商店ではエンジニアを募集中です。
Wantedlyのページもぜひご覧ください!


コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です