メインコンテンツまでスキップ

performance

Overview​

パフォーマンス改善についてまとめる。

考え方​

パフォーマンスチューニングの初手でコードに手を入れるのは悪手。
環境設定のみでパフォーマンスが充分に改善できるならばベスト

フロント側​

  • JSコードのパフォーマンスを比較したいとき オンライン比較ツール

  • ドワンゴでのフロントパフォーマンスチューニング 参考URL

  • スクロールイベントの間引き 参考

  • フロントのパフォーマンス改善のいろは 参考URL

  • SPAとserver Side Renderのパフォーマンス 参考URL

  • webpackを使用した際のバンドルサイズ パフォーマンス改善 参考URL

  • videoタグの圧縮 参考URL

  • 配列アクセスのパフォーマンス 参考URL

  • Webサイトのパフォーマンスを上げる リファレンス

イベントの調整​

解決策の1つは、イベントを延期し、何回かのイベントを一度にまとめて扱うことです。この点で役立つ、よく使われる2つの関数があります。throttleとdebounceです。

throttleは決められた時間間隔でイベントが確実に一定量で推移 (時間ベース型）

debounceは瞬時に頻発するイベントを単一のイベントにグループ化する (イベントトリブン型) →例、mousewheelが少し動かしただけでめちゃくちゃ発生するイベントをまとめる。

debounce 連続したイベントの最後だけ実行 →これはbutton連打とかにいい。 debounceは、Ajaxでのキーの押下など、ほかの問題も解決します。フォーム入力で、キーをたたくごとにリクエストが送信されると困ったことになります。 エレガントなソリューションの1つは、立て続けに起こるキー操作を、Ajaxリクエストをトリガーする1つのイベントにグループ化することです。1つのイベントにグループ化するとタイピングの自然な流れにぴったり合い、サーバーリソースの節約にもなります。キーの押下では、イベントの間隔は重要ではありません。なぜなら、ユーザーは一定の間隔でキーを押すわけではないからです。

throttle こちらでは規定時間後に実行するという考え方です。 こちらの方が間引く時間が正確に反映されています

debounceでは対応しきれない部分の代替手段として、スクロールイベントにthrottleを使えます。スクロールが決まった時間間隔で発生するのがthrottleのメリットです。いったんユーザーがスクロールを始めたら、ちょうどよいタイミングで確実に実行されるのが望ましいことです。

この手法は、ユーザーがページ内の特定の場所にいるかどうかをチェックするのに役立ちます。ページのサイズが大きいと、コンテンツをスクロールしていくのに何秒もかかります。これを使って間引けば、任意の`決まった時間間隔で1度だけイベントを発生できます。イベントを間引くことでスクロール体験をスムーズにし、しかも実行が確実です。

画像表示について​

通信で取ってくるよりbase64で表示させた方がよい 参考URL

画像遅延表示​

画像の遅延方法には2つの種類がある。

参考URL コリス

サイト パフォーマンスチェック項目​

クリティカルレンダリングパス​

DOMとJavaScriptも含めてクリティカルレンダリングパスと呼ぶ

Chrome lighthouse (実施するときはシークレットモードにする)​

Lighthouseとはウェブページの品質改善の指針を パフォーマンス・PWA・アクセシビリティ・ベストプラクティス・SEOの点でチェックしてくれる

  • 経緯

Chrome拡張やコマンドラインで提供されていましたが、Google Chrome 60でデベロッパーツールに統合された。 また、オンラインでチェックしてくれるツールGoogle PageSpeed Insightsも、分析エンジンにLighthouseを採用するようになりました。とは言っても全く同じ結果とはならなくて、Google PageSpeed Insightsの判定の方が低い場合が多いようだ。

メトリクス​

ソフトウェアのメトリクスとは、ソフトウェアを計測する方法およびその尺度のことを意味する。

コードメトリクス​

参考URL

コードメトリクスとはソースコードについてさまざまな角度から計測した値のことを指す。

コマンドの実行時間を調べる​

timeコマンドで調べられる 参考URL

Webページのパフォーマンス指標​

Web ページのパフォーマンス指標として、以下があります

FCP（First Contentful Paint）

ブラウザが最初のテキストや画像などのコンテンツを描画するまでの時間 真っ白な画面ではなく、何かしらの表示（レイアウトなど）がある状態 LCP（Largest Contentful Paint）

ページの主要なコンテンツが表示されるまでの時間 ユーザが関心のあるコンテンツが含まれている DB からデータを取得し、UI にレンダリングされた状態 TTI（Time To Interactive）

ページが完全にインタラクティブになるまでの時間 React がダウンロードされ、アプリケーションがレンダリングされ、ハイドレーションが行われる ページ上の UI コンポーネントが反応し始め、ユーザーが入力できる状態 CSR では、FCP が遅くなってしまうのが問題です。そして、この問題を解決するのが SSR です。

に最終更新