読者です 読者をやめる 読者になる 読者になる

Webサイトパフォーマンスについて

Webサイトのパフォーマンス計測について記事を書いています。パフォーマンス管理は、品質管理です。ですから、これをやっておけば大丈夫みたいなBest Practiceで済む世界ではないです。定常計測や、計測データの分析の正しいやり方の認知が普及することを目的としています。内容は、ハードコアかも。

Web担当者Forumの「グーグルが順位付けに使ってるのはページ表示速度ではなくクロール時間らしい」という記事は誤りです

Web担当者Forumの「グーグルが順位付けに使ってるのはページ表示速度ではなくクロール時間らしい」という記事を拝見して、内容に問題があると思いました。

A Good Serviceとしてのコメント

人様の記事にあれこれ書くのはどうかなと思いました。

To kill an error is as good a service as, and sometimes even better than, the establishing of a new truth or fact.

(間違いを排除するというのは貢献であり、時には、新しい真実や事実を発見するより良い事である。)

― Charles Darwin

でも、チャールズ・ダーウィンの上記のような名言がありまして、おかしいなと思ったら、そういう記事に対しては、自分なりのコメントを書くようにしようと思いました。

それで、最初は、元記事のコメント欄に入力していたのですが、文量が多くなったので、こちらに書きます。

速度の影響

原典の"Empirical Study of Web Site Speed on Search Engine Rankings"の記事の中で、以下のように書いています。

Google wrote that web site speed:

  • Was not as important a factor in search ranking as page relevance(検索ランキングにおいて、ページの関連性ほど重要な要素ではない)
  • Affected less than 1% of search queries(影響は、検索クエリーの1%未満)
  • The site speed signal only applies for visitors to Google.com searching in English.(サイト速度は、Google.comで、英語で検索した訪問者についてのみ適用される)

つまり、この時点で、日本語で検索する人を対象にしたWebサイトについては意味が無さそうです。

計測している測定基準

「サイトの速度について」で、Googleが以下のように明確に書いています。

ブラウザがドキュメントを解析し、ユーザーの操作が可能になるまでの時間。このデータを参照するのに追加の設定は必要ありません。このデータは、[ページ速度] レポートの [DOM 速度] サブタブで参照できます。

つまり、デフォルトは、DOM速度、W3C Navigation TimingのdomCompleteを見ているであろうことが分かります。

この原典の記事で紹介されている指標値は、Crawl timeとPage Load timeです。

Page Load

Page Loadは、Navigation Timingによると、以下の式で算出されます。

function onLoad() {
 var now = new Date().getTime();
 var page_load_time = now - performance.timing.navigationStart;
 console.log("User-perceived page loading time: " + page_load_time);
}

つまり、onLoadが発火した時間とnavigationStartの差分です。
尚、onLoadは、W3C Navigation TimingのloadEventEndに相当します。

Crawl time

では、Crawl timeとは、どのような定義でしょうか?

GoogleのWebmaster Central Blogの2014年10月27日の記事Updating our technical Webmaster Guidelinesに以下のような記載があります。

Historically, Google indexing systems resembled old text-only browsers, such as Lynx, and that’s what our Webmaster Guidelines said. Now, with indexing based on page rendering, it's no longer accurate to see our indexing systems as a text-only browser.
(歴史的に見て、Googleのインデックスシステムは、Lynxのような古いテキストのみのブラウザに似ていますし、そのように私達のウェブマスターガイドラインでも述べてきました。今や、ページレンダリングに基づくインデックスを行うようになり、最早、私達のインデックスシステムがテキストのみのブラウザのようなシステムであるという理解は正しくありません。)

つまり、従来は、htmlファイル(Base Page)のみを読み込んでクローリングしていたものが、この時期からCSSJavaScriptを読み込み、レンダリング処理をしてクローリングするようになっているわけです。

レンダリング処理の終了は、W3C Navigation TimingのdomCompleteに相当します。

さて、この記事の中で、

要は、クロール時間はGooglebotがページを取得する時間、ページ表示時間はユーザーがブラウザでページを表示するのにかかる時間、ということです。

という記載があるのですが、元の調査が開始された時点においてはそうだったのかもしれないです。
この論文自体は、Journal of Web Engineeringの2014年5月号に掲載されています。ですから、その当時においては、上記は当てはまるものの、現状はそうではないという事です。

この記事の中で、

グーグルがページ表示速度が順位の要因として取り入れたのは、本来「ページ表示にかかる時間が短いほうが、ユーザー体験が良くなる」からのはずです。
なので、ページ表示時間が関係していると思い込んでいたのですが、実はまだそうじゃなかったんですね。
その理由は何でしょうか?

と書いていらっしゃいますが、この論文の調査が行われた時期のクローリングシステムと、今回の原稿を書かれた現時点でのGoogleのクローリングシステムが違うから、という単純な理由です。

Google Analyticsの「サイトの速度」の問題

ちなみに、この記事で、Google Analyticsの「サイト速度」について書かれていますが、殆ど使い物になりません。

何故かというと、欠損値だらけだからです。

期間を1日だけにして、時間別を選び、メニューの「エキスポート」を選んで、詳細データをダウンロードしてみましょう。

f:id:takehora:20150305000614p:plain

Excelで開いてみると、このような感じになります。

f:id:takehora:20150305000636p:plain

これは、とあるサイトのデータです。
(私の会社のWebサイトだと、表示速度が速すぎるからだと言われそうなので、遅いところを選びました。)
24時間の内、データが取得できているのは2つだけです。それで、平均0.25秒と表示されているのです。
これが実態です。

結論

残念ながら、このWeb担当者Forumの記事の内容は意味がありません。
原典のWebSiteOptimization.comの記事にも、そのようにコメントを書いておきます。