最近はGoogleさんのウェブサイトのページの評価がうるさくなってユーザーエクスペリエンスというものが重視される傾向。今年はCore Web Vitals(コアウェブバイタル)とかいうものに振り回された(振り回されている？)ウェブサイトの管理者も多い筈。
コアウェブバイタルの3つLCP, FID, CLS、それとFCPの合わせて4つの指標が重要ね。コアウェブバイタルは今年は猶予期間だからとのんびり構えないで早めに対処した方が良さげ。対処するとページの表示速度が改善され、より多くの閲覧者が訪れる、少なくとも減りはしないことが期待される。
難しそうだからと途方に暮れることはなく、GoogleのPageSpeed InsightsやChromeブラウザ内蔵デベロッパーツールのLighthouseを使えばご丁寧に改善点を教えてくれるので1つ1つ潰していくだけ。
で、今回は難しそうで簡単そうでそうでもない「使用していない JavaScript の削除(Remove unused JavaScript)」と「使用していない CSS を削除してください(Remove unused CSS)」の2つの対処。
現在の「がとらぼ」は大きく2つに分かれていて「画面が暗いブログ」と「画面の明るい中華スマホのスペック紹介」になっている。1つのWordPressでテンプレートを2つ用意してブログとスマホ紹介で見た目が全く異なるようになっている。ブログ用の方はフルスクラッチの自作テンプレートでCSSも全部自作。スマホ用の方はテンプレート自体は自作だけど見た目の部分についてはほぼSemantic UIというフレームワークに頼っている。Semantic UIは導入そのものはとても簡単にできるのだが、単に「入れました、使いました」だとGoogleさんの評価が大変悪い。指摘されるのが「使用していないJS/CSSを削除してください」。今回はそれを改善する。
Semantic UI以外でも大きめのフレームワークを使うと同じ指摘を食らう筈だが、対処方法は同じなので少しは参考になる部分がある筈。
PageSpeed InsightsでSemantic UIを使っているページを診断してみた。「改善できる項目」の中に「使用していない JavaScript の削除」と「使用していない CSS を削除してください」がある。(画像の赤い四角の部分)
「使用していない JavaScript の削除」と「使用していない CSS を削除してください」をクリックするとそれぞれ指摘対象のJavascript, CSSファイルのPathが表示される。
この、「使用していない JavaScript の削除」と「使用していない CSS を削除してください」は指摘されているJS/CSSファイルが要らないから削除しろということではなく、指摘されているファイル内に使っていないコードが多すぎるのでそれを省けというもの。ここで指摘の意味を取り違えると対処方法がわからなくなる。Googleさんの指摘って意味が判らないのが多いから困る。
Chromeブラウザを起動して[F12]キーを押す。Macだと[Command]+[Option]+[I]かな?
Chromeブラウザ内蔵デベロッパーツールが起動する。
ここで、[Ctrl]+[Shift]+[p]を押す。Macの場合は[Command]+[Shift]+[p]かな?
小窓がポップアップするのでテキストボックスにshow coverageと入力する。部分一致で候補が表示されるので実際にはcoverとかで良い。2022年12月2日追記: その後show coverageは日本語表対応になったので「カバレッジを表示」を探してください。show coverageでは候補が出なくなっていると思われます。
「[Drawer] Show Coverage」という候補が表示されるのでそれをクリックする。2022年12月2日追記: その後、日本語対応になったので「カバレッジを表示」という候補をクリックしてください。
下部にドロワーが表示されるというかウィンドウが分割されたようになって、Coverageタブが選択された状態になる。
その中央の[]をクリックする。
そのページで読み込まれているJava scriptやCSSのファイルがリストされ、そのファイルで使用されているコードの割合が表示される。上の画像では赤枠で囲ったsemantic.min.cssがSemantic UIのCSSファイルだが、約630KBのファイルを読み込んで、そのファイルのCSSコードの内ページ表示で使用されているのが僅か2.2%であることを示している。つまり630KBも読み込んで97.8%は無駄になっている。これは指摘されても仕方ない。(本当はもう少し多くのコードが使われる)
このリストの中から目的のファイルの行をクリックする。(上の画像だと赤枠で囲ったsemantic.min.cssをクリック)
ファイルを(ダブル)クリックすると上側のConsoleタブが選択されていたところがSourcesタブに切り替わる。(基本的には自動の筈だが切り替わらない場合は手動で[Sources]をクリック)
クリックしたファイルのコードが表示される。改行,余分な空白/タブが削除されたコンパクト化されているcss,jsファイルもフォーマット化されてわかりやすく表示される。
使用中のコードと未使用のコードが色分けされるので青緑の帯が付いた(使用されている)コードをコピーしてエディタなどに貼る。繰り返して使用中のコードを全て抜き出す。
別ページでも同様に繰り返して使用中のコードを抜き出す。普通のWordPressのブログならトップベージ、固定ページ、投稿ページ、記事のリストのページのようにページの種類ごとに各1ページずつから抜き出せば良いかと。ただし、テーブルだとかアイコンだとか特定のページでしか使用していないコードは別途抜き出しの必要も。
ある程度名の知れたフレームワークならCSSコードが系統で分けてあるはずなので整理しながら重複しないように抜き出せる筈。
これで、一応ページの表示そのものに使用されているコードだけは抜き出せたが、それだけではちょっと足りない筈。
元ファイルと比較する方が良い。CSSにに慣れてる人なら先の使用されていないCSSコードの中に必要なコードが混じっていることに気付くかもなので、使用されていないCSSコードに分類されていてもコピーしておけば良い。
元ファイルと比較した場合は元ファイルの分類別コメントをコピーしておく方が後の編集がラクになる。
@media hogeとかイベント・アニメーション関連などはモレ注意。大抵は使用中コードの青緑でマークされている前後に隣接して存在するのであるていどは判るようになっている。
使用中のコードを抜き出して編集したファイルをsemantic-subset.cssなどのファイル名で保存する。
semantic-subset.cssからコメント,改行,タブ,余計な空白を除去してsemantic-subset.min.cssを出力する。
必要に応じてsemantic-subset.min.cssをBrotli圧縮またはGzip圧縮する。(ウェブサーバが静的Brotli/Gzip圧縮対応の場合)
HTMLファイルのHTMLヘッダのCSSファイルのpath+ファイル名を変更する。WordPressならテーマのディレクトリにあるheader.phpと必要に応じてfunctions.phpでファイルの指定を変更する。
JavascriptもCSSの場合と一応同じ方法が使える。ただし、ページ表示しただけでは表示で使用したコードだけしかマークされない。Semantic UIのサイドバーであればトグルボタンを少なくとも2回押してスライドオープン、クローズを実行しなくては必用なコードと不要なコードが判らない。動作に必要なコードを削ってしまうとJavascriptの実行エラーで他の必要なJavascriptまで動かなくなると困った事態になるかもしれない。Semantic UIのJavascriptは1つの巨大なファイルに複数の機能別に関数が分かれて入っているので使用する機能の関数だけまるごと抜き出す方が無難。Javascriptの巨大なコードがスラスラ理解できる人はさらに不要なコードを取り除いてファイルをダイエットさせれば良いかなと思う。
Semantic UI 2.4.2のdist/semantic.jsは以下の様になっている。
site: 11-498行
form: 499-2205行
accordion: 2206-2818行
checkbox: 2819-3651行
dimmer: 3652-4385行
dropdown: 4386-9047行
modal: 9048-10083行
nag: 10084-10591行
popup: 10592-12124行
progress: 12125-13056行
rating: 13056-13565行
search: 13566-15071行
shape: 15071-15993行
sidebar: 15994-17027行
sticky: 17028-17987行
tab: 17988-18940行
transition: 18940-20036行
api: 20037-21204行
visibility: 21205-22515行
たとえば、「がとらぼ」のスマホ用ページならSemantic UIのJavaScriptはサイドバーしか使っていないのでサイドバー関連の15994〜17027行だけ抜き出してsemantic-subset.jsのようなファイル名で保存する。
semantic-subset.jsからコメント,改行,タブ,余計な空白を除去してsemantic-subset.min.jsを出力する。
必要に応じてsemantic-subset.min.jsをBrotli圧縮またはGzip圧縮する。(ウェブサーバが静的Brotli/Gzip圧縮対応の場合)
HTMLファイルのHTMLヘッダのJavascriptファイルのpath+ファイル名を変更する。WordPressならテーマのディレクトリにあるheader.phpと必要に応じてfunctions.phpでファイルの指定を変更する。
これで、ファイルサイズ自体が大幅に小さくなる。
変更前のsemantic.jsは737KB。余計な空白・コメント・改行の無いsemantic.min.jsが275KB。
semantic.jsからSemantic UIのサイドバー機能のコードだけをまるごと抜き出したファイルサイズは約34KB。余計な空白・コメント・改行の無くしたsemantic-subset.min.jsが13KB。ファイルサイズでは約5%になった。
この小さくなったファイルの内、ページ表示時に使うコードは8.5%で91.5%が無駄なコードとして指摘される。サイドバーのオープン・クローズを実行した場合、使用コードが80.1%になり未使用コードが19.9%になる。結構使われるのよね。
でも、正直なところ、サイドバーのスライドによるオープン・クローズ程度なら1KBも要らないので自分で作っちゃった方が圧倒的にコンパクトな筈。
CSSとJavascriptのダイエットが完了したのでもう一度PageSpeed Insightsで計測してみた。ダイエット前のスコアが52で、ダイエット後が64なのでスコアが12上昇したことになる。また、「使用していない CSS を削除してください」の指摘は無くなり、「使用していない JavaScript の削除」の指摘対象からは今回スリムになったsemantic-subset.min.jsは消えている。しかし、残り3つの指摘されているファイルがあるので、これもなんらかの対応が必用。
ちなみに、他に指摘されている改善可能な項目は「適切なサイズの画像」「次世代フォーマットでの画像の配信」「効率的な画像フォーマット」。
「適切なサイズの画像」はモバイル端末には画面サイズに合わせて小さい画像を出せというやつ。pictureタグを使えば指摘されない。WordPressのブログ等ではメディアの扱いをWordPressまかせにしていれば指摘されない部分。
ただし、素のWordPressでは次世代フォーマットの画像を扱えないので「次世代フォーマットでの画像の配信」で指摘を食らう。
「がとらぼ」では画像をWordPressまかせでなく独自管理にしていてimgタグを使っている。画像を複数サイズ用意するのが面倒なのでpictureタグは使っていない。その代わり基本出力が次世代フォーマット画像のWebP。WebP非対応ブラウザにはJpegかPNGを送る。これはNginxまかせ。
基本がWebPなら「次世代フォーマットでの画像の配信」の指摘は喰らわない筈なのに指摘されてるのはAliExpressの商品画像のせい。これは手出しできない他所のウェブサイトなのでどうしようもない。「効率的な画像フォーマット」もAliExpressの同じ画像が指摘を受けている。迷惑な話。
はじめまして。貴重な記事、ありがとうございました。
以下の、”コードをコピーしてエディタなどに貼る”
使用中のコードと未使用のコードが色分けされるので青緑の帯が付いた(使用されている)コードをコピーしてエディタなどに貼る。・・・
このコピーしてエディタなどに貼る、やり方が分かりません。
素人なもので、こんなことも分からないのか！！と、・・・そうなのです。
簡単でも構いませんので、ご伝授頂けましたら嬉しいです。
よろしくお願いいたします。
使用中コードと未使用コードの色分けの帯が表示されている窓で、色分け帯のすぐ右隣あたりを(マウス)ポインタで合わせて左クリックしながら上下にポインタを動かすと行で選択できます。[Ctrl]+[C]または[Ctrl]+[Insert]で選択した内容をコピーできます。
エディタは例えばWindowsであればメモ帳などですが、文字操作と保存ができれば何でも良いです。ただし、勝手に変換されないことが条件なのでワープロ(Wordなど)は向いていません。
貼り付けたい場所にポインタを合わせて、[Ctrl]+[v]または[Shift]+[Insert]を押せばコピーしたコードを貼り付けられます。
編集を完了させたら、そのファイルを保存して、元のCSS,Javascrptファイルと置き換え(アップロード)するという流れになります。
なお、ファイルを置き換えると(内容によっては)表示に不具合が発生することがあるかもしれないので、置き換え前のファイルは先に必ずバックアップしてください。
初めまして。ブログ初心者です。
『Largest Contentful Paint』を改善したくて色々調べたのですが
なかなか改善できず、何とかこのページにたどり着いたのですが、
このサイトの下記の部分から何をしたら良いかわからなくなってしまいました。
青い行を抜き出したものを、どこに貼り付けたら良いのでしょうか？
『使用中のコードを抜き出して～
～semantic-subset.min.cssを出力する。
必要に応じてsemantic-subset.min.cssをBrotli圧縮またはGzip圧縮する。(ウェブサーバが静的Brotli/Gzip圧縮対応の場合)
HTMLファイルのHTMLヘッダのCSSファイルのpath+ファイル名を変更する。WordPressならテーマのディレクトリにあるheader.phpと必要に応じてfunctions.phpでファイルの指定を変更する。』
お手数おかけいたしますがご返答いただけると助かります。
この記事は、「使用中のCSSに含まれているムダなコードを取り除きましょう」なので、現在使用しているCSSファイルを直接編集してムダを取り除いて上書きするか、現在使用しているCSSファイルとは別に新しいファイルを作ってそこに使用するコードだけをコピペして保存するかになります。前者は編集に間違いがあった場合に困ることになるので記事では後者を書いています。それが「使用中のコードを抜き出して編集したファイルをsemantic-subset.cssなどのファイル名で保存する。」の部分です。
コピペしたCSSコードには見やすいように改行や不要な空白やタブが入っているのでそれもムダです。CSS中のコメントもムダです。そのムダを省くのは「css minify」などでググるとオンラインツールなどもあるのでそれらを利用するのが簡単かと思います。で、そうやってhogehoge.cssからムダな文字を省いたのをhogehoge.min.cssなどのさらに別の新しいファイルに保存します。このやり方は慣例というだけでhogehoge.cssを上書きしてはいけないということでも、〜.min.cssというファイル名にしなければならないというわけではありません。ただし、これも上書きしてしまうと後で編集したいときに困るので普通は上書きはしません。
最後に、現在使用中のHTMLヘッダの中に「ページを表示するために使用するCSSファイルのPath」が書かれているのでそれを新しく作ったファイルのPath (〜.min.css)に書き換えます。それが記事中の「HTMLファイルのHTMLヘッダのCSSファイルのpath+ファイル名を変更する。WordPressならテーマのディレクトリにあるheader.phpと必要に応じてfunctions.phpでファイルの指定を変更する。」の部分になります。
これなら、「ムダを省きました」→「なんか表示がおかしい」となったときでもHTMLヘッダ内のCSSのPathを元に戻せばすぐに復旧できるので簡単です。
なお、CSSのムダなコードを手作業で省くというのはCSSに慣れていないと結構難しいです。記事中では「CSSにに慣れてる人なら先の使用されていないCSSコードの中に必要なコードが混じっていることに気付くかもなので、使用されていないCSSコードに分類されていてもコピーしておけば良い。」としか書いていませんが、「ページ表示時以外に使うコード」、「ブラウザの窓サイズが違うときに使うコード」などはChromeのデベロッパツールでは「使用しないコード」に分類されるのでそこに気付けないと上手くいかないことになります。
早急なご返答ありがとうございます。
重ね重ね申し訳ありませんが、『最後に、現在使用中のHTMLヘッダの中に「ページを表示するために使用するCSSファイルのPath」が書かれているのでそれを新しく作ったファイルのPath (〜.min.css)に書き換えます。』の部分の、『現在使用中のHTML』をどこで表示させるのかもわかりません。。。
ホントに素人で申し訳ないのですが、このサイトの画面で説明していただいているように、どの画面で何をしたら良いかまで教えていただけると助かります。
個人的な対応で非常に申し訳ありませんが、是非とも宜しくお願い致します。
「ここ屋マネースクール」さんの名前からググりまして、勝手に拝見したブログはCMSがWordPressでテーマがCocoonとお見受けしました。
Cocoonは全く知らないので当てずっぽうでテキトーなことを書きますが、よくある外部CSS(ページ本体のHTMLファイルとは別にCSSファイルを用意)ではなく、HTMLヘッダ内にstyleタグがあってその中にほぼ全て？のCSSがCocoonにより自動で書き出されるインライン形式のようです(或いは何かのSEO系プラグインを使ってるならばそれが)。
この場合は、HTMLファイル内にCSSを持つわけなので、これまで書いた「HTMLヘッダ内のCSSファイルのPath云々」という部分は当てはまらなくなります。おそらくCocoonのテーマが使う専用のCSSファイルがあるでしょうからそれを編集することになります。この場合はテーマの中で使用するファイル名が決まっているので新しく勝手にファイルを作るという方法はダメな筈で、元からあるCSS用のファイルを編集して上書き保存する形になります。編集する前にバックアップを取る方法が良いかと思います。Cocoonを使ってないのでCSSのファイル名はわかりませんが、WORDPRESS/wp-content/themes/cocoonの中にあると思われます。一般的なWordPressのテーマであればWORDPRESS/wp-content/themes/使用中のテーマ/style.cssですが、インラインスタイルとして出力するテーマだと違うファイル名のことが多いかと。
WordPressの管理画面でオンラインで行うということであればメニューの「外観」「テーマエディタ」を選べばいきなり現在使用中のテーマのstyle.cssが自動的に開きます。WordPressではそういうことになっています。ですが、テーマの造りが特殊な場合はテーマが使用するCSSが別のファイルになっているかもしれないので右列のテーマファイルのリストからそのテーマ用のCSSのファイル(何かは知りません)を選んで編集することになります。編集が終わったら左下の「ファイルを更新」で保存しますが、保存したら編集前の状態が無くなるので更新管理は自分でなんとかするしかないです。「ヘンになったので戻したいけど戻せない、困った」だけは避けるようにして下さい。
あと、WordPressではテーマの「style.css」というファイルの存在と、style.cssファイル内の最初の10行程度のコメントのようなものがWordPressの中でだけ特別な意味を持っているので「こんなファイル消しちゃえ」とか「コメントだから消しちゃえ」とやると困ったことになるのでご注意ください。
また、CSS内の改行や不要な空白やコメントなどを除去するのはCocoon側(或いは何らかのSEO系のプラグインを使ってればそれが)自動的に行ってくれるでしょうから前回返信に書いた「オンラインツールなどもあるのでそれらを利用」云々とか「ファイル名を〜.min.cssで保存」とかは不要です。
で、最後に蛇足のような実はこれがメインのような書き難いことを書きます。
本来はムダなCSSコードは無いに越したことはないのですが、CSSをHTMLファイル内にインラインで出力する場合はGoogleのPageSpeed Insightsではかなり甘く採点されるようなのでおそらく「CSSに含まれるの無駄なコード」の存在は指摘対象にはなっていないのではないかと思います。つまり、LCPが要改善ということはCSSではなく別の要素がレンダリングを大きく妨げていると思います。先ずは、PageSpeed InsightsやChromeブラウザのデベロッパツールのLighthouseなどでレンダリングを妨げているのが何かを調べてそれを改善するのが近道だと思います。
ありがとうございます。
確かにグーグルアドセンスに申請するHTMLを入力した時点でPage Speed Insightsの数値が落ちたので、とりあえず気にせずブログ作成に勤しみたいと思います。とは言え、グーグルアドセンスに合格するためには、あまり記事を増やさない方が良いとも聞いているため、下書きでコツコツ投稿ページを書きつつ、合格のためのリライト等をしていきたいと思います。
ご親切・丁寧にありがとうございました。