First Input Delay（FID）を考慮したWEBサイト制作（Core web vitals SEO）
FIDとはGoogleが推奨する新しいSEOランキング基準（Core web vitals）要素の一つです。
WEBページのレンダリング処理が終了しユーザー操作を受け付けるようになるまでの時間を指します。
FIDスコアはユーザーの性格によって変わりますが、レンダリングの邪魔をしない様、ソースを最適化する事で改善できます。
First Input Delay（FID）とは？
First Input Delay（以下：FID）とは、サイトの読み込み中にブラウザがユーザーのアクションに応答するのにかかる時間を指します。
このユーザーアクションとは、インタラクティブ（対話性）なものを指します。
ユーザーがボタンやリンクを押したり、画面をタップする事に対する「WEBサイト側の反応の速さ」がそれにあたります。
ユーザー体験の向上につながるSEOランキング要素
FIDはGoogleが新しく導入したユーザーエクスペリエンスの指標であり、SEOランキング要素です。
GoogleがFIDを推奨するのにはもちろん理由があります。
FIDを改善すればサイトのパフォーマンスが向上する訳ですから、ユーザーを喜ばせる事にもなります。
それが一般的な売上（広告収入など）や訪問者数の増加へもつながる訳です。
FIDに含まれないもの
FIDの測定対象は、サイト読み込み中のユーザー操作に対する反応速度の度合いです。
ですのでテキスト入力候補やドロップダウンおよびチェックボックスなどの入力補助機能は含みません。
さらにページスクロールやズームなどの機能も、サイト自体からの応答ではないので対象外となります。
なぜFID数値を測るのか
この反応速度の遅延は主に、無秩序にダウンロードされる画像とスクリプトが原因で発生します。
WEBページのダウンロードが過度になり過ぎると、読込自体が一時停止してしまいます。
一時停止している間、WEBページを操作するユーザーのあらゆるアクションに応答しません。
ご経験ありませんか？
WEBページを開いてすぐにリンクをクリックしても何も動かないって事がたまにありますよね。あれがまさにその状態です。
この時間が長ければ長いほどユーザーにストレスを与えますから、結果ユーザーを離脱させてしまいます。
この状態を防止したい訳です。
GoogleのFIDに対する見解
GoogleはFIDの原因を次のように説明しています。
一般に入力遅延（入力遅延）は、ブラウザーのメインスレッドが他のことを行うのに忙しく、ユーザーに（まだ）応答できないために発生します。
これが発生する可能性のある一般的な理由の1つは、ブラウザがアプリによって読み込まれた大きなJavaScriptファイルの解析と実行でビジー状態になっていることです。
その間、ロードしているJavaScriptが何か他のことをするように指示する可能性があるため、イベントリスナーを実行することはできません。
ブラウザが応答しなくなる理由
ブラウザは、WEBページを表示するタスクを実行するソフトウェアです。
タスクは、コード、画像、フォント、スタイル情報、およびスクリプトをダウンロードし、スクリプトを実行して、HTMLの指示に従ってWEBページを構築します。
この構築プロセスを一般的に「レンダリング」と呼びます。
さらにWEBページをレンダリングするために実行される各タスクの事を「スレッド」と呼びます。
WEBページのレンダリング土台：メインスレッド
ブラウザには、メインスレッドと呼ばれる1つの大きなスレッドが建ちます。
このメインスレッドが、ユーザーに表示するWEBページを作成（レンダリング）する役割を担います。
メインスレッドは、ダウンロードおよび実行される画像とスクリプトを並べる土台の様なものです。
例えるなら、車が通る高速道路の様なものですね。
高速道路が渋滞する状態
遅延を起こすコードは、高速道路上を走る、とても巨大で速度の遅いコンテナ車のようなものになります。
このコンテナ車のゆっくり走行より他の車が渋滞停止するため、大きくて遅いコードが高速道路から降りるまで待たなければなりません。
これが一時停止の状態です。
高速道路が渋滞しないような工夫
これを防ぐには、コードの実行時やダウンロードされるコードを最適化できる様にWEBページのコーディングを見直す必要があります。
WEBページが可能な限り最速でダウンロードされるようにしなければなりません。
つまりコンテナ車から個別の小さな貨物車に分けたり、あまり車がいない内に走行させるなど、渋滞が起きないような工夫が必要だという事です。
FIDを修正する方法
FIDの根本的な原因は、スクリプトと画像の無秩序なダウンロードにあると言えます。
問題を解決するためには、各要素の読込や方法を整理することです。
解決法
目標は一時停止に状態にならない様にスムーズにWEBページをダウンロードする事ですね。
・HTML属性を使用してスクリプトのダウンロード方法を制御する
・画像（HTMLと画像）を最適化する
・不要なスクリプトを省略する
スクリプトのダウンロード順や状態を見直す
スクリプトはHTMLページ上で必ず読込されますが、読込する位置が必ずあります。
それにより読込・レンダリングの順番が決定する訳です。
順番を整理していかに他の邪魔にならないようにするかがポイントです。
画像とHTMLの最適化
画像やHTMLソースを軽量化し、少しでも負担なくレンダリングできるように工夫する必要がありますね。
特に画像は容量が大きい程時間が掛かります。最適な画像をいかに早く処理できるかが重要です。
不要なスクリプトは読み込まない
100個の情報量を毎回全て使う事は稀です。
しかし都度20個しか使わないのに、毎回100個情報を読み込むのはナンセンスですよね（開発者としては楽でしょうが）。
画像もそうです。レスポンシブルデザイン向けに複数画像を用意するのが主流ですが、毎回全て読み込んでいては負担になるだけです。
ですので使わないソースやスクリプト・画像は読み込まない工夫が必要です。
FIDスコアはユーザーによって異なる
先述した通りFIDスコアは訪問者によって常に異なり、そこに一貫性はありません。
それはスコアが、サイトにアクセスするユーザー固有のインタラクションに依存するためです。
あなたはどちら側のユーザーでしょうか？
例えば私の場合、基本的にはWEBページを開いて読込マークの回転が終了してから、各種操作をおこないます。
この場合私におけるこのWEBサイトのFIDの数値は限りなく低くなりますよね。
レンダリング処理が完了して応答できるまで、親切に待っている訳ですからね。
ほとんど待たないユーザーも
ただ別ユーザーによってはマークを待たずにすぐにアクションをしようとする人もいます。
その場合FID数値は高くなり、問題であると判断されるはずです。
この様に全ての情報がロードされて準備完了となるまでアクションを起こさないユーザーと、そうではないユーザーがいるのです。
同じWEBページでもアクションを起こすユーザーのタイミングによって、FIDの数値は変わってきます。
スコアに関するGoogleの見解
Googleが以下の様に説明しています。
すべてのユーザーがアクセスするたびにサイトを操作するわけではありません。そして、すべての相互作用がFIDに関連しているわけではありません。
一部のユーザーの最初の対話は悪い時間（メインスレッドが長時間ビジー状態のとき）になり、一部のユーザーの最初の対話は良い時間（メインスレッドが完全にアイドル状態のとき）になります。
つまり同じサイトでも一部のユーザーにはFID値が出ず、一部のユーザーには低いFID値が、一部のユーザーには高いFID値が出ます。
必要以上に焦らない
FID数値の改善は確かに必要です。ですので改善できる部分は進めるべきですが、必要以上に悩まない事です。
説明した通り、同じページでもそのFID値はユーザーによってばらつきがあります。
ましてや、同一ページの表示速度を競合他社と比べ合っている訳でもありません。
なのであまり深刻に考えるべきではないと思います。
FIDにおけるJavaScriptの影響
JavaScriptは様々なギミックの実現に使われます。
何かのアクション中にポップアップで警告メッセージを表示させる場合がありますよね。
例えばお問い合わせ入力フォーム上で、入力用と確認用に同じメールが入力されているかを認証する時などです。
Javascriptはユーザーアクションをコントロールするために必須の機能です。
読込時間＋実行時間
一番の問題は、JavaScriptがダウンロード時間以外に実行時間も要する事です。
例えば大きなJavaScriptファイルがページのheader内にあるとしましょう。
この時そのファイルのダウンロードと実行が完了するまで、そこから下のページがレンダリングされないようにせき止めてまうのです。
これをページのブロックと呼びます。
ページのブロックをいかに回避するか
こういったページブロックを避けるためには工夫が必要です。
容量の大きいスクリプトはheaderからfooterに移して、レンダリング待ちのページ要素に干渉しないようにしなければなりません。
footerに移しても影響を及ぼす場合も
ただし大きい容量を持つスクリプトだと、footerに配置しても問題が起きる可能性があります。
レンダリングが完了した後もスクリプト実行に時間が掛かると、その間ブラウザは応答しないためです。
ページは速くダウンロードされるかもしれませんが、JavaScriptの実行を待つ間に停止してしまいます。
つまりファイルの読込位置以外に、肥大したスクリプト自体を解決しないといけません。
非同期属性・延期属性
Javascriptにはこういった処理速度の問題を解決する要素があります。
Async属性およびDefer属性は、JavaScriptのダウンロードと実行の開始と停止を制御するものです。
これらの属性はダウンロード中にレンダリングをブロックせず、ブラウザにメインスレッドを続行するように促します。
非同期（Async）属性
通常JavaScriptファイルは、ダウンロードされるとすぐに実行され、それと同時にメインスレッドをブロックしようとします。
しかしAsync属性の様な非同期属性はブロックをしません。
スレッド独立による非同期ダウンロード
それはAsync属性のjavascriptファイルがメインスレッドとは別に独立しており、別々にダウンロード処理されるためです。
これを非同期ダウンロードと呼びます。
async属性は、広告やソーシャル共有などのサードパーティのJavaScriptファイルなど、実行する順序があまり影響しないファイルに役立ちます。
延期（defer）属性
「defer」属性を持つJavaScriptファイルも上記同様、非同期でダウンロードされます。
ただしdefer属性のJavaScriptファイルは、ページ全体がダウンロードされてレンダリングされるまで実行されません。
レンダリング後に順次実行
その代わり、実行時はWEBページに配置されている順序で実行されます。
defer属性を持つスクリプトは、そのページに置いて実行される順番が大切なJavaScriptファイルに役立ちます。
一般的にWEBページ自体のレンダリングに影響しないスクリプトには、このdefer属性を使用します。
改変を迫られたCMSの例
少し前までは多くのCMSシステムにおいて、このFIDの数値がなかなか改善できずにいました。
この新しい基準に準拠するように設計していなかったためです。
まあ後から加えられた新基準な訳ですから、対応できていなくても無理はありませんね。
Wordpressのグーテンベルク
WordPressを例に取ると、グーテンベルクが挙げられます。
グーテンベルクは、ブロックのインターフェースまたはメタファーを使用してサイトを構築する方法です。
画面はウィジェットブロック、お問い合わせフォームブロック、フッターブロックなどに分けられています。
WEBページを作成するプロセスが見やすくなり、管理画面を通じてブロック単位でページを構築します。
さまざまなに表示および動作ができる、非常に多くの種類のブロックがあります。
統一CSSによるスタイル管理
個々のブロックには対応するCSSスタイルがあるので、これらの全ての固有スタイルをまとめる必要がありました。
そこで各固有のスタイルを網羅する1つのCSSファイルを用意しています。
ブロックに固有の全てのコードを統一CSSで管理できるので、理にかなった方法と言えますよね。
毎回不要なスタイルを読込している
当然の事ながらページへの出力時は、この統一CSSファイルを読み込みます。
例えば20個のブロックで構成されたページであっても、毎回全てのブロックスタイルを読込する訳です。
コードが膨れ上がっていると指摘
ところが今回のCore Web Vitalsの新しいSEO基準が導入された後から、それは「コードの膨張」と見なされました。
そのためWordPress Gutenberg 10.1では改善がされました。
使用したブロックに必要なスタイルのみを読込し、それ以外の未使用スタイルは読込しないようにしたのです。
FID向けの抜本的な手法の切り替え
これはWordPressおよびパブリッシャー、そしてWordPressで作成されたサイトにアクセスするユーザーにとって大きい変更です。
この様に今後、CMS、テーマ、プラグインの開発担当者は、FIDに適したコーディング手法に移行していく事でしょう。
逆に言えば、このようにCMS側の整備を待つしかない場合もあると言えます。
FIDを考慮した仕様に変わる訳ですから、サイト管理者も仕組みとその理由を理解した構築が必要になりますね。
