当社はIT技術のオンライン教育を得意としたセミナー専門会社です。 | 一戸英男

ITエンジニアの技術力UPをお約束します。

Speed SEOの検証でどの速度を最も重要視しているのか?

Speed SEOの検証でどの速度を最も重要視しているのか?


Speed SEOの中で一番重要視するべきと思う速度の箇所について解説します。通常どの種類のWEBブラウザーも名称は多少違いはあるものの検証ツールなるものが存在するのでそれを用いて説明したいと思います。因みに知らない人もいると思いますので「Speed SEO」とはなんぞや?から始めます。

Speed SEOはWEBの表示速度を早くしてユーザビリティを高める事が目的です。例えば今ならコンテンツの作り方はレスポンシブが標準だと思います。PCもスマホも同じコンテンツなので評価されやすい作り方は間違いなくレスポンシブ。しかしGoogleの基準では1秒以内に表示するのがBESTと言ってます。PCとスマホの画像が同じだと遅くなりますよねViewPort使ってCSSで切り替えないと。そのようにスマホ向けに画像を最適化したり、見せ方を小さい画面でわかりやすくする。画像がダウンロードできてなくてもレイアウトがしっかりするように作るとかそれがSpeed SEOでやることなのです

私も昔は1秒以内で表示は無理でしょう!と思っていましたが今では、十分可能と思っています。そう思う根拠はAnalyticsがどの値の速度を見ているのか!?というところが概ね理解できたからです。

WEBブラウザ上で検証ツールの起動

下記はchromeブラウザで検証ツールを立ち上げ、当社のあるページを読み込んだ画面です。

検証ツールのフッタに転送容量や転送時間のステータスがありますので、その意味を下記に解説します。

  • ・49/52 requests 全部で52個のコンテンツリクエスト。その中で49個が内部コンテンツ、残りは3個は外部リクエストコンテンツ
  • ・27.1KB/27.1KB transfered 全体の転送量(圧縮されたり、キャッシュを使うので実際のデータ量と異なる)
  • ・842KB / 868KB resources 実際の転送されたデータ量。ディスク上の容量という意味です。
  • ・Finish: 716ms ページコンテンツがブラウザに表示されるまでの時間。最終的な全体ロード時間です。(外部リンク読み込み済み)
  • ・DomContentLoded: 492ms このページのHTMLファイルの読み込まれた時間。(DOMツリー構築時間)
  • ・Load: 682ms ページコンテンツが全てサーバからブラウザに到着した時間。(外部リンクは読み込まれてない)

上記の写真を見ていただくとわかる通り、ピンク色で囲んだ箇所のLoadがグーグルが最も優先的に評価している時間であると推測します。この時間とGoogle Analyticsの速度の評価状況を見るとほぼ一致しています。ホームページのコンテンツには外部URLを含んでいるものもあるため、その影響によって表示が遅くなってしまうものもありますが、Loadの時間はその意味では1つの判断基準にはなると思います。次に優先的なものはレンダリングの部分だと思います。このあたりもGoogleはAIで評価できるようになっているため、Lazy Loadを使ったりレイアウトが初期の穴あきコンテンツ状態でもコンテンツロードで綺麗に形成されていれば評価は高くなると思います

Speed SEOで効果が最も期待できるのは?

メインワード検索順位が1位〜10位に既に位置しているレベルでは、Speed SEOを実施しても劇的な効果は期待できないと思います。むしろ30位〜50位に位置しているなら効果が最も出やすいかもしれません。既に上位に位置しているサイトはアナリティクスの速度評価の箇所でページ単位で遅延が発生しているものを見つけて速度遅延解消に努めたほうが微力ながら効果があると思います。基準としてグーグルはベストは1秒以内と言いますが平均2秒以内に収まっていれば問題ないと思います。またGoogle Insightでのスコアは平均70〜90に収まっていれば良いと思います。執拗に最適化するのは時間の無駄ですし、コストと順位、サイトの評価の全体バランスを見極めて適当なところで留めておくのが良いと思います。

タグ: , , ,

SEO対策を考慮したホームページ SSL化の導入作業の流れ(手順)


2月の後半にグーグルから本格的モバイルファーストインデックスとオールSSL化に関するアナウンスが出ました。3年ほど前から言われてきたことなのですがいよいよタイムリミットが迫っています。7月24日リリース予定のクロームブラウザversion 68ではhttps対応になっていないと安全ではないサイトということで警告が出るそうです。

6月末までには対応しておくべきでしょう。ついでにそのタイミングでモバイルファーストインデックスを行えば余計な二重投資は防げると思います。逆に一緒にやらないとアノテーション設定のURLがhttpsに変わるので変更を行う手間を考えたらこのタイミングで行うことがもっとも効率が良いという事がわかると思います。


※日本時間で平成30年3月28日にモバイルファーストインデックスが開始されました。逐次MFI導入している企業から置き換えてゆくそうです。MFIになっていない企業は最終的には自動でグーグルの中でMFIに置換されるようです。今年1年かけて置換されるため、最後の方でMFI対応していない会社のHPは置換されるのかもしれません。

アナウンス関連の記事

GoogleオールSSL化の理由はここにあり。
モバイルファーストインデックス
オールSSL化対応

今回はこれらの対応の中でもSSL化に関する対応の流れを説明しておきたいと思います

サイトをSSL化するには、証明書を購入してサーバに導入しなければならないのですが、大変複雑なプロセスが生じます。

また、WEBサーバに証明書を登録しただけではほとんどのサイトはSSL化対応が不十分なケースが多いです。下記のような流れが必要になります。

証明書のインストールの流れ

下記は専用サーバ系で証明書を購入から申請、導入までの手順です。共有サーバの場合はプロバイダーの管理画面で共有SSL、オリジナルSSL設置案内がサイト内にあるはずですからそれをお読みください。

WEBコンテンツ側の修正

専用サーバ、共有サーバで共通で使えるノウハウです。

分析ツールの設定変更

専用サーバ、共有サーバで共通で使えるノウハウです。

  • Google Search Consoleでサイトマップ(httpsの内容に置換後)の送信を行い最新のhttpsURLでインデックスをさせる。
  • Google Search Consoleのhttpsプロパティを新規作成
  • Google Analysticsの管理画面から既存プロパティhttps切り替え、ビューのhttps切り替え
  • Google Analysticsの目標設定にhttpsが影響がないか確認。
  • 分析タグコードを管理する各種ツールにてhttpsに設定変更、再認証を行う

検索エンジンのhttpsアドレスのインデックス反映状況

専用サーバ、共有サーバで共通で使えるノウハウです。

  • 検索エンジンの窓で「site:https://あなたのドメイン」で検索し出力結果を眺めhttpとhttpsの混在割合を確認し進み具合を見る。siteコマンドでhttpsで検索しても結果的に両方(http&https)出力されます。
  • もし、上記の検索結果から表示して欲しくない、あるいはhttpsに切り替わってくれない緊急性の高いものはGoogle Search Consoleの「URLの削除」を実行し新しいインデックス取り込みを促す。

タグ: , , , , ,