00:03
はい、12月5日月曜日ですね。 時刻は朝9時を回りました。
今日の東京は一気に寒くなりますね。 最低気温3度とか言うてるので、もうガチガチ
冬になってくるなという感じですね。 はい、おはようございます。ひめみのきーつくとくわはらです。
では本日も朝活をやっていきたいとおもいます。 本日も昨日に引き続き、ウェブパフォーマンスチューニング70選の記事ですね。
読んでいきたいなぁと思っています。 昨日でhtml、css編が終わったってことですね。
画像コンテンツをなるべく避けたりとか、 そもそも読み込むファイル数を減らしたりとか、
サードパーティーのライブラリーを使って 読み込み速度とかを変えたりするとか、いろんなものがありましたね。
この辺のテクニックを一個一個皆さんも見てみていただければと思いますし、 一個一個自分の手元で試してみるのもいいかもしれないですね。
では今日は続きから、ブラウザーAPI編ですね。
1個だけ謝罪というか、もしかしたら可能性あるんですけど、 僕が昨晩スマホの充電をし忘れてですね、今バッテリーが残りますから、
もしかしたら突然落ちるかもしれないです。 その際はちょっとご了承いただければ幸いです。
では早速入っていきたいと思います。 プテラノゾさんですね。おはようございます。ご参加ありがとうございます。
今日もダラダラ読んでいこうと思ってます。 ではいきましょう。ブラウザーAPI編の一つ目ですね。
永続化ストレージというものはローカルストレージではなくて、 インデックスとDBを使いましょうというところです。
ブラウザーの永続化ストレージにはですね、 ローカルストレージとインデックスDBは2つあって両方使えるんですけど、
ローカルストレージってのは基本的に同期的、 インデックスDBは非同期処理になりますので、
インデックスDBの方がブラウザーの動きを阻害することなく データアクセスができるというところで、
ノンブロッキングがあったというところで、 インデックスDBがいいんじゃないのというお話でした。
手軽に使えるという意味ではローカルストレージもいいんですけどね。
なおかつ、そんな言うほどローカルストレージに何かデータを 大量に持たせるということはそうそうないと思いますので、
別に僕はローカルストレージもいいと思いますけどね。
それほどブロッキングするような処理ってあんまないと思いますので。
とはいえそのちょっとのブロッキングとか、
JSの制御とか処理が変わってきたりするっていうのが嫌なっていう人は、 別にインデックスDBで非同期にやるのがいいんじゃないかなと思ったりしてました。
では続きまして、重たい処理とかUIに依存しない処理というのは Webワーカーを使いましょうということですね。
Webワーカーを使うことで、 ブラウザーのメインスレッドとは別のスレッドを立ち上げることができますと。
フロントで例えば検索機能であったりとか重い処理であったり、 エラーをサーバーに送信するというとUIに依存しないような処理というのがあると思いますけど、
そういうようなWebワーカーを使うことで、 そのメインスレッドの処理を阻害させませんみたいなことができるので、 Webワーカーおすすめですよということでした。
そうなんですね。
UIに依存しない処理、 Webワーカーに全然処理投げることができるのであれば、 確かにそれはいいかもしれないですね。
基本的にはブラウザーはレンダリングする、 見た目のレンダリングのところに処理を、重きを置きたいところであるので。
なるほどでした。
では続いて、サービスワーカーでリソースをキャッシュするっていうところですね。
03:02
サービスワーカーを使えば、PWAですね、 プログレッシブウェブアプリケーションなどのイメージが強いんですけども、
ブラウザから外部サーバーへのリクエストをフックして、 HTML、JS、JavaScriptなどのリソースをキャッシュすることもできますよと。
リクエストする際はキャッシュから取得することができるので、 外部サーバーへのリクエストをするよりも処理が早くなります。
またキャッシュから取得するか、先にサーバーへのデータを取得してから キャッシュするかなど、柔軟なキャッシュ戦略も選択できるので、
サービスワーカーとか、お勧めですよということでした。
まずキャッシュって言ってる時点で、 初期レンダリングはしょうがないと思いますので、2回目以降ということですね。
では続いて、サービスワーカーを使うときは、 ナビゲーションプリロードも使いましょうと言ってますね。
サイトにアクセスしたときに、必要なリソースをフェッチするときには、 サービスワーカーが起動するのを待ってフェッチする処理が始りますと。
ナビゲーションプリロードっていうものを使うと、 サービスワーカーの起動を待たずにフェッチ処理を開始することができますよと。
なので、サービスワーカーを使うときは、 ナビゲーションプリロードっていうのもセットで使うと、
待たずに走らせることができるよというお話でした。
僕もこれを初めて知りましたね。
これなんか勉強になる。
それについての詳しい記事がWebDevの方にもありますので、 それも見てみてくださいということでした。
あんまりサービスワーカーを使ってキャッシュ戦略を ガリガリやったことは僕もなかったので、ここはちょっと勉強になりますね。
では続いて、ウェブアセンブリーを使いましょうと。
これはなんとなくわかりますけど、
JavaScriptだけでなく、 CとかRustで書いたコードがブラウザで実行できて、
JavaScriptよりも高速化される場合がありますので、 使ってみてくださいと。
Amazonの事例もありますというところで、 Amazonの事例の記事の別のリンクが貼られていますので、
興味があれば見てみてくださいと。
Amazonプライムビデオというか動画再生中に、 動画再生にWebアセンブリーというのを実は採用していて、
再生デバイス上でWASM VMをデプロイとか、 高フレームレートで動かすなどみたいなことができているそうです。
側の方でゴリッゴリにWebGLを使っているとか、 画面ビデオがある周りの方で計算処理が必要な場合は、
その計算処理をWebアセンブリーで丸投げして、 そこでガッと計算し終わったものをただブラウザレンダリングすることができるので、
そういうことをしたい場合は Webアセンブリーはオススメですよということでした。
あくまでその計算処理を型変わりするというところだけがポイントだと。
確か僕の記憶ではあってますけど、 その記憶も古くなっている可能性があるので、
改めて見たほうがいいかもしれないですね。
では続いて、優先度の低く軽い処理は、 リクエストアイドルコールバックを使いましょうというものですね。
どっかで聞いた関数だな。
リクエストアイドルコールバックを使えば、 ブラウザのアイドル中、いわゆる何もしない状態に処理を走らせることもできます。
アイドル時間はアイドル時間である意味大事だったりはするんですけど、
アイドルを減らしてしまって大丈夫かっていう不安はちょっとあるんですけどね。
なおリクエストアイドルコールバックというのは、 そのアイドル状態が解除された後続の処理に影響が出てしまわないように、
06:05
なるべく軽い処理をすることがお勧めですと。
例えばGoogleアナリティクスで重要度の低いイベントの 送信をする際に活用できたりするでしょう。
本当に軽微なものとか簡単な処理だけを リクエストアイドルコールバックで使うということですね。
そうすることでブラウザはイベントによるメインの処理を 優先的に行うことができますよということですね。
では続いて、アニメーション中のJavaScriptの実行というのは、 リクエストアニメーションフレームを使いましょうと。
これはよく聞く話ですね。
ブラウザは絶えずフレームを更新し再描画をしているんですけど、
スクロール等のアニメーション中にセットインターバルなどで、 JavaScriptを実行すると描画を中断してしまいますと。
アニメーション中にセットインターバルを使うかはちょっと分からないですけどね。
ものによってはセットインターバルを使って、 いわゆる無理やりポーリングをするみたいなことをやることもありますよね。
リアルタイム性が必要だったりするアプリケーションとかでは、 たまにやったりしますけど。
そのときにセットインターバルを使ったりするので、 そこで描画を中断してしまうという可能性は確かにありますね。
その結果、ユーザーから見たら、 アニメーションがカクついて見えるということは確かにありますねと。
で、リクエストアニメーションフレームを使えば、 次のフレーム開始でJavaScriptを実行することができ、
アニメーションでのJavaScript実行の 最適化することができますよということでした。
文言的にはそうですねって感じですけど、 ちゃんとソースコードとか実行の例とかを見ないとわからないので。
知識としてまず知っておいて、実際にこれでも手を動かしてみないと 何とも僕は言えないなと思いましたね。
そんなにアニメーションをいっぱい使うかという話も 別ではあるとは思いますけど。
では続きまして、アナリティクスですね。
アナリティクスにはNavigator.SendBeaconを使いましょうと。
いや、また知らない。 知らないメソッドがあったんですね。ナビゲーターオブジェクトの中で。
ページ遷移する際にページ遷移をブロックして 分析用データを送信しているケースがあるんじゃないでしょうか。
ありますね。確実に分析データを送信するためには もちろん必要ではあるんですけど、
ページ遷移が遅くなってしまうという問題が発生します。
これを防ぐにはNavigator.SendBeaconというのが使えますよと。
ちなみにほとんどのウェブサイトの運営者が使っている Google AnalyticsにもSendBeaconを使うことができますよと。
例えば、GTag.jsですね。 Google AnalyticsのGTag.jsであれ、
Analytics.jsであれ、SendBeaconというのを設定できますよと。
これは、あれですね。 developers.google.comの公式サイトにもそういうのが設定できますという記事のリンクが貼られていますので、
これを使ってデータの送信を柔軟に扱うことができますよということでした。
そのページ遷移のところが今回のフォーカスですよね。
そのナビゲーター周りのところでSendBeaconを使うのがお勧めですよということですね。
これはちょっと知りませんでしたね。
公式ブログにちゃんと書いてあったというのはちょっと不勉強がバレたって感じがしますね。
これは貴重な情報ありがとうございました。
ぜひ今後の開発体験の中で使っていこうかなと思います。
では続いて、イベント.PreventDefaultを使わない場合は、Passive Trueを指定しましょうということです。
09:02
例えばタッチスタートなどのタッチイベントでイベント.PreventDefaultを使わない場合は、
Passive Trueを指定することでスクロールの性能が改善されることがありますよと。
ただしブラウザによってはデフォルトでPassive Trueになっていたりしますよということですね。
例えば、ソースコード出てきてますけど、constのHandlerイコールでアロー関数が定義されていて、
console.log.testという、単純にコンソールログにテストという文句を出すだけのハンドラー関数を定義しておいたとしましょう。
その関数をwindow.adventListenerでタッチスタートイベントを発火します。
そのコールバックの関数として、さっき言ったハンドラー関数ですね。
コンソールログを出すだけのハンドラー関数を定義しておくと。
その第3引数にPassive Trueというのをつけておきましょう。
こうすることによって、スクロールの性能が改善されることがありますよということでした。
どういう風な改善されるとか、どういうケースで改善されるかというのが詳しいとこは
MDNを見たほうがいいかもしれないですね。
イベントターゲット.adventListenerのドキュメントのところのリンクが貼られているので、見てみてくださいということです。
僕これやった記憶がありますね。
Passive Trueでどこかで指定したことがあるので、スクロール周りで重いなってなるんだったらこれを使うといいかもしれないですね。
僕もこれ原理はしっかり分かっていないので、これは反省というか、ちゃんと知らなきゃなという感じがしました。
では続きまして、遅延読み込みとか無限スクロール等を実装するときはIntersection Observer APIというのを使いましょうと。
なんか知らない名前が出てきた。
遅延読み込みとか無限スクロール等を実装するときは、ブラウザー上の座標の計算がやっぱり必要になりますよと。
Event.GetBoundingClientRectというのを使えば、座標計算はもちろんできますけども、
セットインターバル等を用いて逐一計算するのはパフォーマンスに悪影響が出ます。
なるほどですね。
なのでIntersection Observer APIというのを使えば、このような問題を回避することができますと。
あと個人的にそのIntersection Observer APIを使って遅延読み込みができるリアクトコンポーネントをNPMで公開しているので見てみてくださいということでした。
リアクトドムレイジーロードコンポーネントというのでNPMに公開されているので、興味ある人は見てみてくださいということですね。
リアクト用だという感じなので、これ別にフォークして自分のよく使うフレームワークとかライブラリー用のやつを作ってアップしてもいいと思いますけどね。
そもそもそのIntersection Observer APIというのがなんぞやというのはちょっと分からないので、これは後ほど見て勉強したいなと思いました。
では続いて、今のでですね、Web API編は以上になりますね。
やっぱり僕全然Web APIをちゃんと知らなかったというか、不勉強すぎたというのがすごく分かりましたね。
今のテクニックほぼ全部知らなかったので、とてもありがたいなと思いますね。
では続きまして、V8エンジン編ですね。
まあいわゆるクロームだったりとかノードJSですね。内部的にV8エンジンが使われていますので、この辺、クロミウム系だったら確かV8エンジンなので、エッジもあとは使われているんですかねということですけど。
12:02
ここまで最適化すると変態ではありますけど、チップスとして紹介しますということでした。
ちょっとそういうことを聞かれると逆にエンジニアとしては、逆に知りたいとなっちゃう気がしますね。僕だけかもわかんないですけど。
はいでは一つ目です。値の格納というのはコンストラクターでやりましょうということですね。
V8エンジンでは内部的にヒドゥンクラスというものを生成しているそうですね。
詳しい仕組みは割愛しますけど、そのインスタンス化したオブジェクトに対して値を追加すると、新しいヒドゥンクラスというのが生成されてしまいますということですね。
はーはーはー、なるほどですね。 値追加すると新しいヒドゥンクラスが生成されるんですか。
なので、値の格納はなるべくコンストラクターの中でやりましょう。
例えばそのクラスポイントみたいなクラスを定義しておいて、コンストラクターで引数にxyみたいなのを受け取るとしましょう。
で、コンストラクターの中なので、this.で受け取って、this.xイコール引数xで、this.yイコール引数yの方をそのまま格納しますと。
まあそんな感じですね。 で、まあ使う時はもちろんnewポイントで引数を渡してあげるという感じですね。
そこでクラスの生成がされてしまいます。で、もう一回ですね、別の変数としてのnewポイントでnewをしてインスタンスを作ったとしましょう。
そうするとですね、もともとあったヒドゥンクラスが再利用されるということになるので、パフォーマンス周りとしてはここがいいよという話ですね。
で、単純に最初にインスタンスを作ったそのP1、例えばそのポイント1ですね。P1という変数を
newポイントの、newポイントでインスタンスを作ったものをP1という変数に入れたとしましょう。
その場合ですね、そのP1.zといって新しい変数を追加としたとしますね。その時は新しいヒドゥンクラスが生成されてしまうので処理が1個追加されて重くなるよってことですね。
なので、なるべくは格納時、コンストラクターのnewをするときに全部値を入れてあげましょうということでした。
なるほどね。では続きまして、オブジェクトは同じ順番のプロパティで生成しましょうということです。
はい、まあそもそもオブジェクトを使わないでマップを使った方がいいよっていうのが私はこの記事のだいぶ前にありましたけどね。
そのキーバリューを頻繁に追加削除する場合はそのマップを使いましょうというだけで、まあそういうことはしないなら別のオブジェクトでもいいよって話ですけど。
オブジェクトは同じ順番のプロパティで生成しましょうということです。
これもさっきのそのヒドゥンクラスに関わる話ではあるんですけど、違う順番でプロパティを生成すると新たにヒドゥンクラスがやっぱり生成されてしまいますよということでした。
具体的にはですね、ソースコードをまた音読になりますが、例えばコンストオブジェイコールナミカッコのAコロン1みたいな値を最初に初期定義しておきますと。
で、その下にオブジェドットBイコール2って言って新しいプロパティを追加するとしますね。
で、その時ですね、今のはオブジェだったんですけど、今度はオブジェ2みたいな新しい変数を定義しておいて、コンストオブジェ2イコールナミカッコのAコロン1ってやってみます。
そうするとですね、先にAコロン1っていうのをオブジェっていう変数の方で定義しておいて、そこでヒドゥンクラスっていうのが生成されているので、実は同じプロパティの名前のものだとヒドゥンクラスを使い回せることができるということですね。
15:03
これは知りませんでした。内部的には同じオブジェクトってところでヒドゥンクラスを使い回せるんですね。
これはプロトタイプチェーンと同じところの概念を使っているんだろうなと思いました。
結局大元はオブジェクトオブジェクトなので、そこからやっていくってところで辿れるのでヒドゥンクラスを使い回しているんだなということですね。
これは良い設計ですね。
その時にオブジェ2.bってやってもやっぱり同じことが起きるのでヒドゥンクラスは使い回せますよということですね。
最後3つ目です。オブジェ3イコールナミカッコのBコロン2みたいな値ですね。
今度はオブジェクトの定義としてプロパティBを新しく作るときにセットしてしまいますと、その時は新しいヒドゥンクラスが生成されるそうですね。
というところなのでなるべくは同じものを使うのがいいよということですね。
違う順番でってそういうことか。はいはいはい。だから順番が重要なんですね。
先にAを定義しておいてその後にBを追加するんだったら大丈夫ですと。
オブジェ3の方は先にBを定義しておいて後からAを追加したので新しいヒドゥンクラスっていうのが作られてしまって処理が1個も下りるってことですね。
あー理解しました。
まあここまでやると確かにあれですね。ちょっと変態感はあるんですけど、まあでもオブジェクトを扱うときは確かに順番は結構重要だったりするので、
まあこれはいい話かもしれないですね。
はいでは続いて、
関数というのは同じ引数の型を使いましょうということです。まあこれはなんとなく予想つきますね。
関数の引数はできるだけ同じ型を使うようにしましょうということでした。
例えばそのファンクションアドっていうのがあって引数にXYがありますと。
リターンXプラスYで返してあげているだけなんですけど、
でそのアド関数に渡す値が1、2っていう単純にインテージャーだったら別にいいんですけど、
アドに文字列で34とか渡すと、まあたし算するときにJavaScriptは勝手にたし算してくれるんですけど、
文字列で渡しているので文字列34になるっていうのはもちろんご存知の通りですけど、
この場合は少し遅くなるのでなるべくは同じ引数の型を使いましょうということでした。
まああんまそんなことしないと思います。最近はTypeScriptを使うのでちゃんと型定義、引数の型は定義すると思うので、
そこで縛ってやるのでいいと思いますけどね。
はいでは続きまして、
クラスを使う場合はトップレベルのスコープで定義をしましょうということでした。
関数内でクラスを定義するのはV8エンジン的には良くないらしいです。
そうですって書いてあるので、これのリソースどこからそういう話が出てきたのかちょっと気になりますけど、
なるべくその関数の中でクラスを定義するんじゃなくてトップレベルでクラスを定義しておきましょうということでした。
まあV8エンジン的にはというところなので別のブラウザーではわかんないんですけど、
これちょっと実際に試してみて検証してみるのはいいかもしれないですね。
ものすごい処理をするとか、入手する時にちょっと重い処理をするようなクラスを作っておいて、
それを関数内でやるか、それとも関数外でやってみるか、
どっちが良いのか、どっちがパフォーマンス早いのかというのは計測してみるといいかもしれないですね。
18:00
ほいでは今のがV8エンジン編でした。
まあ確かに変態と言われたら変態かもしれないですね。
こんな知らんわみたいなところがあるので。
まあでも主にオブジェクト周りとヒドゥンクラスの話がほぼほぼだったので、
まあこの辺は知っておけばというところですね。
はいでは続きましてV8エンジン編終わったので、最後かなこれ。
あと何個あるかちょっと分からないですけど、続いてライブラリー編に移ります。
あーでもまだありますね。ライブラリー編終わったら次SPA編に行って、ついでサーバー編なので。
はいじゃあついでライブラリー編です。
まあなるべくその軽量なライブラリーを採用しましょうってところから入ります。
ライブラリーを採用する一つの観点として、まあ純粋にサイズがありますと。
で、バンドルフォビアっていうサイトでライブラリーのサイズをチェックすることができますと。
こんなんあったんですね。バンドルフォビアっていうサイトがあったんですね。
まあここでその使うライブラリーとかのURLとかをここで名前を付けてあげると、
そこから検索してくれてどんなサイズになりますかってのを教えてくれるので、
まあなるべくサイズが小さければ小さい方がいいよねって話でした。
まあこれはそのパフォーマンス観点ではそりゃそうだよねって感じです。
では続いてライブラリーのサイズそのものを減らしましょうと。
はいまあ例えばそのMoment.jsとかローダッシュですよね。
などのライブラリーってのはWebpackのプラグインを使って不要なスクリプトを削減することがもちろんできますよってことでした。
はいまあ最近Moment.jsはそもそも使わないと思いますけど、
今はあとDJSかDate.fnsみたいなライブラリーを使うと思いますけど。
あとはローダッシュですね。ローダッシュもまるっと全部読み込むんじゃなくて、
ローダッシュってそれぞれのライブラリーに分けられているので、
必要なメソッドのライブラリーだけを読み込めば別にサイズも減らすことはできますし、
そもそもnpmインストールするときもそれだけをインストールすればいいと思いますので。
まあそういうやり方もありますけど、まるっと持ってくる場合もプラグインを使って、
不要なスクリプトを削減することもできますよってことでした。
はいまあこれも大事ですね。とにかくバンドルのサイズを減らしましょうということですね。
で続きまして、続いてはテクニックっていうかあれですけど、
ライブラリーのドキュメントを読みましょうっていうのが続いてのお話ですね。
ライブラリーの公式ドキュメントには最適化のチップスがやっぱり載っていたりすることもあります。
例えばリアクトにはそのパフォーマンス最適化のドキュメントのページがあったりとか、
Tailwind CSSにもオプティマイディングフォープロダクションっていうページがあって、
まあ本番用にビルドするときにはそういう最適化のオプションがありますよということなんですね。
こういうものがその公式のドキュメントに記載されていることがあるので、
しっかり各ライブラリーのドキュメントを見てみましょうという話でした。
これはマインドセット的なお話ですけど、すごく大事ですよね。
まあ先ほど今日読んでいた通りですけど、僕も知らないことたくさんあったので、
しっかりこの公式ドキュメントのパフォーマンス最適化のところの項目は読むのが確かに大事だなとちょっと反省する次第ですね。
はいでは続きまして、次ではライブラリーに頼らず自前で作りましょうという話ですね。
ほう。そのライブラリーっていうのは番人向けに最適化されていて、
あなたのアプリケーション向けには最適化されていませんと。
ああまあそうだよね。
エッジゲースとかユースケースによって最適化するわけはもちろんないので、
あなたのアプリケーション以上に機能型であることがほとんどだったりすることがあります。
21:00
時には自前で作るというのも一つの手ですよということですね。
これはエンジニア観点としていいお話です。
なければ作るというのはいい話だし、
もしくはフォークして自分たちでメンテナンスするかどうかはちょっと今後の話として置いておいて、
機能型だったらフォークしたものを自分たちで削減したものを改めてプッシュしておけば、
GitHubからNPMでインストールできますので、そういうやり方をするのも一つの手ですね。
はい。
これはでも大事ですね。ひたすらサードパーティーとかエコシステムに完全依存するわけではないというのはすごく大事な話だなと思いました。
では行きたいと思います。続いてSPA編になりますね。
リアクトとかVueといったコンポーネント志向のライブラリを想定していますよと。はい、OKです。
リアクトの行動例が多いですけどVueでも参考になると思います。はい、OKです。
では一つ目ですね。コンポーネントがマウントされた後に遅延的にデータを読み込みをしましょうと言っています。
優先順位だったりデータサイズが大きい場合はそのマウント後にリソースを取得するのもどうでしょうかという話ですね。
はーはーはーはー、なるほどですね。
例えば、でもこれはソースコードいっぱい出てくるのでちょっとあれなんですけど、
例えばですね、ライブラリで、例えばarticles.jsonみたいな何かを読み込むとしましょう。
それをimport fromでやっていた場合ですね。
先に読み込むのではなくて、useEffectを使ってマウントされた後にimport前で読み込んで、
それをuseStateにセットしてあげるというのでいいんじゃないのという話でしたね。
物によったりしますね。あまりにも巨大だったりするんだったら、
先にhtml的にはレンダリングされておいて、その内容のコンテンツというのは後から非同期的にセットすると。
その場合は途中でスケルトンだったりを表示するという必要もあったりしますけど、
その辺のテクニックを使うのも確かに一つかもしれないですね。
とにかくユーザーにどういう体験をさせるかというのが結構大事なので、先に出すか後に出すかというところですね。
これは確かに一つの手ではありますが、
そんなに巨大なデータを一遍に全部で取ってこなくてもいいと思っているので、
昨日読んだ範囲ですかね、映っている画面の範囲だけにまずはデータを取ってきて、
後でスクロールしたりするときに非同期的に取ってくるというのも手ではありますけどね。
先に絶対にどんどんデカいのを取ってきたいのであれば、マウント後にデータを読み込むというのが一つの選択肢ですよという話でした。
では続いて、クリック等のイベント後に遅延的にデータを読み込みにしましょう。
これもさっきの話に近いですかね。
コンポーネントがマウントされた後に遅延的にデータを読み込みにすると、先ほどの話と似ているんですけど、
クリック後などユーザー操作の後に遅延的にデータを読み込みにするのはありですよということですね。
これはよくやればいい話だと思います。
0時ローディングとかもあったりしますけど。
では続いて、コンポーネントを遅延読み込みにしましょう。
コンポーネントそのものを遅延読み込みにしましょうというお話でした。
初めてコンポーネントが表示されるタイミングでコンポーネントを読み込みます。
やっぱり画面で描画されるところでコンポーネントそのものを読み込みにいくということですね。
例えばユーザーがボタンをタップして初めて表示されるコンポーネントは遅延読み込みの実装を考えます。
リアクトのURLのサスペンスですね。
Next.jsでいうダイナミックなAPIとかを使ってコンポーネントの遅延読み込みを実装することもできるので、
24:00
この辺も使ってくださいということですけど、
サスペンスは最近使うことは結構デフォルトに近いんじゃないですかね。
と思うのでこの辺をうまく使っていきましょうということですね。
あとは遅延読み込みという話でいくとリアクトの次のリリースですね、
サーバーコンポーネントという話も出てくるので、
この辺も使って読み込みの頻度とか順番とか、
あとはその処理自体をサーバーサイトに任せるかクライアントにやるかという設計周りの話が出てくると思いますけど、
ということもできたりしますよというのはあるので、
コンポーネントそのものの読み込みタイミングは確かにハンドリングした方がいいなと思いました。
では続いて、SSR、SSG、ISRに移行しましょうということですね。
リアクトとかVueは通常のSPAというのは性質上初期描画がやっぱり遅くなりますと。
SPAなんで。
リアクトであればNext.jsとかGatsby.jsとか、
VueであればNextみたいなフレームワークを使えば、
その初期描画が遅くなる問題を解決できますと。
ここはちょっと文言があまりにも抽象的で、
どうやってるのっていう、その初期描画の遅くなる問題解決の方法がもう少し欲しかったなって感じはしますね。
言いたいことはわかりますけど。
では続いて、コンポーネントの設計を最適化しましょうという話です。
リアクトとかVueだとコンポーネントレンダリングの仕組みが違うので、
一概にこれが最適とは言えないんですが、
共通した設計の最適化というのがありますと。
例えばコンポーネントとデータの依存を考えて、
再レンダリングの範囲を最小限にすることでしょうと言ってます。
次のコンポーネントの例を見てくださいというので、
とあるコンポーネントのソースコード例があるんですけど、
単純にLibタグが1個置いてあって、その中にLibタグ2つ置いています。
片方はデータAに依存するUI部分と、
もう片方はデータAに依存しないUI部分みたいな、
雑に書いてますけどね。
ような感じでコンポーネントが作られていたとします。
リアクトとかVueであれ、
このようなケースの場合はデータAに依存しないUI部分というのを
別コンポーネントに切り出した方がもちろん良いでしょうと。
そういう話ね。
そうすればデータAに変更があったときに、
データAに依存するUIの部分のみサイレンナリングすることができます。
Vueであれば問題ないんですけど、
リアクトの場合はステート管理のライブラリ使っていない場合は
リアクトメモとかを使う必要がありますねという話ですね。
まあまあまあ確かにそれはありますけど、
使ってしまえばいいという話ですね。
でもこれはよくある話ですよね。
データとかAPIフェッチしたデータに依存するようなUIかそうじゃないか
というのは別に切り出すのはよくある話だと思いますので。
では続いて、
今のがSPA編でした。
次はサーバー編ですね。
サーバーの話をフロントエンドでやるのはどうかというと
別の話はありますけど、とりあえず読んでみましょう。
一つ目ですね。
必要なデータのみフロントへ返却しましょうと。
例えばその記事の一覧ページに各記事の本文を一部表示するとします。
よくやれですね。
本文を一部だけならサーバーから一部だけ返却するようにします。
そうすることでファイルサイズの削減などができますよということですね。
まあこれは言いたいことはわかるんですけど
結果SPAでやってるしシームレスに扱いたいので
もってよくに越したことはない感はありますので
フロントで表示するときにCSSで文字を少なくしてとか
27:01
3点リーダーの表示にするとかできたりはしますけど
この辺は側の方でもJSで制御することもできなくはないかな
と思ったりはしましたね。
ただ結果的にブラウザでメモリーに持たしているのは事実なので
そのサイズを小さくするに越したことないというのは
もちろんそうかもしれないなと思いました。
では続いて事前に静的ファイルにしておくというのが次ですね。
都度APIへアクセスするのであればあらかじめJSONにしておくのも良いでしょうと。
まあそうですね。データの更新がそんなに頻度多くなるわけではないし
日時バッチとかでその日だけはデータ変わらないというのであれば
JSON化して一層アプリの中で持っておくのも一つかもしれないですね。
これは確かに戦略的にやることであるかもしれないと思いました。
もしかもキャッシュのところでずっと持たし続けるというのはあるかもしれないですね。
MEMキャッシュとかREDISとかあったりすると思うので
その辺に持たすのも一つかもしれないですね。
まあちょっとREDISに頼るのは怖い感はありますので。やっぱりキャッシュなのでね。
なのでJSONファイルにしておくというのが一つの手ではありますが
まあ無理やり感があるので好まれないかもしれないですね。
はいでは続いて日本にあるサーバーを使いましょう。
これは単純にサーバーが物理的に近いところを選びましょうということですね。
これだったらCDNとかエッジサーバーも同じですね。
とにかく距離が近いところのサーバーを使いましょうということでした。
まあとはいえAWS使うと思うので東京リージョンのところを使うと思うんですけど。
はいでは続いてAWS以外のものもですけど
基本的には物理的に近いものがいいというのはそれはこの通りだというところでした。
まあこの辺は皆さん普通にそうしてるんじゃないですかねクラウドを使っている方は。
では続いてブロットリー圧縮を使いましょうと言ってます。
初めて聞きました。何ですかブロットリー圧縮。
GZIPより圧縮後のサイズ削減とか圧縮速度の向上が見込めるので
ブロットリー圧縮っていうのを使ってみたらどうでしょうかってことでした。
これはですねブログ.redbox.ne.jpっていうサイトですねにあります。
ウェブスピード向上転送量の削減をするためにブロットリー圧縮とCDNの連携という記事があるので
興味ある人は見てみてくださいということでした。
ちょっと初めて聞いたんで僕はちょっと後で見てみようと思います。
続いてCDNを使いましょうと。
これはもう言わずもがなというところでした。
あと続いてhttp2を使いましょうと言ってます。
もちろんhttp1.4でそれは早いに決まってますね。
できるんだったら使いましょうってことですけど
もう今2よりも次の話3とか出てきたりするし
クイックの話がありますよね。
ネットワーク周りの話もあったりするので
その辺まで実装できればいいと思いますけど
ここまで来るとフロントの領域をちょっと超える気はしますね。
ラストですね続いて。
ちょっと駆け足で行きましたけど
httpキャッシュを使いましょうと。
キャッシュコントロールなどのhttpヘッダーを利用して
ブラウザにリソースをキャッシュさせるという
そういうことも確かにできますね。
これを使うのもいいでしょうということでした。
キャッシュもどこをキャッシュするかってありますよね。
もう既に計算結果のDOM自体をキャッシュするのもあれば
API自体をキャッシュすることもあれば
APIコールですね。
コールそのものをキャッシュすることもできたりするので
そもそもキャッシュ戦略という話はやっぱりあると思いますけど
30:01
そのhttpヘッダーのキャッシュコントロールも
確かに一つの選択肢としてありだなと思いましたね。
というところで以上ざっと言ってきました。
この3日間ですね。
次のようなカテゴリーを分けしてあって
JavaScript編とHTML、CSSなどのリソース編と
ブラウザAPI編、V8エンジン編と
ライブラリー編とSBA編でした。
いろんなありましたけどHowToを紹介しました。
皆さんのパフォーマンスチューニングの力になれば幸いです
ということですね。
そもそもパフォーマンス周りのところはですね
ボトムアップとトップダウン的なアプローチ
2つがありますよね。
ちゃんと定量的に計測をしてボトムネックを探す
というトップダウン的なアプローチ
っていうのが多分成功法だと思うんですけど
そういうものが分からなかったりとか
なかなか探しても見つからないというときは
ボトムアップ的にいわゆる専門ノック的に
HowToを片っ端しか試していくっていうのも
一つの選択肢としてありだよねっていうのが
この本記事の冒頭で書かれていた思想であるので
まあそういう選択肢として
いろんなリファレンスとしてこの記事を
使っていくのも一つでいいんじゃないかな
というところでご紹介しました。
僕もすごく勉強になりましたし
パフォーマンス周りは来年本格的にやろうかな
と思っているので
あとこの辺は一個一個自分でも手を動かして
計測していきたいなと思います。
ではですね、30分ちょっと超えてしまって
大変に申し訳なかったですけど
今日の朝活動は以上にしたいなと思います。
今日はですね、ネムさんとプテラノドさんですね
ご参加いただいて大変にありがとうございました。
明日は何読むかちょっとまだ決めてないんで
なんか見つけてゆるーく読んでいこうと思いますので
またご参加いただければ幸いです。
ではまた今日からですね
1週間始まりますので
頑張っていけたらと思いますし
もう始末ですので、どうせ忘年会シーズン始まるので
あんま仕事手につかない可能性もあるかもしれないですけど
まあまあ無理せずゆるーく
コミットしていければいいんじゃないかなと思います。
では今日も頑張っていきましょう。お疲れ様でした。
