Twitter ウィジェット削除比較は PageSpeed で9点改善となりました

PageSpeed Insights の点数改善で、Twitter のウィジェットを削除した場合の点数を比較しました。

Twitter のウィジェットとは以下のようなものです。

Twitter Publish からウィジェットを作成してウェブサイトに貼り付けることができます。

しかし、Twitter ウィジェットは PageSpeed との相性がよくないです。 PageSpeed で指摘される様々なポイントが、Twitter ウィジェットとぶつかります。

PageSpeed 対策で削除

まずは試しに、Twitter ウィジェットを削除してみましょう。
どれくらいの影響があるのかその上でウィジェットの利用の参考にすると良いです。

削除前の点数

削除前はモバイル版で、80点でした。

削除後の点数

削除後はモバイル版で、89点でした。

モバイルで+9点の改善となりました。

デスクトップ版は変わらず

Twitter ウィジェットを削除してもデスクトップ版への影響はありませんでした。

ウィジェット削除で変わる PageSpeed 項目

Twitter のウィジェットを削除すると、PageSpeed で指摘される項目が減ったり変化しました。

ページの表示を遅延させる要素が減少して、表示速度が改善したということになります。

消えた項目

以下の項目は PageSpeed で表示されなくなりました。

  • 次世代フォーマットでの画像の配信
  • 第三者コードの影響を抑えてください 第三者コードによってメインスレッドが 270 ミリ秒間ブロックされました
  • メインスレッド処理の最小化 
  • 静的なアセットと効率的なキャッシュ ポリシーの配信
  • JavaScript の実行にかかる時間の低減 

5項目が削除されているので、多岐に渡り効果が出ています。

変化した項目

以下の項目は PageSpeed で変化がありました。

  • リクエスト数を少なく、転送サイズを小さく維持してください 74 件のリクエスト

リクエスト数が74から25に減少しました。

Twitter ウィジェット削除比較まとめ

今回 Twitter のウィジェットを削除してみたところ、PageSpeed のモバイルで9点の改善となりました。

また、前後比較により削除されたり変化した項目を見ると、Twitter ウィジェットのように外部通信するウィジェットが表示のパフォーマンスに大きな影響を及ぼしていることがわかります。

PageSpeed 視点では Twitter ウィジェットはネガティブに働きますが、Twitter ウィジェットの有効活用を目指しているケースもあるはずです。

ケースに合わせて Twitter ウィジェットをご利用ください。

「ウェブフォント読み込み中のテキストの表示」対策で PageSpeed 点数改善

PageSpeed Insights の表示で、「ウェブフォント読み込み中のテキストの表示」をせよと指示されるケースの対策です。

原因

この表示される理由は、ウェブフォントのロードによりページ表示の遅延になっているためです。

近年では、fontawesome や googlefont など woff2 フォントが原因となり、この指摘が出てしまうケースが多いのではないでしょうか。

改善対策

ウェブフォントが原因の遅延対策としては、二つご紹介します。

  • CSS でフォントを遅延ロードする
  • ウェブフォント読み込みを削除する

CSS を利用する場合はの @font-face を指定してフォントを遅延読み込みさせます。

CSS で遅延ロード、@font-display を swap 指定にする

CSS を編集して @font-face に swap を設定します。

ただ、今回指摘された箇所は WordPress プラグイン内の CSS でした。ですので、 WordPress プラグインの CSS に対して直接 @font-face を指定しました。

まずはプラグインの該当 CSS を見てみます。

@font-face{font-family:ez-toc-icomoon;src:url(fonts/ez-toc-icomoon.eot?-5j7dhv);src:url(fonts/ez-toc-icomoon.eot?#iefix-5j7dhv) format('embedded-opentype'),url(fonts/ez-toc-icomoon.ttf?-5j7dhv) format('truetype'),url(fonts/ez-toc-icomoon.woff?-5j7dhv) format('woff'),url(fonts/ez-toc-icomoon.svg?-5j7dhv#ez-toc-icomoon) format('svg');font-weight:400;font-style:normal}

実際にこちらがロードされているコードです。フォントが複数指定されています。

@fon-face に font-display の swap を追加します。

@font-face{font-family:ez-toc-icomoon;src:url(fonts/ez-toc-icomoon.eot?-5j7dhv);src:url(fonts/ez-toc-icomoon.eot?#iefix-5j7dhv) format('embedded-opentype'),url(fonts/ez-toc-icomoon.ttf?-5j7dhv) format('truetype'),url(fonts/ez-toc-icomoon.woff?-5j7dhv) format('woff'),url(fonts/ez-toc-icomoon.svg?-5j7dhv#ez-toc-icomoon) format('svg');font-weight:400;font-display: swap;font-style:normal}

プラグイン の CSS を上書きして swap を追加しました。

swap 設定前の点数

swap の設定前はデスクトップ版で、91点でした。

swap 設定後の点数

デスクトップ版の swap ありの点数です。

僅かですが PageSpeed の点数が改善しました。
ウェブフォント読み込み中のテキストの表示」の表示が消えました。

ウェブフォント読み込みを削除して速度改善

ウェブフォントをそもそも消してしまうというのもありです。
あまり環境に左右されずに対応できます。

<link href="https://fonts.googleapis.com/css?family=Spinnaker" rel="stylesheet">

例えばこういうフォントの読み込み表示を丸ごと削除します。

ウェブフォント削除前の点数

ウェブフォント削除後の点数

削除後のモバイルの点数は+3点となりました。

モバイルでの点数改善は大きいですね。
デザインに左右されないフェーズでしたら、思い切って削除もありというスタンスです。

「ウェブフォント読み込み中のテキストの表示」対策まとめ

「ウェブフォント読み込み中のテキストの表示」に対する対策として二つの対策をご紹介しました。

CSS の swap 読み込みは、「過大なネットワーク ペイロードの回避」対策 でも有効な方法です。

また、ウェブフォントの使い所にもよりますが、削除するのも高速化の選択肢として有力だと考えています。ゴールやフェーズに合わせて意思決定をしていきたいです。

PageSpeed で「ウェブフォント読み込み中のテキストの表示」が指摘された際には点数改善が期待できますので対応するべきポイントでしょう。

参考

Ensure text remains visible during webfont load

PageSpeed の「静的なアセットと効率的なキャッシュ ポリシーの配信」対策で速度改善

PageSpeed Insights で、「静的なアセットと効率的なキャッシュ ポリシーの配信」をせよと指示されるケースの対策と改善手法です。

キャッシュのTTL が None になっています。
アセットにキャッシュが設定されていないことがわかります。アセットとは画像や、CSS、JavaScript などのファイルと考えてください。

改善対策

WordPress を使っている想定として、キャッシュを設定することが対策となります。

レンタルサーバーで WordPressを利用している場合、通常利用できる手法となります。

Expires の指定を追加

Apache などの Web サーバーで Expires 指定をしてキャッシュすることができます。キャッシュは PageSpeed に影響があり表示速度改善が期待できます。サーバーに合わせた指定をしてください。

レンタルサーバーは .htaccess に指定

Apache を利用しているレンタルサーバーなどは、.htaccess に記述すればキャッシュの Expires の指定を追加できます。

<IfModule mod_rewrite.c>
    ExpiresActive On
    ExpiresDefault "access plus 1 days"
    ExpiresByType image/png "access plus 1 months"
    ExpiresByType image/jpeg "access plus 1 months"
    ExpiresByType image/gif "access plus 1 months"
    ExpiresByType text/css "access plus 30 minutes"
    ExpiresByType text/javascript "access plus 10 hours"
    ExpiresByType application/javascript "access plus 10 hours"
</IfModule>

PageSpeed の指摘では JavaScript や画像が出ていたので、画像や JavaScript、CSS を追加します。

パフォーマンスへの影響を確認

再度 PageSpeed Insights を確認します。

相変わらず「静的なアセットと効率的なキャッシュ ポリシーの配信」という項目は表示されています。
しかし、キャッシュの TTL None の項目が消えています。
また、赤いだった表示が、黄色いアイコンになりました。

Expires 設定前の点数

Expires の設定前はデスクトップ版で、90点でした。

Expires 設定後の点数

デスクトップ版のキャッシュありの点数です。

90点から94点となり+4点の変化となりました。
モバイル版では点数の変動はありませんでした。

大きなポイントではないかもしれませんが、キャッシュ指定は忘れず対応したい設定ですね。

参考

mod_expires – Apache HTTP サーバ バージョン 2.2

WordPressで「オフスクリーン画像の遅延読み込み」対策で速度改善

PageSpeed Insights の表示で、「オフスクリーン画像の遅延読み込み」をせよと指示されるケースの WordPress での対策です。

オフスクリーン画像の遅延読み込み

オフスクリーンとは、画面に表示されない部分ということで、表示されない画像のロードを遅れてロードせよという指示になります。

改善対策

この記事では、WordPress の対策をメインにご紹介します。

WordPress の対策

WordPress では遅延ロードに対応したプラグインを使いましょう。

WordPress の画像遅延読み込みには、lazy load プラグイン を使えと PageSpeed の指示があります。
今回は、Autoptimize – WordPress plugin を使ってみます。

WordPress 以外の対策

WordPress 以外の場合は、JavaScript の Lazy-load プラグインを使うといいでしょう。

Autoptimize の設定

プラグイン Autoptimize をインストール&有効化してください。
設定 > Images と進みます。

Autoptimize 設定

ここから Lazy-load images? にチェックを入れます。

「Lazy-load images?」にチェックを入れて 変更を保存 を押せば設定は完了です。

パフォーマンスの確認

PageSpeed Insights を確認して「オフスクリーン画像の遅延読み込み」という記述が消えていれば OK です。

Autoptimize 設定前の点数

Autoptimize プラグインなしでは、モバイル38点でした😇

オフスクリーンロード無しのモバイルの点数

Autoptimize 設定ありの点数

Autoptimize ありではモバイルで点数が改善です。

AutoptimizeのLazyーLoadありの点数

モバイルで、5点の改善となりました😁
改善の点数はわずかですが、モバイルの点数改善は難易度が高めなので、対応したい項目です。

プラグインを入れるだけなので WordPressは やりやすいですね。

参考

Defer offscreen images

PageSpeed で「レンダリングを妨げるリソースの除外」対策でJS読み込み速度改善

PageSpeed Insights の表示で、「レンダリングを妨げるリソースの除外」をせよと指示されるケースの JavaScript の対策です。

JavaScript がレンダリングを妨げるリソース

JavaScript の jQuery などライブラリファイルがレンダリングを妨げるリソースとして指摘されています。

改善対策

JavaScript の読み込みを遅らせることで、レンダリングの妨げにならないようにします。基本的には遅延ロードなどをすれば点数改善ができます。

link タグに defer 属性を追加

JavaScript の遅延読み込みには、async と defer があるそうなのですが、今回は defer を使います。

元のタグ

以下のように外部 JS を読み込んでいた箇所が PageSpeed の指摘です。

<script src="https://code.jquery.com/jquery-3.2.1.slim.min.js"
             crossorigin="anonymous">

改善したタグ

defer 属性を足します。

<script src="https://code.jquery.com/jquery-3.2.1.slim.min.js"
             crossorigin="anonymous" defer>

script タグの最後に defer を足しています。一番後ろに書きましたが、属性なので script タグ内のどこに足しても大丈夫です。

PageSpeed で指摘された読み込み JS には全部 defer を足しておくといいでしょう。

パフォーマンスの確認

PageSpeed Insights を確認して「レンダリングを妨げるリソースの除外」という記述で該当の JS(jquery-3.2.1.slim.min.js)が消えていれば OK です。

パフォーマンスへの影響

defer 属性で PageSpeed の点数に改善がみられました。

defer 設定前の点数

defer 設定なしでは、モバイル41点でした😇

defer 無しの js 読み込みの点数

defer 設定ありの点数

defer ありでは点数が改善しました。

defer を js 読み込み設定後の点数

モバイルで、17点の改善です😁
defer 設定、やる価値のある対応ですね。

WordPress の wp_head() でライブラリが出力される場合は?

当記事でご紹介した手法を WordPress で使う場合は wp_head() をカスタマイズする必要がある場合があります。wp_head() で出力される JavaScript に defer 属性を付与するには、functions.php で wp_head() の出力を変更します。

以下の記事も合わせてご覧ください。

参考

Eliminate render-blocking resources

PageSpeed で「レンダリングを妨げるリソースの除外」対策でCSS速度改善

PageSpeed Insights の表示で、「レンダリングを妨げるリソースの除外」をせよと指示されるケースの対策です。

レンダリングを妨げるリソース

CSS がレンダリングを妨げているようなので、CSS の読み込みを送らせます。

link タグに preload と style を追加

PageSpeed で指摘された CSS を読み込んでいるタグを修正します。

元のタグ

以下のように外部 CSS を読み込んでいた箇所が PageSpeed の指摘です。

<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css">

改善したタグ

rel=”preload” と as=”style” を足します。

<link rel="stylesheet" rel="preload" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css" as="style">

rel 属性に preload して欲しいという記述と、リソースを style と指定しました。この指定、以前はブラウザごとに実装に差があったようなのですが、最近は概ね対応してきているようです。

パフォーマンスの確認

PageSpeed Insights を確認して「レンダリングを妨げるリソースの除外」という記述が消えていれば OK です。

パフォーマンスへの影響

CSS のプリロードの影響はモバイルでは少し改善し、
デスクトップは大きなポイント改善となりました。

preload 設定前の点数

preload 設定なしでは、モバイル65点でした😇

モバイル CSS の preload なし

デスクトップは79点

デスクトップ CSS の preload なし

preload 設定ありの点数

preload ありでは点数が改善しました。
モバイルで+3点、デスクトップで+15点です。

モバイル CSS の preload あり
デスクトップ CSS の preload あり

モバイルで+3点、デスクトップで+15点改善されました。
レンダリングを妨げるリソース部分が改善されたようでよかったです😁

しっかり改善したようなので、preload は対応する価値がありそうですね。

WordPress の wp_head() の場合は?

当記事でご紹介した手法を WordPress で使う場合は wp_head() をカスタマイズする必要がある場合があります。wp_head() で出力される style.css などに preload 属性を付与するには、functions.php で wp_head() の出力を変更します。

以下の記事も合わせてご覧ください。

参考

Eliminate render-blocking resources

rel=”preload” によるコンテンツの先読み – HTML: HyperText Markup Language | MDN

PageSpeed で「テキスト圧縮の有効化」対策で速度改善

PageSpeed Insights の表示で、「テキスト圧縮の有効化」をせよと指示されるケースの対策と改善手法です。

テキストリソースを gzip や deflate で圧縮せよという指摘

上図ではテキストリソースの js や css の圧縮して通信料を抑えるように指摘されています。

改善対策

ウェブサーバーから返すリソースに圧縮指定をするのがよくある手法です。

gzip と deflate の指定を追加

Apache などの Web サーバーで gzip や deflate の圧縮指定をすればこの表示が消えて、速度が改善が期待できます。サーバーに合わせた指定をしてください。

レンタルサーバーは .htaccess に指定

Web サーバーの設定を直接変更できないレンタルサーバーなどは、.htaccess に記述すれば deflate の圧縮指定を追加できる場合があります。レンタルサーバーの設定を確認してください。

.htaccess の IfModule mod_rewrite.c タグ内に AddOutputFilterByType DEFLATE を追加します。

<IfModule mod_rewrite.c>
    AddOutputFilterByType DEFLATE text/html
</IfModule>

これは HTML だけしか指定していないので、他にも追加する場合は後ろに複数追加できます。

<IfModule mod_rewrite.c>
    AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/js application/x-javascript application/javascript
</IfModule>

js と css が PageSpeed の指摘にありましたので追加しました。

パフォーマンスへの影響を確認

再度 PageSpeed Insights を確認します。

deflate 設定前の点数

deflate の指定前は37点でした。

deflate 設定後の点数

こちらが deflate 設定後の点数です。

37点から66点になっています😁
29点の改善となりました。

速度改善では、gzip と deflate の圧縮をまず検討するべきと言えますね。

参考

mod_deflate – Apache HTTP サーバ バージョン 2.2

PageSpeed でフォントの「過大なネットワーク ペイロードの回避」対策で速度改善

PageSpeed Insights の表示で、「過大なネットワーク ペイロードの回避」をせよと指示されるケースの対策です。
中でも、ウェブフォントが上位に指摘されているのでフェブフォントの対応です。

ネットワークペイロードの回避

PageSpeed の指摘としてはフォントのロードに負担がかかるので遅延読み込みをせよとあります。

改善対策

負担をかけているのはウェブフォントなので、CSS を改善して読み込みを遅延読み込みさせます。

CSS で font-display 指定を swap にする

CSS の @font-face を利用してフォントを遅延読み込みさせます。
CSS を編集して @font-face に swap を設定します。

    @font-face {
        font-family: 'Noto Sans Japanese';
        font-style: normal;
        font-weight: 100;
        src: url(//fonts.gstatic.com/ea/notosansjapanese/v6/NotoSansJP-Thin.woff2) format('woff2'), url(//fonts.gstatic.com/ea/notosansjapanese/v6/NotoSansJP-Thin.woff) format('woff'), url(//fonts.gstatic.com/ea/notosansjapanese/v6/NotoSansJP-Thin.otf) format('opentype');
        font-display: swap;
    }
    
    @font-face {
        font-family: 'Noto Sans Japanese';
        font-style: normal;
        font-weight: 200;
        src: url(//fonts.gstatic.com/ea/notosansjapanese/v6/NotoSansJP-Light.woff2) format('woff2'), url(//fonts.gstatic.com/ea/notosansjapanese/v6/NotoSansJP-Light.woff) format('woff'), url(//fonts.gstatic.com/ea/notosansjapanese/v6/NotoSansJP-Light.otf) format('opentype');
        font-display: swap;
    }

今回の PageSpeed の指摘では Google の Noto Sans Japanese が原因だったので、そこに font-display を追加しています。

font-display で swap を指定しておけば、font のロード待ちを回避してくれます。

パフォーマンスの確認

PageSpeed Insights を確認して「過大なネットワーク ペイロードの回避」という記述が消えていれば OK です。

パフォーマンスへの影響

実はこのウェブフォントのロードは大きな影響があります。

swap設定前の点数

swap 設定なしでは、0点でした😇

Swap なしのロード

swap ありの点数

swap ありでは点数が大幅に改善しました。

なんと驚きの36点もの改善となりました😁
「過大なネットワーク ペイロードの回避」は速度改善では外せない項目ですね。