PageSpeed Insights リニューアル後のスピード改善で実施したこと(診断編)

前回の以下の記事の続きです。迷いましたが、日も空いたので「改善できる項目」と、今回の「診断」で記事を分けました。

PageSpeed Insightsリニューアル後のスピード改善で実施したこと

リニューアル後に追加されたPageSpeed Insightsの「診断」とは

「改善できる項目」とは別に、「ここは良い状態・悪い状態というのを教えてくれるサブ的な速度評価」みたいですが、一部は改善することでスコア上昇がみこめるようです。

改善によりスコア上昇が見込める項目

現在、私も改善途中ですが、以下の項目はスコア上昇が見込めるようです。

  • ウェブフォント読み込み中のテキスト表示
  • 静的なアセットと効率的なキャッシュポリシーの配信
  • メインスレッド処理の最小化
  • 課題なネットワークペイロードの回避
  • JavaScriptの実行にかかる時間の低減
  • 過大な DOM サイズの回避

ウェブフォント読み込み中のテキスト表示

これはWebフォント(woff, woff2など)を利用している場合、ページが初回表示されるときにフォントをダウンロードする必要があるため、その間はデバイス標準搭載のフォントなどで代替表示しときましょう、ということですね。

Google公式のページ(PSIでも「詳細」というリンクがあります)に方法が書いてありますが、日本語で説明してくれているこちらのブログの方が分かりやすいかと。

CSSの@font-faceにて以下のようにfont-display:swap;を追加してやれば本来はクリアできるはず(他にauto, fallback, blockなどのプロパティが指定できますがswapが一番のよう)です。

@font-face { font-display: swap; }

ただし先の項目でフォントのプリロード<link rel="preload">をしている場合は上手くいかなかったので、Webフォントに関してはプリロードをやめました。

追記

別の案件で再度ここに取り組みましたが、WordPressだとAutoptimizeなどのCSS圧縮・連結系のプラグインを使っていると、なぜかGoogleのPSIでは認識してくれず。仕方ないのでbodyタグ直後に@font-faceのスタイルを入れてAutoptimize側の「本文中のCSSを連結する?」のチェックを外し、無事Googleに認識され合格できました。

しかし「スコアが高いから速度が速い」わけではなく、実際@font-faceを2度読んでおり、CSSの連結を外しているだけ遅くなる可能性もある。

一応ms単位で画面レンダリングやフォント表示を確認して双方で表示挙動・スピードがどのくらい違うか正確に観測してみるのがいいだろう。

別の参考リンクから「CSSのプロパティと違って子テーマなどで@font-face { font-display:swap; }と追記するだけでは上書きしてくれない」との意見もあり今回はurlを指定し直したが不要かも知れない。

@font-face {
  font-family: 'Oswald';
  font-style: normal;
  font-weight: 500;
  src:
  url('../fonts/Oswald-Medium.woff2') format('woff2'),
  url('../fonts/Oswald-Medium.woff') format('woff'),
  url('../fonts/Oswald-Medium.ttf') format('truetype'),
  url('../fonts/Oswald-Medium.eot');
  font-display: swap;
}

ちなみに@font-face{ font-family: 'hoge'; }html { font-family: 'hoge'; }body{ font-family: 'hoge'; }との違いを勘違いしていたが@font-faceは「独自のfont-familiyを追加しまっせ」という宣言。これで宣言したfamilyをhtml{}body{}の中でfont-familyとして指定してやる、という使い方のものです。

追記の追記

さらに別案件でAutoptimizeで「インラインのCSSを連結」「CSSコードを最適化」にチェックを入れていても(有効にしていても)PSIの診断をクリアできた。

結論、追加CSS側にURL付きで、パスをきちんと通したうえでfont-display: swap;を記述してやれば消えた。

@font-face { 
   font-family: 'ico'; src: url('/wp-content/themes/nano_tcd065-child/fonts/ico/ico.eot?expxkp'); 
   src: url('/wp-content/themes/nano_tcd065-child/fonts/ico/ico.eot?expxkp#iefix') format('embedded-opentype'), 
     url('/wp-content/themes/nano_tcd065-child/fonts/ico/ico.ttf?expxkp') format('truetype'), 
     url('/wp-content/themes/nano_tcd065-child/fonts/ico/ico.woff?expxkp') format('woff'), 
     url('/wp-content/themes/nano_tcd065-child/fonts/ico/ico.svg?expxkp#ico') format('svg'); 
   font-weight: normal; 
   font-style: normal; 
   font-display: swap; 
} 

ポイントは、WordPressだと@font-faceを記述しているstylesheetがテーマ内にあり、さらに子テーマを作成したりするからパスが通りにくいことにある。パスが通ってないとConsoleにエラーが出るし、font-displayも効いてくれない。なのでurlの部分はきちんと/wp-content/themes/子テーマ名/...という記述をするように。

ただし今回はTCDのテーマで追加CSSが通常のテーマカスタマイザーの中ではなく別のWP管理画面内の項目にあった。だからAutoptimizeを使っていてもうまく行ったのかもしれない。

静的なアセットと効率的なキャッシュポリシーの配信

これは従来からあるブラウザキャッシュの有効化と、キャッシュ保存期間を長くとることでクリアできる項目ですが、今回のリニューアルで期間1年以上でないとクリアが不可になった?ようで、一旦1年以上としました。

けれどCSSやJavaScriptは頻繁に変更しやすいので、あえて警告のまま、期間1週間くらいで妥協するのがいいかもしれません。またGoogleアドセンスやアクセス解析のタグなどは有効期間をいじれないので止むなしです。やり方は「ブラウザキャッシュ htaccess」などでググると大量にでてきます。WordPressならWP Fastest Cacheなどのプラグインを活用すれば80%くらいのブラウザキャッシュは設定・カバーできます。

メインスレッド処理の最小化系

以下の3つはどれも、JavaScriptコードの処理が重かったり、CSSコードが多かったりする場合に警告されるようだ。

  • メインスレッド処理の最小化
  • 課題なネットワークペイロードの回避
  • JavaScriptの実行にかかる時間の低減

基本的には、scriptにはdeferを付け、かつhtaccessでgZip圧縮をJavaScriptとCSSにかけてやれば少しスコア(処理スピード)が改善し、警告は消えた。
https://satoyan419.com/gzip-compression/

過大な DOM サイズの回避

DOM(Document Object Model)は、WebページのHTML要素をオブジェクトとして捉える考え方・モデルのことで、これの総数を1500以下に、要素のネスト(親>子>孫…の構造)の深さを最大32以下にしましょう、という指針のようです。

以下の記事がより詳しいですが、例えばWordPressなどで制作しているならテーマ依存も含めある程度のDOMの数・ネストは構造上避けられなさそうです。スコアへの影響が大きくなさそうなら、一旦スルーでもいいかなぁと思っております。

http://blogs.itmedia.co.jp/webnoma/2018/11/19.html

カスタム速度の記録と計測

結論から言うとスコア/ページスピードには関係なし。ページを分析するためのツール(UserTimingAPI)を使ってサイトを分析しましょうね、ということみたい。監査の合否としては「どこからどこの表示・処理に何秒かかっているのか」を測るためのJavaScriptコード、それをConsoleに出力するコードを書けば消えますが、Chromeのデベロッパーツールはもっと使いこなしたいと思っていたので、より詳しくはこちらなどを参照してください。

https://5exp.net/pagespeedinsights-customspeed-solved

https://developers.google.com/web/tools/chrome-devtools/evaluate-performance/timeline-tool

GoogleタグマネージャやYahoo!タグマネージャを使っている場合

Googleタグマネージャ(GTM)やYahoo!タグマネージャ(YTM)、また以前のGoogleAdwords(現Google広告)のタグが埋め込まれている場合、これも処理が重くなりスコアが低下する原因となる。 Google広告やGoogleAnalytics, SearchConsoleのタグであればGoogleタグマネージャに統合できるはずだが、Yahoo!系のタグはまとめられない。逆もまた然りなので、GoogleとYahoo!両方の広告に出稿しているのなら、両方のタグを使わざるを得ない。

それぞれの設置ガイドラインにも書いているが、Googleタグマネージャのタグは<head>のなるべく上に、Yahoo!タグマネージャのタグは</body>の直前に設置することが推奨されている。

またこれらのタグには<noscript>というタグが含まれているが、これは「JavaScriptに対応していないブラウザを使用していたり、JavaScriptの実行を拒否しているユーザー」のために設置するものなので、思い切って削除した。

AdobeのTypeKitは重かった

直接は関係ないのですが、今回の高速化したサイトではAdobeのTypeKitで、東南アジア(日本)のフォントを使うためのscriptが使用されていた。これがかなり重く、サイトで使われてもいなかったのでTypeKitは削除、これでスコアが90代まで上昇した。

ちなみにこのTypeKitのscriptをdeferした場合、なぜかLighthouse(Chrome拡張として元からあったツール)でのSEOのスコアが低下した(なぜか<meta>タグのviewportが無いと警告を受けた)ので、そういった意味でもAdobeは使いづらかった。

余談ですが、Adobeの最近のデザインツールはAI導入したり、背景から人物を完全に消したりとすごい進化だが、デスクトップのCreativeCloudのツールがメモリやパワーを食い過ぎるとか、どこか残念な節が拭えません。

まとめ

PSIがリニューアルして初の高速化の実施でしたが、周りのWebマスターの声も「厳しすぎる」といった批判的な意見が聞こえます。実際、こんかいの高速化は骨が折れました。しかし、曖昧な理解だったasyncやdeferへの理解、scriptをなぜ</body>の直前で呼ぶのか、linkのpreloadについてなどの理解を深める良い機会でした。

Googleはページの画像読み込みやレンダリングブロックの除去などの小手先の施策よりも、Webページ自体の軽量化(省HTML/CSS, 省JavaScript)を推奨しているように感じました。AMPやPWA、またJSON-LDなどによるリッチカードの作成など、表示速度だけでなく、検索結果一覧自体にWebサイト側から影響できる窓口が増えています。Webサイト制作はいずれAIの発達で不要な職業になるので、こういった高速化や新しいWeb技術を、私も身につけていきたいと思います。