SEO
PageSpeed Insightsの点数を上げてWEBサイトを高速化【WordPress】
ページの表示速度がSEOに直結するって訳で、WEBサイトの表示速度改善をしたいけど、何をすればどう改善するのか分からん！という方の為のTipsです。
かなり長いので、『Ctrl + F』の全文検索を使って、自分に関係のある部分だけを見る事をオススメします。
- PageSpeed Insightsで現状の点数を見てみる
- 改善できる項目・診断
- レンダリングを妨げるリソースの除外
- 適切なサイズの画像
- オフスクリーン画像の遅延読み込み
- CSS/JavaScriptの最小化
- AutoptimizeでCSS/JavaScriptを最小化
- 使用していない CSS を削除してください
- 効率的な画像フォーマット
- 次世代フォーマットでの画像の配信
- テキスト圧縮の有効化
- 必須のドメインへの事前接続
- サーバーの応答時間が遅い（TTFB）
- 複数のページ リダイレクトの回避
- キー リクエストのプリロード
- アニメーション コンテンツでの動画フォーマットの使用
- 過大なネットワーク ペイロードの回避
- 静的なアセットでの効率的なキャッシュ ポリシーの使用
- 過大な DOM サイズの回避
- JavaScript の実行にかかる時間
- ウェブフォント読み込み中の全テキストの表示
- Googleアドセンスの読み込み遅延について
- WEBサイトの高速化まとめ
PageSpeed Insightsで現状の点数を見てみる
WordPress初期テンプレートTwenty Nineteenの点数
WEBサイトの表示速度を測れる、PageSpeed Insightsを使って自分のWEBサイトの表示速度を計ってみましょう。
色々なWEBサイトの表示速度をみてきましたが、大体のWEBサイトは60点未満の事が多かったです。Wordpressに最初からインストールされているテーマ（Twenty Nineteen）も表示速度を計ってみると33点という点数となり、このままではWEBサイトの表示が遅く使用に耐えない事も分かります。
| PageSpeed Insightsの点数 | |
|---|---|
| 90～100 | 早い |
| 50～89 | 普通 |
| 0～49 | 遅い |
では、点数を上げる為には何をしたらいいのでしょうか。
改善できる項目・診断
先ほど実行したPageSpeed Insightsの点数画面を下にスクロールすると、『改善できる項目』『診断』があるのが分かるかと思います。
改善できる項目
『改善できる項目』『診断』を改善する事によって短縮できる時間も出ており、優先順位も上から順番になっていますので、どんどん上から順に改善していきましょう。
レンダリングを妨げるリソースの除外
レンダリングを妨げるリソースの除外
ページの First Paint をリソースがブロックしています。重要な JavaScript や CSS はインラインで配信し、それ以外の JavaScript やスタイルはすべて遅らせることをご検討ください。
そもそもレンダリングってなんぞ？という方がいると思いますので、簡単に説明されていただきます。
WEBサイトを見る際に使うブラウザ（ChromeやEdge、Firefox等）は、<head>タグ内にあるCSSやJSなどの外部ファイルを全て読み込んでから、<body>タグ内の記述を描画します。
その<body>タグ内の描画（レンダリング）が<head>タグ内の外部ファイルの読み込みによってブロックされている為『レンダリングブロック』と呼ばれています。
これをWordpressで解決するにはプラグインを使うのが一番楽ですが、プラグインを無駄に増やし過ぎてしまうとそれも表示速度の遅延へとつながってしまうので、注意が必要です。
できれば、必要の無いcssやjsを読み込まない・遅延読み込みする様にfunctions.phpを改造するのが一番良いと思います。
プラグインによって削除方法が異なる場合がありますので、一概には言えませんが、私が記述しているJetPackプラグインのCSS/JS削除方法を紹介したいと思います。
JetPackのJS/CSSの削除
/* ジェットパックのcss消す */
add_filter( 'jetpack_implode_frontend_css', '__return_false' );
/* ジェットパックのアイコンcss消す */
function jetpack_remove_styles_777() {
wp_dequeue_style('jetpack-widget-social-icons-styles');
}
add_action( 'wp_enqueue_scripts' , 'jetpack_remove_styles_777' , 11 );
/* devicepx-jetpack.jsを消す */
add_action( 'wp_enqueue_scripts', 'dequeue_devicepx', 20 );
function dequeue_devicepx() {
wp_dequeue_script( 'devicepx' );
}上記はJetPackプラグインのCSS/JSの削除ですが、私はプラグインで追加されたCSSやJSは全て削除しており、実際に使う部分のみを別で記述し、読み込むようにしています。
一つ一つのCSS/JSは0.01秒くらいしか掛かっていないかもしれませんが、塵も積もればなんとやらです。プラグインを色々使っている方は、今一度確認してみてはいかがでしょうか。
適切なサイズの画像
適切なサイズの画像
適切なサイズの画像を配信して、モバイルデータ量を節約し読み込み時間を短縮してください。
簡単に言いますと、画像のサイズをCSSで無理やり小さくするのは辞めましょう。との事です。
例えば、300px × 300pxの画像があったとして、100px × 100pxにしたいなぁ。でもリサイズめんどくさいなぁ。と思ってCSSで、
img{width:100px;height:auto;}とかしていると怒られます。
記事の中で使う画像をデジカメ等から取り込んだままのサイズで記事に入れたりすると、見た目上はCSSの制御ではみ出ない様にしているテンプレートがほとんどなので問題ないように見えますが、死ぬほど重くなりますのでちゃんとリサイズしてから載せましょう。
画像は、WEBサイトの中でも容量を一番食いますので、適切なサイズの画像を使いましょう。
オフスクリーン画像の遅延読み込み
オフスクリーン画像の遅延読み込み
オフスクリーンの非表示の画像は、重要なリソースをすべて読み込んだ後に遅れて読み込むようにして、操作可能になるまでの時間を短縮することをご検討ください。
画像の遅延読み込みをしましょう。
通常WEBサイトは、見えていない部分（オフスクリーン）の画像もサイトを表示した瞬間に読み込んでいます。
なので、見えていない部分の画像を読み込む必要は全くないので、スクロールをして画像が出る時になったら初めて画像を読み込みましょう。
言葉で説明すると分かりづらいと思いますので、画像を見てもらった方が早いと思います。
画像の遅延読み込みの有り無し
この様に、スクロール外にある画像を、非表示または1pixelの軽い画像に置き換えることが、画像の遅延読み込みと言われるものです。
画像の遅延読み込みの実装方法
では、さっそく実装しましょう。
色々なプラグインがありますが、私がオススメするのは『EWWW Image Optimizer』です。
プラグインを増やし過ぎると碌なことがないので、できるだけ複数の機能を持っているプラグインを使った方がいいです。後でまた出てきます。
EWWW Image Optimizer
EWWW Image Optimizer設定画面にに行き、上部タブの『イージーモード』を選択し、画像の通り『遅延読み込み』にチェックを入れて『変更を保存』すれば完了です。
EWWW Image Optimizerの遅延読み込み
ちゃんと画像の遅延読み込みができているか、チェックする方法として一番簡単な方法は、Chromeの開発者ツール（F12）を立ち上げて、NetworkタブのImgを選択しておきます。一度ページをリロードしてからスクロールしていくと、画像が画面内に入った瞬間に画像が読み込まれている事が分かると思います。
CSS/JavaScriptの最小化
CSS/JavaScriptの最小化
CSS/JavaScript ファイルを最小化すると、ペイロード サイズとスクリプトの解析時間を抑えることができます。
この項目が指す最小化とは、スペースやインデント、コメントアウトを削除して、CSS/JavaScriptの容量を減らす事を指します。
正直人力でもできるのですが、最小化後のCSS/JavaScriptは可読性が全くない状態ですので、更新等々を考えると現実的ではありません。
あまり使いたくはないですが、プラグインをつかっての実装をオススメします。
AutoptimizeでCSS/JavaScriptを最小化
シンプルな設計のAutoptimizeを使います。
Autoptimize
インストールし有効化したら、左メニューより『設定』→『Autoptimize』を開きます。
Autoptimizeの最小化オプション
『JavaScript/CSS コードの最適化』にチェックを入れて、自分が望むオプションがあればそれにもチェックを入れて『変更を保存』します。
ページのソースを開き、CSSの可読性が0になっていたら完了です。
使用していない CSS を削除してください
使用していない CSS を削除してください
スタイルシートから古いルールを削除し、スクロールせずに見える範囲のコンテンツに使用されていない CSS の読み込みを遅延させると、データ通信量を減らすことができます。
読んで字の如し、使っていないCSSを削除しましょう。
Googleが推奨するのは、スクロールせずに見える範囲に入っていない部分のCSSは後から読み込む様にする事ですが、Wordpressでこれをやろうと思うと、非常に手間がかかりますしデザイン変更の手間も半端なく上がります。
勿論できるのであれば、やったほうがいいですが、現実的ではないので、使っていないCSSの記述を消す等の対応するだけでOKだと思います。
私のサイトは、スクロール範囲外のCSSも読み込んでいますが、この項目をクリアできています。
Chromeの開発者ツールで使っていないCSSを洗い出す
まずは、Chromeの開発者ツール（F12）を立ち上げます。
開発者ツールの右上にある『…』をクリック、次に『More tools』をクリック、次に『Coverage』をクリックします。
Coverageの起動方法
これで、Coverageが起動できましたので、ページの再読み込みを開発者ツール上で行いましょう。
リロードボタンをクリック
右下に『Usage Visualization』という項目が赤と緑で分けられているのが分かると思いますが、これが現在のページでの使用率になります。
試しに左下のCSSをどれかクリックしてみますと、上のソース上で何が使われていないかがチェックできます。
CSS使用率
WEBサイトのデザイン更新等で、CSSは煩雑になりやすいので、要らない記述を発見したら消すようにしましょう。
効率的な画像フォーマット
効率的な画像フォーマット
画像を最適化すると、読み込み時間を短縮しモバイルデータ量を抑えることができます。
適切な画像フォーマットで画像を使っているかどうか・画像を圧縮して容量を減らせているかの項目です。
適切な画像フォーマットを選ぶ
画像には色々な種類がありますが、ここではWEBで使われる一般的な『jpg』『gif』『png』だけに絞って簡易的に解説させていただきます。
これらの画像フォーマットは、用途によっては適していなかったりするので、チェックしましょう。
| jpg | gif | png |
|---|---|---|
| 写真等の色数が多い画像 | 256色以下の画像 | 透過の必要な画像 |
pngはjpgに比べると、画像の容量は結構大きくなります。透過処理が必要な場合はpngを使う事も選択肢に入ります。
gifは256色以下の画像の場合は、jpgよりも容量が少なくなる可能性は高いです。
イラストやサイトのロゴマークに使う事が考えられます。
ただ、ロゴマークがシンプルな物であれば、SVG化した方が遙かに軽くなるので、SVG化を検討しましょう。
jpgしか使っていないのであれば、あまり問題はないのですが、pngしか使っていないサイトだと大幅な容量の削減が可能です。
画像を圧縮する
画像は圧縮すると、大体20%～50%近い容量の削減が可能になります。
多少画像が劣化してしまいますが、ぱっと見では分からないレベルなので、気にせず圧縮しましょう。
再び『EWWW Image Optimizer』の出番です。
EWWW Image Optimizer
プラグインを有効化しておくだけで、新規で追加される画像は全て圧縮されます。
過去に投稿した画像も圧縮したい場合は、『メディア』→『一括最適化』をクリックします。
一括最適化
出てきたページで『最適化されていない画像をスキャンする』をクリックします。
最適化できる画像数
最適化できていない画像数が出てきますので、『画像を最適化』をクリック。
後は自動で全ての画像を圧縮してくれます。
初期設定のままだと結構画質が劣化してしまうので、気になる方は『上級者向け』タブにある、『JPG 品質レベル』をいじりましょう。100にしても圧縮率は下がりますが、ちゃんと圧縮されるので、画質の劣化が気になる方は100にしてもいいと思います。
JPG品質レベルの調整
次世代フォーマットでの画像の配信
次世代フォーマットでの画像の配
JPEG 2000、JPEG XR、WebP などの画像フォーマットは、PNG や JPEG より圧縮性能が高く、ダウンロード時間やデータ使用量を抑えることができます。
簡単に言うと、画像の容量をもっと減らせるから、次世代の画像フォーマットで容量を削減しよう！って事です。
この項目で注意するべき点は、どの次世代フォーマットに対応するかです。
| 次世代フォーマットの対応状況 | |
|---|---|
| JPEG 2000 | Safari / iOS Safari |
| JPEG XR | IE |
| WebP | 上記ブラウザ以外ほぼ全て |
参考サイト：CanIuse
現在の対応状況は上記の通りになっており、WebP以外の次世代フォーマットにするメリットはあまり感じられません。
ただ、日本のiPhoneシェアは50％くらいあり、Safari / iOS Safariを無視できる数字ではありません。IEは個人的にゴミだと思っているので無視します。
しかし今後の動きとして、どこのブラウザも使っていない独自規格をずっと使い続ける事は考えづらいので、将来的にSafari / iOS SafariもWebPに対応するのではないかと言われています。
なので、とりあえずはWebPに対応しておきましょう。
WebPへの対応方法
WordPressでのWebP対応はプラグインを利用する方法が一番簡単だと思います。
ここでも『EWWW Image Optimizer』を使います。
EWWW Image Optimizer
インストールし、有効化しましたら、左メニューにある『設定』から、『EWWW Image Optimizer』にいき、『WebP』のタブをクリックします。
WebP化する画面
『JPG, PNG から WebP』にチェックを入れて、『変更を保存』をクリックします。
すると下の方に、下記内容を.htaccessに挿入してください。と出ると思います。
.htaccessの編集はサイトがクラッシュする可能性がありますので、必ずバックアップを取ってから実行しましょう。
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_ACCEPT} image/webp
RewriteCond %{REQUEST_FILENAME} (.*)\.(jpe?g|png)$
RewriteCond %{REQUEST_FILENAME}\.webp -f
RewriteCond %{QUERY_STRING} !type=original
RewriteRule (.+)\.(jpe?g|png)$ %{REQUEST_FILENAME}.webp [T=image/webp,E=accept:1,L]
</IfModule>
<IfModule mod_headers.c>
Header append Vary Accept env=REDIRECT_accept
</IfModule>
AddType image/webp .webp.htaccessへの書き込みに制限を掛けていなければ、下にある『リライトルールを挿入する』をクリックすれば、プラグインが自動的に.htaccessにルールの追加をしてくれます。
リライトルールを挿入する
『挿入成功』と出て、右下が『PNG』から『WEBP』になれば完了です。
これから、追加する画像については全てWebP化されるので問題ありませんが、過去に入れた画像はWebP化されていないので、最適化が必要になります。
左メニューの『メディア』に『一括最適化』というメニューが追加されていると思いますので、そちらから過去の画像を全て一括最適化しましょう。
全ての最適化が終わりましたら、ちゃんとWebP化されているのかをチェックしましょう。
Chromeを使っている方でしたら、『F12』からコンソールを出し、『Network』タブの『img』にしてサイトをリロードしましょう。
Webp化されているかチェック
画像の『Type』がWebPになっていれば完了です。
一応WebPに対応していない、safariとIEでのチェックもしておきましょう。WebP化はされていませんが、ちゃんと画像が見えていれば問題ありません。
テキスト圧縮の有効化
テキスト圧縮の有効化
テキストベースのリソースは圧縮（gzip、deflate、または brotli）して配信し、ネットワークの全体的な通信量を最小限に抑えてください。
要約しますと、サーバーから送るテキストデータ（HTML・CSS・javascript等）を圧縮しましょう。とのことです。
テキストデータのgzip化
.htaccessに追記するだけなので、簡単に実装できます。
プラグインを利用した実装方法もありますが、プラグインは無駄に増やさない方が良いので、使わない方がいいです。
.htaccessは不備があると、WEBサイトを閲覧できなくなる可能性があるので、バックアップは絶対に取っておきましょう。
<IfModule mod_deflate.c>
SetOutputFilter DEFLATE
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|ico)$ no-gzip dont-vary
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/x-httpd-php
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE application/x-font-woff
AddOutputFilterByType DEFLATE application/x-font-opentype
</IfModule>上記のコードを.htaccessに追記すれば完了です。
必須のドメインへの事前接続
必須のドメインへの事前接続
重要な第三者ドメインへの接続を早期に確立できるように、`preconnect` または `dns-prefetch` のリソースヒントを追加することを検討してください。
外部サイトへのアクセスだったり、外部スクリプトを読み込む時には、そのドメインを見つける名前解決(DNSルックアップ)という事が裏で行われています。
この名前解決が少し時間が掛かるので、ページを読み込んだ瞬間に名前解決だけを先にやっておいて、いざ外部サイトへのアクセスだったり、外部スクリプトを読み込む時には、直でアクセスできるようにするのが、事前接続です。
必須のドメインへの事前接続は必要か
外部サイトへのアクセスに関する名前解決は全く必要ないと思います。
この外部サイトへのアクセスが指すのは、例えばFacebookやTwitter等のリンクだったりしますが、9割以上のユーザーはそのリンクをクリックする事はありません。
ほとんどのユーザーは、外部サイトへアクセスする事なくページを閉じるので、事前接続は無駄なリソースを読み込むだけになりますのでやるだけ無駄です。
外部スクリプトの事前接続は必要に応じて追加した方が良いと考えられます。
私の場合は、Google AdSenseとGoogle Analyticsの事前接続だけ追加しています。
<link rel="dns-prefetch" href="//www.google-analytics.com">
<link rel="dns-prefetch" href="//pagead2.googlesyndication.com">基本的に外部スクリプトを読まない様に設計しているので、私の場合は上記2つだけですが、色々な外部スクリプトを読み込んでいる場合は適宜追加しましょう。
ここでひとつ注意が必要なのは、遅延読み込みをしている外部スクリプトは事前接続は必要ありません。無駄に最初の読み込みが遅くなるだけですので気を付けましょう。
外部スクリプトのチェック方法
自分のサイトがどこの外部スクリプトを使っているかをチェックする方法としては、WebPageTestを使うのが簡単で分かりやすいです。
WebPageTestの使い方
『Enter a Website URL』に自分のサイトのURLを入力し、『START TEST』をクリックしましょう。
テストが実行されるので、終わるまで少し待機します。
出てきたページで上部バーの『Domains』をクリックすると、右側に外部サイトのドメインが出てきます。
ここに載っているドメインがサイトで使われている外部ドメインになります。
外部ドメイン
この中から、ファーストビューに関係あるものを事前接続に追加しましょう。
<link rel="dns-prefetch" href="ドメイン名">追加方法は<head>内に上記内容を入れるだけです。
サーバーの応答時間が遅い（TTFB）
サーバーの応答時間が遅い（TTFB）
最初の 1 バイトまでの時間は、サーバーが応答を返すまでにかかった時間を表しています。
借りているレンタルサーバーのプランによって、サーバーの強さは変わるので一概には言えませんが、ある程度（月1000～2000円）のレンタルサーバーを使っているのにも関わらず、このエラーが出る事があります。
その時は、使用中のプラグインを全てを停止して、ひとつづつ有効化しながら確認してみましょう。
プラグインの中には、プラグイン同士が競合（コンフリクト）してしまい、多大な負荷がサーバーに掛かる事があります。もしくは、サーバーへの負荷が高いプラグインも中にはあるので、そのチェックをしましょう。
プラグインを全て停止したのにも関わらずPageSpeedInsightのエラー項目が消えない場合は、大人しくレンタルサーバーのプランを1段階上げましょう。そのサーバープランではWordpressを動かすのは無理な気がします。
また、ある程度のユーザーが来ているサイトですと、キャッシュプラグインを使うとサーバーの負荷が下がり、エラーが消える事もあります。
私は、MixHostサーバー
を利用しているので、LiteSpeed Cacheというキャッシュプラグインを使っています。
複数のページ リダイレクトの回避
複数のページ リダイレクトの回避
リダイレクトを行うと、ページの読み込みにさらに時間がかかる可能性があります。
複数のリダイレクトを掛けている場合にこのエラーが出る可能性がある様です。
例えば、Aページ→Bページ→Cページといった複数のページをまたいでのリダイレクトを掛けているとこのエラーが出ます。
無駄なリダイレクトを掛けるのはやめましょう。
キー リクエストのプリロード
キー リクエストのプリロード
`<link rel=preload>` を使用して、現在ページ読み込みの後のほうでリクエストしているリソースを優先的に取得することをご検討ください。
ファーストビューに関係のあるCSSやJavascript、font等が</body>前にあったりすると出るエラーです。
エラーに出てくるファイルを<head>内でプリロードすればOKです。
<head>
...
<link rel="preload" href="問題のあるCSSファイルのURL" as="style">
<link rel="preload" href="問題のあるjsファイルのURL" as="script">
<link rel="preload" href="問題のあるfontファイルのURL"as="font">
...
</head>アニメーション コンテンツでの動画フォーマットの使用
アニメーション コンテンツでの動画フォーマットの使用
サイズの大きい GIF は、アニメーション コンテンツの配信方法として効率的ではありません。ネットワークの通信量を抑えるため、GIF を使用する代わりに、アニメーションには MPEG4/WebM 動画、静止画像には PNG/WebP を使用することをご検討ください。
読んだままです。
GIFアニメはかなり重い画像ファイルなので、GIFである事が必須でなければMPEG4/WebM等の動画を使いましょう。
過大なネットワーク ペイロードの回避
過大なネットワーク ペイロードの回避
ネットワーク ペイロードのサイズが大きいと、ユーザーの金銭的負担が大きくなり、多くの場合、読み込み時間が長くなります。
ページを全て読み込んだ時の容量が1,600KB以上になるとエラーになります。
大体の場合が、画像の使い過ぎでオーバーする事になると思います。前述した画像のWebP化や、画像の圧縮をしていれば早々越える事はないので、あまり心配しなくても良いと思います。
コンテンツ内で何も画像を使っていないのにオーバーする場合は、デザイン部分で使っている画像が多すぎます。CSSで表現できる所はCSSを使い、アイコン等の簡単な画像はSVGを使いましょう。
静的なアセットでの効率的なキャッシュ ポリシーの使用
静的なアセットでの効率的なキャッシュ ポリシーの使用
キャッシュの有効期間を長くすると、再訪問したユーザーへのページの読み込み速度を向上できます。
画像データや、js・cssといったファイルのキャッシュ有効期限を1か月以上にすればOKです。このキャッシュデータはブラウザに保存され、サイトを再訪問した際に使われてロード時間を短くします。
ただし、サイトのデザイン更新が頻繁にあったりする場合は、CSSやJSファイルをキャッシュするのはやめておきましょう。CSSやJSファイルを更新しても、再訪問したユーザーには新しいCSSやJSが読み込まれない為、デザインが崩れたサイトが表示されてしまう可能性があります。
.htaccessを使ったブラウザキャッシュの実装方法
.htaccessに下記内容を追記しましょう。内容は2か月間キャッシュを保持させる設定になりますので、適宜変更してご使用ください。
<ifModule mod_expires.c>
ExpiresActive On
ExpiresByType image/gif "access plus 2 month"
ExpiresByType image/jpeg "access plus 2 month"
ExpiresByType image/png "access plus 2 month"
ExpiresByType image/svg+xml "access plus 2 month"
ExpiresByType image/webp "access plus 2 month"
ExpiresByType image/x-icon "access plus 2 month"
ExpiresByType text/css "access plus 2 month"
ExpiresByType text/js "access plus 2 month"
ExpiresByType text/javascript "access plus 2 month"
ExpiresByType application/javascript "access plus 2 month"
ExpiresByType application/x-javascript "access plus 2 month"
ExpiresByType application/x-shockwave-flash "access plus 2 month"
</ifModule>過大な DOM サイズの回避
過大な DOM サイズの回避
ブラウザ エンジニアは、ページに含まれる DOM の要素数が 1,500 個を超えないようにすることを推奨しています。ツリーの深さは 32 要素まで、子や親の要素数は 60 個までにするのが最適です。DOM サイズが大きいと、メモリの使用量が増え、スタイルの計算に時間がかかり、レイアウトのリフローというコストが発生する可能性があります。
DOMはHTMLの要素の数だと思って良いと思います。<div></div>これで1要素です。
ツリーの深さは、入れ子にしている数です。
<div>
<div>
<div>
これでツリーの深さは3要素
</div>
</div>
</div>子や親の要素数は、要素の中に入ってる要素の数です。
<div>
<div>要素1</div>
<div>要素2</div>
<div>要素3</div>
<div>要素4</div>
</div>この数をGoogleが定める数以内に収めましょう。
TwitterやFacebook等のタイムライン埋め込み等をしていなければ、問題になる事は少ないと思います。逆にそういった埋め込みをしているとひっかかりやすいので、遅延読み込み等の対策をしましょう。
JavaScript の実行にかかる時間
JavaScript の実行にかかる時間
JavaScript の解析、コンパイル、実行にかかる時間の短縮をご検討ください。配信する JavaScript ペイロードのサイズを抑えると効果が見込めます。
外部スクリプトやプラグインを使いすぎていると、ひっかかりやすいです。
無駄なプラグインが無いか、その外部スクリプトは本当に必要なのかを今一度チェックしましょう。
ウェブフォント読み込み中の全テキストの表示
ウェブフォント読み込み中の全テキストの表示
フォント表示の CSS 機能を使用して、Web フォントの読み込み中にユーザーがテキストを読めるようにしてください。
WEBフォントを使っていて、対策をしていないと大体このエラーが出てきます。
対策方法としては、別の記事になっておりますので、ソチラをご覧ください。
ただ結局のところ、アイコンを使うためにFontAwesomeや、フォントの見栄えを変える為にGoogleFontを使うのは本当に必要なのかを考えましょう。
私は両方とも使っていたのですが、読み込みに時間が掛かるくらいなら使わない方がマシだと判断して使うのをやめました。
Googleアドセンスの読み込み遅延について
Googleアドセンスによる読み込み遅延はなかなか酷いもので、前述した内容を全て実践したとしても90点に届かない場合がほとんどだと思います。
私が実践している、Googleアドセンスタグ対策の記事がありますので、是非ご覧頂ければ幸いです。
WEBサイトの高速化まとめ
上記内容を全て実践できれば、PageSpeedInsightで90点以上を取れていると思います。
SEO的に見て、WEBサイトの高速化は必須だと思いますので、是非実践してみてください。
内容的に簡易的に説明してしまっている部分もあると思いますので、分かりづらい部分等ございましたら是非コメントでお知らせください。
SEO全般にについて書いた記事もありますので、宜しければご覧頂ければ幸いです。
スポンサーリンク
コメント欄
コメントを書く