夜中に目が覚めて、気になっていたモバイルINP問題は現時点でどんなスコアになってるのか調べてみました。
前回の記事では、問題を解決するためには、専門知識が必要と結論付けましたが、今回は問題点を深掘りするためにやって来た調査結果をまとめてみました。
目次
現状の問題点
昨年末からGoogle search consoのウェブに関する主な指標でCLSやINPの問題が発生し出した。
INPとはユーザーがページを操作した時の応答性を評価(実際にページを開いて操作しないと評価出来ない)フィールドデーターから取得
フィールドデーターとは、あらゆるユーザーの環境下で使われているデバイスから取得したもの。
言える事は、データーは日々環境によって変化しているので、測定値の変動に一喜一憂すべき事ではないと思っています。
目標の設定
この問題点を踏まえて、INPが不良になっている原因を特定して出来る範囲で対策をしたいと思っています。
INP不良の原因調査
Googleサーチコンソールのウェブに関する主な指標を開いて問題になっているURLを確認page speed insertで分析結果を確認。
CLS INP等の分析結果が表示され、それぞれの不具合に対する改善案が表示されます。
その中で特に問題になっているのが、ビューポートに描画される最大コンテンツの要素となっていて、ヒントには不要なJavscriptやCSSの削除や圧縮等です。
最初の描画が表示されるまでのレンダリング遅延やその他多数の問題があります。
更に問題になっているINPに対して詳しく調べてみると、デペロッパーツールのパフォーマンスでリアルタイムの分析が出来る事を見付けました。
自分が見ているモバイル(スマホ)での評価はどうかのか?を知る事が出来ます。
パフォーマンスのローカル指標
デペロッパーツールを使ってパフォーマンスのローカル指標を調べる事で、自分のネットワーク環境で現在使っているデバイスから分析データを取得する事が出来るようになります。
つまり、フィールドデーターで分析されたpage speed insightのINP値との比較が出来るようになる訳です。
ローカル指標 実際の分析結果
デペロパ-ツールのパーフォーマンスデータで分析したローカル指標の結果は下記の様になっています。
①LCP 0.56秒 はてなブログタイトル
②CLS 0 秒 レイアウトシフト
③INP 8ms ページの応答性
以上3つの指標共にローカル指標に於いて問題が無い事が判明しました。
自分が使っているモバイル機器でのINP値には問題が無いと言う事になります。
主な対策内容
以上のような調査結果を踏まえて行ったこれまでの対策は、不良になっているページの画像ファイルの大きさを確認し、最低でも100Kb以下に修正する作業を続けています。
ここ数日の間、継続的に分析結果を見ていますが、INPの数値が578㍉秒から554㍉秒に変化して来ています。
ただこの対策内容は、あくまでフィールドデータに対応したもので、自分のデバイス環境下ではローカル指標の改善にどの程度貢献出来たのかはまだ把握出来ていません。
目標に対する効果は?
INPの問題(フィールドデーター)に対する真因がハッキリしていないので、出来る事が限られており、効果の確認までには至っておりませんが、数値が少しでも改善の方向に向いているので希望を持っています。
今後やるべき事は?
ここまで調査した結果、page speed insightで表示されていた不要なJavascriptの削除とかCSSの圧縮などの専門的な技術者でなければ対応が不可能な対策はあえてとる必要はないのでは?と思える様になって来ました。
更に調査をしても限界が見えて来たような気もしますが、まだ出来る事があれば諦めずにやっていくつもりでいます。