レンダリングを妨げるリソースの除外！

レンダリングを妨げるリソースの除外！

久しぶりにサチコを覗いてみると、以前よりもレスポンスが悪くなっていました。

「レンダリングを妨げるリソースの除外！」が出ていて、0.26秒時間が余計にかかっているようです。

基本ソフトやアプリケーション・ソフトが、画面に表示すべき内容を、与えられたデータから計算しながら描き出すことです。ウェブブラウザが受信したHTMLのデータに基づいてページを表示すること、ゲームソフトが立体的で美しい景色を描き出すことなどがレンダリングの具体例です。

参考：コトバンク「レンダリング（読み）れんだりんぐ（英語表記）rendering」

”https://cdn.jsdelivr.net/npm/swiper@8/swiper-bundle.min.css?ver=6.1”というリソースが対象です。

cssということから、どうやらスタイルシートのようですね。

文書のレイアウトに関する情報を記述した文書の雛型。インターネットのHTML文書に対して広く利用されている。

参考：goo辞書「スタイル‐シート【style sheet】 の解説」

今回は、「わからないことを解決する」と言ったので、これが解決できるまで突き進めて行きたいと思います。

正直、こんな作業は、プログラミングの世界の話だと思うので、畑違いの気がするのは私だけでしょうか？

ズブの素人が、なんでここまでやらなきゃならないのか！？

まあでも、やらないと評価してくれないようなので、あの手この手を使いながら、解析していきたいと思います。

レンダリングを妨げるリソースの除外
0.26 s
ページの First Paint をリソースがブロックしています。重要な JavaScript や CSS はインラインで配信し、それ以外の JavaScript やスタイルはすべて遅らせることをご検討ください。詳細FCPLCP
URL
転送サイズ
減らせるデータ量
…swiper@8/swiper-bundle.min.css?ver=6.1(cdn.jsdelivr.net)
5.5 KiB
780 ms

とりあえず今日は、現象まで！

明日デバッグをしてみます！^^

問題点の意味を知る

まず、やらなければならないことは、問題点の意味を知ることですよね！

ド素人の私にとっては、意味を解読するだけでも、物凄く時間がかかります。

First Paint をリソースがブロック

ページの First Paint をリソースがブロックしています。

「First Paint」とは、ページ内で一番最初に表示される画像のことです。

FirstPaint は Paint Timing API の一部です。ナビゲーションからブラウザーが読み込んだ最初のピクセルを画面にレンダリングします。

参考：MDN Web Docs「First paint」

その画像を表示する際に、スタイルシートが邪魔をしているということですよね。

重要な JavaScript や CSS

重要な JavaScript や CSS はインラインで配信し、

「重要な JavaScript や CSS」というのは、「First Paint」の邪魔をしているものという意味だと思います。

「インラインで配信」というのは、cssをhtml内に直接埋め込むことをいうようです。

スタイルシートを、htmlのどの部分に直接埋め込めばいいのか？

それがわかれば、なんとかなるのかもしれません！？

もう少し、調べてみようと思います。

それ以外の JavaScript やスタイル

それ以外の JavaScript やスタイルはすべて遅らせることをご検討ください。

それ以外というのは、「First Paint」に関わらないものという解釈でいいと思います。

「このリソースが、邪魔をしていますよ！」という警告が出るので、それ以外は未対応でいいと思います。

リソースと画像の関係

デベロッパーツールでリソースと画像の関係を調べてみると、リソースが画像の前に割り当てられていることがわかります。

画像の後に割り当てられるようにすれば、回避できると思います。

ところが、このリソースは出たり出なかったりすることから、恐らく広告関係のリソースだと思います。

だとしたら、対応しても意味がないかもしれませんね！？

でも、対応するとなると、現在cssを設定しているテーマファイルを特定する必要があります。

動的に割り当てられているとすると、その仕組みを理解する必要があります。

まだまだ時間がかかりそうです。

リソースを見つけました

ということで、リソースの場所を見つけることができました！^^

こんなところに隠れていたんですね。

知ってる人が見たら、一目瞭然なのかもしれませんが！？

他のクラウドマークを見ると、すべてグーグル関係のものだということがわかりました！^^

だとすると、やっぱり広告関係ですね。

このブログは既にアドセンス関係の処理は、すべてフッターでやるようにしています。

FCP・LCP関係の対応なのですが、何をどのようにやっているのかは説明することができません。

それと同様に、このcssもフッターで実行するようにすれば、恐らく大丈夫なのだろうと思います。

まだまだ続きそうです。

うまくいったら、またここで説明します！^^

WordPressでCSSをフッター(wp_footer)で読み込む方法

ということで、「ｃｓｓをフッターで読み込む方法」 という記事を見つけたので、参考にさせていただきました。

それで、書いたジャバスクリプトがこんな感じです。

子テーマの「functions.php」に追加しました。

●wp_register_styleというのが、スタイルシートの登録

●wp_enqueue_styleというのが、スタイルシートの読み込み

のようです。

「wp_register_styleとwp_enqueue_styleの使い方とその違いとは」を参考にさせていただきました。

どうもありがとうございます。

対象のcssがフッターに追加された

その結果、ヘッダーに定義されていたものが、フッターにも定義されました。

“https://cdn.jsdelivr.net/npm/swiper@8/swiper-bundle.min.css?”

私的には、ヘッダーに定義されたものがフッターに移動するイメージだったのですが、ヘッダーにはそのまま定義されたものが残っていました。

これではダメなのかもしれません！？

レンダリングを妨げるリソースの除外
0.49 s
ページの First Paint をリソースがブロックしています。重要な JavaScript や CSS はインラインで配信し、それ以外の JavaScript やスタイルはすべて遅らせることをご検討ください。詳細FCPLCP
URL
転送サイズ
減らせるデータ量
…swiper@8/swiper-bundle.min.css?ver=6.1.1(cdn.jsdelivr.net)
5.5 KiB
780 ms

転送サイズと、減らせるデータ量も変わっていないし、 経過時間も0.26 s⇒0.49 sと、返って悪くなってしまいました。

定義される順番も、相変わらず画像よりも前にきています。

ところが、一時的かもしれませんが、全体的にサクサク動くようになりました。

変更前

変更後

リソースのスケジュール設定という項目が無くなったので、１２．７４ミリ秒短縮されたのではないか！？と思います。

下手をすると、ｌｃｐ（Largest Contentful Paint）も2.4秒台をたたき出すので、それなりには効果があるのかもしれません！？

しかし、ネックとなっているのは、ｆｃｐ（First Contentful Paint）2.0 秒なので、まだまだ引き続き調査が必要です。

仕組みを理解するのに時間を費やせないのが現状

ちなみに、この手の作業は、今までもいくつかやってきているのですが、その都度手探り状態で、何とか切り抜けてきたものがほとんどです。

だから、完全にその仕組みを理解しているわけではなくて、「結果的にうまくいった」で乗り越えてきました。

時間の都合で、どうしても仕組みを理解するところまで、時間を費やせないのが現状です。