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 で圧縮せよという指摘

上図ではテキストリソースの JavaScript や CSS を圧縮して通信量を抑えるように指摘されています。
この対策について見ていきましょう。

改善対策

テキスト圧縮は、ウェブサーバーが返すリソースへ圧縮の指定がよくある手法です。

gzip と deflate の指定を追加

Apache などの Web サーバーで gzip や deflate の圧縮指定をします。
圧縮指定をすれば PageSpeed の表示が消えて、速度改善が期待できます。

具体的な設定はサーバーに合わせた指定をしてください。

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

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

ご利用のレンタルサーバーの設定を確認してください。

以下は Apache を利用しているケースでの .htaccess の圧縮指定の紹介です。
.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 のロード待ちを回避してくれます。

swap 指定のフォント表示

パフォーマンスの確認

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

パフォーマンスへの影響

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

swap設定前の点数

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

Swap なしのロード

swap ありの点数

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

なんと驚きの36点もの改善となりました😁

まとめ

ウェブフォント読み込みを CSS の指定から速度改善しました。
ウェブフォントの普及は広がっていきますので、「過大なネットワーク ペイロードの回避」は速度改善では外せない項目となりそうです。

参考

If You Can Read This Fonts Work

Google サーチコンソールでサイトマップを再送信する

この記事では、サイトマップに変更があった場合、サイトマップを再送信する方法をご紹介します。

サイトマップに変更があった場合は、すぐにサーチコンソールに登録して検索エンジンに更新が通知されるようにしましょう。

サイトマップを再送信する理由

URL の変更などによりサイトマップを更新した場合、サイトマップを再送信した方が良いです。

再送信しない場合は、サイト内の URL 変更などサイトマップの変更反映に時間がかかる場合があります。

サーチコンソールでサイトマップを再送信する方法

サーチコンソールから、サイトマップ > 新しいサイトマップの追加 で新しい URL 入力で完了です。

すでにサイトマップが登録されている場合には再送信されます。

Googleサーチコンソールから新しいサイトマップの追加
Googleサーチコンソールから新しいサイトマップの追加

上図のようにサイトマップでは sitemap.xml というパスが一般的です。
実際に入力される場合は、サイトマップのパスに合わせてご入力ください。

サイトマップ送信の成功

送信されたサイトマップのステータスが、「成功しました」になっているか確認してください。

成功していれば送信はOKです。

Google サーチコンソール 送信された URL が見つかりませんでした(404) 対策

Google サーチコンソールで404エラーが発生した際の対策です。
404はエラーですのでエラー表示を消すことが正しい対応になります。

404エラーの確認

サーチコンソールの インデックス > カバレッジからエラーを確認します。

Google サーチコンソール404エラー
Google サーチコンソール404エラー

上図ではエラーが2件発生しています。
サイトマップの URL がアクセスできない状況のようです。

404エラーのサイトマップ修正する

404の原因は色々考えられますが、URL の変更ならば新しい URL への更新、URL の削除ならサイトマップからの削除を行います。

サイトマップを編集し、サイトマップに掲載されている URL がアクセスできることをしっかり確認してください。

サイトマップを送信

Google サーチコンソールにサイトマップを送信します。

すでに送信済みのサイトマップでも、サイトマップの更新がサーチコンソール上で反映されない場合は、再度サーチコンソールで送信すると良いでしょう。

問題修正を Google サーチコンソールで確認

修正が Google サーチコンソールから認識されると、Google サーチコンソールからメールでメッセージが届きます。

カバレッジの問題が修正されました
カバレッジの問題が修正されました

「カバレッジ」の問題が修正されましたとあります。

つまり、「送信された URL のクロールに問題があります」の問題が修正されたことを Google サーチいコンソールが認識したということです。

404エラーのステータスが合格に
404エラーのステータスが合格に

Google サーチコンソールのステータスが合格になっています。
こちらでOKです。

まとめ

Google サーチコンソールで表示される「送信された URL が見つかりませんでした(404) 」を解消する対策について記載しました。

404が出ていると、検索エンジンからの流入にネガティブに働きます。エラーを見直して、アクセス流入改善につなげてください。

【必須】ウェブ分析最初の一歩 GoogleAnalytcis の設定

ホームページやブログのウェブ分析しっかりできていますか。
あるいは、ビジネスの結果に繋げられていますか。

「GoogleAnalytics は見ているけど、どうも見方がわからなくて困っている。」

そのような声にお応えするためにウェブ分析最初の一歩、必ず整備して欲しい設定をご紹介します。

ウェブ分析の最低条件は3つ

正直な話、サービスのウェブ分析をビジネスに繋げられているかどうかは、ウェブ分析の環境を教えていただくことで、だいたいわかります。

まずは以下の3つを確認してください。

  1. GoogleAnalyticsが導入されている
  2. SearchConsoleと連携できている
  3. GoogleAnalytcisの目標が設定されている

いかがでしょうか。会社にマーケターがいるから、エンジニアがいるからと安心せず必ず確認してください。私が知る現場では、これら3点が設定されていない環境が多かったです。

GoogleAnalytics の導入について

GoogleAnalytics はウェブ分析ではディファクトスタンダードなツールです。
正直な話、これが導入されていない現場はウェブ分析以前の段階と言えるでしょう。どんなに分析をしようとしても、データ無しには多くを語ることはできません。

とにかくまず GoogleAnalytcis を導入しましょう。

GoogleAnalytics の導入からウェブ分析の最初の一歩が始まります。

SearchConsole と連携しているか

次に、GoogleAnalytics と SearchConsole の連携を確認しましょう。
意外にこの重要な設定がなされていないケースが多いです。

GoogleSearchConsole のデータは SEO の集客状況を見るために必須のツールです。もしこれが、GoogleAnalytics と連携されていないということは、今までウェブ集客の重要な1つである SEO の分析を一切行ってきていなかったという状況と言えるでしょう。

SearchConsole を GoogleAnalytics と連携していない場合、そもそも SearchConsole を使用していない、あるいは、SearchConsole は使っているが GoogleAnalytics と連携していないというパターンです。

後者の場合は連携していないだけでデータは取れていますが、前者の場合検索のデータがそもそも取得できていません。早急に SearchConsole の導入から進めてください。

GoogleAnalytcis に目標設定の有無

GoogleAnalytics で目標機能は、GoogleAnalytics の最も大事な機能と言っても大袈裟ではありません。

GoogleAnalytics は目標を設定すれば、コンバージョンという項目で目標に達成するまでのデータを分析できるようになります。

逆に GoogleAnalytcis の目標設定をしていないということは、それだけでサイトには目標がない状態ということがわかります。さらに言えば、そのサイトを運営する組織やチームの目標が設定されていなかったり曖昧だったりする場合が多いのです。

目標設定はとにかくなんでもいいので設定してください。お問い合わせページの表示や、バナーのクリック数など簡単なところからでも構いません。

まずは、「数字をとる」ところから分析が始まります。

ウェブ分析最初の一歩を踏み出そう

ウェブ分析最初の一歩という3つの重要なポイントをご紹介しました。

いかがでしょうか。みなさまの職場のウェブ分析環境は十分に整っていましたか。これら GoogleAnalytics の整備は、サイトに数値分析という現実的な手法をもたらします。

数値分析をしていないサイトはコンパスのない旅のようなものです。まずは小さなことからでも設定を行い、方向を定めていきましょう。

SSL化で忘れがちなTODO

近年ではサイトを SSL で HTTPS 化することが必須の時代となりました。
そんな HTTPS 化の際には忘れがちで必須の TODO があります。

  • SSL 対応したら SearchConsole に新規登録が必要
  • 新規登録なのでサイトマップ登録が必要
  • GoogleAnalytics のプロパティを更新

URL が代わりますので、サイトマップや GoogleAnalytics の連携が必要になります。

HTTPS 化したサイトを SearchConsole で新規に追加する

HTTPS 化したサイトは GoogleSearchConsole への新規登録が必要です。過去のHTTP のプロパティをそのまま移行はできないようです。

サイトマップを追加

SearchConsole への追加ののちに、サイトマップを追加します。
SearchConsole の「サイトマップ」ページからサイトマップを登録します。

忘れがちな所なので注意してください。

GoogleAnalytics のプロパティからSearchConsole を設定

SearchConsole を変更したので、次は GoogleAnalytics の設定を変更します。
管理 > プロパティから SearchConsole の指定を変更してください。