HTMLリフローとページスピードへの影響を理解する
リフローは、ブラウザがWebページ内の要素の位置とジオメトリを再レンダリングのために再計算するときに発生します。これがページスピードにどのように影響するかを学びましょう。

Webリフローとページスピードへの影響を理解する
リフローは、レイアウトまたは再計算とも呼ばれ、Webブラウザにおいて再レンダリングのためにWebページ内の要素の位置とジオメトリを再計算する重要なプロセスです。このプロセスはWebコンテンツを正しく表示するために不可欠ですが、ページスピードと全体的なパフォーマンスに大きな影響を与える可能性もあります。この記事では、Webリフローとは何か、そのトリガー、そして提供された情報に基づいてページスピードにどのように影響するかを探ります。
リフローとは?
Webリフローは、基盤となるDocument Object Model(DOM)とCSSスタイルに基づいて、各要素の位置やサイズを含むWebページのレイアウトをWebブラウザが計算するプロセスです。DOMやCSSにレイアウトに影響する変更があると、ブラウザはページの外観を正しく更新するためにリフローを実行する必要があります。
Webリフローのトリガー:
ユーザーインタラクションやDynamic HTML(DHTML)の変更など、いくつかのアクションがWebリフローをトリガーする可能性があります。一般的なトリガーには以下が含まれます:
DOM要素の変更:DOM内の要素の追加、削除、変更はリフローを引き起こす可能性があります。ブラウザはこれらの変更に対応するためにレイアウトを再計算する必要があるためです。
CSSの変更:width、height、margin、padding、transformsなどのCSSプロパティを変更すると、ブラウザが要素の位置とジオメトリを調整する必要があるため、リフローがトリガーされる可能性があります。
フォントの読み込み:Webフォントが読み込まれたり更新されたりすると、テキストのレイアウトに影響を与え、リフローにつながる可能性があります。
ウィンドウのリサイズ:ブラウザウィンドウのサイズを変更すると、レイアウトが新しいサイズに適応する必要があるため、リフローが強制されます。
メディアクエリの変更:画面サイズや向きが変わると、ブラウザは新しいメディアクエリルールに基づいてレイアウトを再計算する場合があります。
WebリフローのPageSpeedへの影響:
Webリフローはページスピードと全体的なuser experienceに大きな影響を与える可能性があります。レイアウトの再計算とページのレンダリングのプロセスには時間と計算リソースが必要であり、読み込み時間の遅延やパフォーマンスの低下につながる可能性があります。Webリフローがページスピードに影響する仕組みは以下の通りです:
パフォーマンスのボトルネック:過剰で頻繁なリフローはパフォーマンスのボトルネックを生み出し、ページレンダリングの遅延や最適でないuser experienceにつながる可能性があります。
レイアウトスラッシング:レイアウトスラッシングは、頻繁なDOM更新によりブラウザが不要なリフローを複数回実行するときに発生します。これにより、ぎこちないアニメーションやカクカクしたユーザーインターフェースが生じる可能性があります。
Cumulative Layout Shift (CLS):CLSは、ページ読み込み中の予期しないレイアウトシフトを計算することで、Webページの視覚的安定性を測定します。頻繁なリフローはCLSスコアの上昇に寄与し、SEOとuser experienceに悪影響を及ぼす可能性があります。
より良いPageSpeedのためのブラウザリフローの最小化:
ページスピードを最適化し、Webリフローの影響を最小限に抑えるために、開発者はいくつかのベストプラクティスに従う必要があります:
DOMの深さを減らす:DOM構造を浅く保ち、要素を過度にネストしないようにしましょう。フラットなDOMツリーはより高速なリフローにつながります。
CSSルールの最適化:複雑なCSSセレクターの使用を制限し、不要なスタイルの適用を避けましょう。CSSルールの数を減らして再計算のオーバーヘッドを最小限に抑えましょう。
DOMの変更をバッチ処理する:複数のDOM変更を行う場合、リフローの回数を減らすためにそれらをまとめてバッチ処理しましょう。これはrequestAnimationFrameなどのテクニックやDocumentFragmentを使用して複数の要素を挿入することで実現できます。
TransformsとTransitionsを使用する:要素をアニメーションする場合、widthやheightなどのプロパティの代わりにCSSのtransformsとtransitionsを優先しましょう。transformsの方が効率的で、リフローをトリガーする可能性が低くなります。
Webフォントの最適化:Webフォントを慎重に選択・最適化して、リフローと読み込み時間への影響を最小限に抑えましょう。
Interaction to Next Paint (INP)を理解する:
Interaction to Next Paint (INP)は、ユーザーインタラクションに対するWebページの応答性を評価するメトリクスです。クリック、タップ、キー操作などのユーザーアクションに応じて、ブラウザが視覚的フィードバックを処理・表示するまでの時間を測定します。低いINPスコアは迅速でスムーズな応答を示し、高いスコアは応答性の悪さを示し、混乱や不満足なuser experienceにつながる可能性があります。
INPは、ユーザーがWebサイトのインタラクティブ性をどのように認識しているかについて貴重な洞察を提供する、重要なCore Web Vitalsメトリクスです。200ミリ秒未満のスコアは良好とみなされ、500ミリ秒を超えるスコアは応答性の改善が必要であることを示します。
リフローとINPの関連性:
WebリフローはINPスコアの決定において重要な役割を果たします。ユーザーインタラクションがWebページのレイアウトやスタイリングの変更をトリガーすると、ブラウザは影響を受ける要素の位置とジオメトリを再計算する必要があります。リフローはリソースを大量に消費する操作であり、次のペイントイベントが発生するまでの時間に影響を与えます。
ブラウザがユーザーインタラクション中にリフローを実行すると、リフローによる遅延がINPスコアの上昇につながる可能性があります。過剰で頻繁なリフローはパフォーマンスのボトルネックを生み出し、ユーザーアクションへの応答性の低下、つまりINPスコアの悪化につながります。
CrUX data is 28 days late.
Google provides data 28 days late. CoreDash provides data in real-time. Debug faster.
- Real-Time Insights
- Faster Debugging
- Instant Feedback

