タグ: セッションレポート

ページスピードはどこまで早くなれば良いのか？(Bastian Grimm氏)

昨今、Googleはページスピードにとらわれている。そして、正式にランキングファクターとして用いており、とにかくページスピードを速くするようにと促してくる。

しかし、ページスピードはUXの要素であると私は考える。

実際、ユーザーはモバイルのページスピードの遅さを、ホラームービーを見ること以上にストレスを感じている。

Ericsson ConsumerLab. Neurons Inc　調べ(2015年)

昨今のページスピード問題は、計測が機械的に行われているという事である。

ユーザー体験に基づくページスピードの考え方

ユーザー体験とパフォーマンス基準を変換するとこのようになる。

ペイントのタイミングの計測と最適化

#2 FP(ファースト・ペイント) － ブラウザが何かしらをレンダリングし始めるタイミング。
#3 FCP(ファースト・コンテンツフル・ペイント) － ブラウザがDOMからテキストや画像最初の要素をレンダリングし始めるタイミング。　
#5 FMP(ファースト・ミーニングフル・ペイント) － ヒーローエレメントがロードされている状態
#6 TTI(タイム・トゥ・インタラクティブ) － ユーザーが使うことが出来る状態

クリティカル・レンダリング・パス

ページを最初にロードした際に見えないビロウ・ザ・フォールドよりも、イニシャルビューの方がユーザーにとっては重要である。

CSSOM：CSSオブジェクトモデル

CSSOMとは以下のようなものである。

• CSSOMはページ上で発見されたCSS styleのマップである。
• DOMと似ているが、HTMLではなくCSSを対象としている。
• CSSOMはDOMと組わせて、ブラウザがウェブページを表示するために使われる。

ウェブブラウザはレンダリングのためにCSSOMを使用する

ページの読み込みは以下のような手順で行われる。

1. ウェブブラウザがHTMLを調べ、DOMを構築する
2. ウェブブラウザがCSSを調べ、CSSOMを構築する
3. DOMとCSSOMを組み合わせ、レンダリングツリーを構築する
4. ウェブブラウザがページを表示する

ちなみにGoogleはCSSのためにGETリクエストを行っていない。インラインで記載を行っている。

実際の導入はこのような手順で行うとよい。

1. 重要なCSSをインライン化する
2. 重要でないCSSをrel=”preload”で非同期にロードする
3. onloadでロードが完了したら一度CSSを適用する
4. 非JSのリクエストをフォールバックする
5. 古いブラウザのためにloadCSSを実装する

どれくらい効果があるのか？

レンダリングまでの時間と、インタラクティブになるまでの時間の短縮に成功した。

• レンダリングまでの時間 0.6秒 ⇒ 0.410
• インタラクティブになるまでの時間 0.931秒 ⇒ 0.563

サイト構造にクロールデータを活用する(Brian Weiss氏)

なぜクロールをするのか？

• サイトの構造とSEO的な問題を特定するため
• モバイルとデスクトップの構成を均一にするため
• 前回とのクロールの差分を正確に計測するため
• リソースのリクエストをするためのデータを集めるため
• 何か足りないものはないかを確かめるため
• サイトの規模が大きく、全てのページを訪れるのは難しいため

有名なクローリングツール

• DEEP CRAWL
• Screamingfrong
• BOTIFY
• STONE TEMPLE
• OnCrawl

クローラが集めるべき情報

基礎的にはURLや、Canonicalなどの情報を集められる必要がある。

特に、情報をフォルダやページタイプ毎に仕分けをする能力は必須である。

クロールを行う前の心構え

サイト内で何が重要なURLなのかを理解しておく
結果の予測をしてみる ⇒ 予測と結果の差分が分かる

見るべき重要なポイント

• 重要なページに対して効率的にクロールされるような導線設計になっているか
• Googleに薄いコンテンツとして見られていないか
• クロールバジェットを有効に使えているか
• タイトルや見出し、タグの設置に問題はないか

各ページタイプごとの「ページ総数」と「インデックス可能なページの総数」を比較
⇒もしインデックス可能なページが、ページ総数の半分を下回っていた場合、処置をやりすぎている可能性がある。

処置法毎に生じるコスト

処置法の選び方

• ページランクをあまり渡さないページが大量にあるか？ ⇒ Robots.txt
• Canonicalのターゲットと適用法があるか？ ⇒ Canonical
• 上記の問いへの回答が全て「否」であり、インデックスされたくないページがあるか？⇒Noindex

デスクトップとモバイルのクロール分析

• リンク均一性が保たれているか
• コンテンツ均一性が保たれているか・・・Title、H1、メタディスクリプション、タグなど
• ユーザーエージェントの一貫性があるか

まとめ

• 見つけられないものは治すことが出来ない。クロールをしなければ、視覚的に把握することが難しい課題がある。
• どの処置法でもコストが生じる
• リンク構成はGoogleに対して、あなたがどのページを重要と考えているかを伝えることになる。

Web戦略でお困りではないですか？

自然流入を増やしたい…
もっと問い合わせ、売り上げを増やしたい…
15年以上SEOサービスを提供してきたアイオイクスが、貴社の課題を解決するコンサルティングサービスを提供いたします。

スピーカー
Cindy Krum氏　MobileMoxie CEO
Leslie To氏　3Q Digital SEOディレクター
※Leslie氏のセッションはこちらの記事でご紹介しています。

モデレーター
Barry Schwartz氏　SearchEngineLand、RustyBrick

MFI時代のエンティティとインテントの理解(Cindy氏)

MFIとは何か

モバイルファーストインデックス(Mobile-First Indexing)とは何なのかをもう一度考えてみる。

• モバイル(本来のmobileという単語の意味は「可動性の、流動的な」など移動性があること) ⇒ ポータブル、デバイスを問わない、目を使う必要すらない
• ファースト ⇒ 「優先する」という意味「～のみ」ではない
• インデキシング ⇒ システム的に順番付けられた情報

つまり、「モバイルファーストインデックス」は「デバイスの垣根を超えたエンティティの理解」を意味する。
この文脈において、URLはもはや必要ではない。

Googleのインデックスにおいては、URLリンクの関係性が重要。
しかし、URLベースのSEOは終わりを告げるだろう。

PWA

まずは、PWAがその例である。ServiceWorker、AppShellで実現している。

Google Action

Google検索の検索結果画面でも出てくるが、Google アシスタント上で呼び出すこともできる。
アシスタントから呼び出せば、画面を見る必要はなく声だけで完結させられる。

例えば、OpenTableはこんなユーザー体験を提供している。

ディナーの予約がしたい
⇒ Googleアシスタントで呼び出す
⇒ 人数は？何日の夜？何時？どこで？などの質問に答える
⇒ データベースを参照
⇒ 予約完了

重複して予約しそうになっても、すでに予約済みだとして警告を出してくれる。

Googleアシスタントストア

Googleアシスタントストアが公開。声だけでアクティベートができる。

Googleインスタントアプリ

データベースを簡易的にアプリのように見せるということが可能になる。
大きな小売事業者などでは、部門や建物全体で働いている人が全員ウェブサイトの管理に携わっているということがあり得るが、本来はそうあるべきではない。
彼らは本来はデータベースの管理に集中できるべきであり、Googleはそれを直接インデックスできるようになるべき。
これはURLに基づかないものであり、これこそがモバイルファーストインデックスである。

エンティティ理解

エンティティを理解するということは、AIを作り出すことに近しい。

検索をした時の本当のインテントを複数の選択肢の中から回答する ⇒ AIをトレーニングしている

インターネットにおいては無限のものが存在しうる。インターネットの前は百科事典が役割を担っていた。

Googleがやろうとしていることは、様々な言語に対応する必要があるため、とても大変な取り組みとなる。

しかし、バケツはどこでもバケツだし、他のものとの関係も場所柄によって大きく変わったりすることはない。

もはやURLに基づいてやる必要はないし、実際URLはインターネットの発展への妨げとなるであろう。

エンティティを理解した後はどうするのか？
⇒物事を4つに分類する

それぞれ4つの種類(情報、マップ、ショップ、メディア)のうち、一つ以上のバケツに分類される。
例)CDはメディアとショッピングの両方に当てはまる。

GoogleマイクロモーメントにおいてはInfo(情報)が一番重要

情報

Googleアシスタントなどでニュースカードを表示すると、エンティティのレーベルが付与されていることがある。
国ごとの検索結果を出すのにCCTLDを使用していない＝国ごとにアルゴリズムを変えていない。
Googleはモバイル端末、アカウントを基にパーソナライゼーションをしようとしている。

エンティティの理解は画像検索であれば簡単だが、言語が絡むと難しくなる。

munich、München、ミュンヘン、など表記や発音が異なっても同じ地点を表している

別の例でいうと、例えば「tulip movie」と調べれば、どの言語においても同じチューリップフィーバーという映画の画像が返される。
⇒Googleはキーワードではなく、エンティティを理解しようとしている

また、「青い椅子」の画像はページ内に「青い」や「椅子」という表記が無くても認識される。

なぜこれらが重要なのか？
モバイルファーストインデックスはAIドリブンであり、たくさんのデータやフィードバックが必要なため、全ての言語ごとにAIは存在する。
これらのAIをひとつの言語、エンティティに集約すると、一つの機械学習アルゴリズムに集約される。

エンティティで関連づけられているからこそ、画像検索クエリに合わせて「ビデオ、GIFs、ニュース、レシピ、商品」などのタグが付与されている。
また、「関連する検索」というのもエンティティを理解している証拠である。

Schema JSON-LDは英語ベースのマークアップであるが、これがSEOのエンティティ理解にとってのロゼッタストーンとなるであろう。

Googleアシスタントでチーズと検索すると、関連するエンティティや、AIトレーニングが出てきたり、検索ワードを一部入力すると、続きのワードを具体化しようとしてくる(大きなクエリのビッグデータ)アプリのディープリンクや、プレイリストの曲や閲覧履歴などのパーソナル情報などの情報も候補として出てくる。

Googleはビッグデータとパーソナル情報を網羅しようとしている。

きっと未来のアルゴリズムは、パーソナルインテントがどれだけ含まれているのかを理解し、それに応じてビッグデータとパーソナル情報の比重を決めるはずだ。

マップ

また、Googleはマップ上でもフィードバックを得ようとしている

Googleマップでは、その国の言葉に翻訳してから場所検索をする必要はない。
ドイツで「Groceries Store(食料品店)」と検索すれば、食料品店を検索してくれる。
どこの国だろうと大体同じものを売っているので、食料品店はどこに行っても食料品店である。これもエンティティを理解しているおかげである。

AIをトレーニングするとともに、個人の好みなどパーソナル情報も同時に得ようとしている

(質問例)
クレジットカードは使えるか？
混雑していたか？
車いすでも入れる？
景色は良いか？
ユニセックスのトイレはあるか？
ダンスしに行くところか？

これらの質問に答えることで、GoogleのAIのためにカテゴライズしているのである。

買い物

Schemaマークアップが重要である。
例えばWheelチーズを購入したいと思ったときに「固め」「パルメジャン」「$80以上」等の情報でソートできる。
また価格、販売主、色、サイズなど、Schemaの情報に応じて商品のフィルタリングができる。

配送の事を考えて、近い販売事業者を選定して表示している。ロイヤリティカード(日本でいうポイントカード)の登録をしていればそれに応じて選んでくれる。

メディア

動画や音楽などのメディアをGoogleHomeやクロームキャストに転送することが出来る。

CESでビルトインモニターについてアナウンスがあった。これにより生活の様々な場面でGoogleアシスタントが使用できるようになる。

Google Play、Google Play Movies & TV、YouTubeでは同じ映画を見ることが出来る。
YouTube Music RadioステーションはAIを使って、Pandoraに対抗している。しかし、自分の好みの曲を勝手にプレイリストに追加してしまう。
例：Eminemのプレイリストにカントリーの曲が追加されている。

好みのジャンル選択：トピック ⇒ スポーツ ⇒ 野球 ⇒ チーム
Googleアカウントを持っていれば、パーソナルデータがクラウドに集約される。

今後画像を選択する形式の質問など、よりAIのトレーニングクエスチョンを増やすであろう。
実際、YouTubeは従来では広告を表示していたところを、トレーニングクエスチョンに変えている。
例)下記の業界で働いていますか？下記の内で聞いたことがあるものはありますか？

まとめ

• 「モバイルファーストインデックス」は「モバイルファースト」や「モバイルフレンドリーデザイン」とは異なる。
  それはエンティティの理解であり、どのエンティティも少なくとも4つ(情報、地図、買い物、メディア)の内1つの種類に分類される。
• また、新しいインデックスの手法として、PWA、Googleアクション、Androidインスタントアプリなどがある。

Web戦略でお困りではないですか？

自然流入を増やしたい…
もっと問い合わせ、売り上げを増やしたい…
15年以上SEOサービスを提供してきたアイオイクスが、貴社の課題を解決するコンサルティングサービスを提供いたします。

スピーカー
Leslie To氏　3Q Digital SEOディレクター
Cindy Krum氏　MobileMoxie CEO
※Cindy氏のセッションは次回の記事でご紹介します。

モデレーター
Barry Schwartz氏　SearchEngineLand、RustyBrick

モバイル：やるなら今しかない(Leslie To氏)

スピーカー　Leslie To氏

サイト構成に関わらず重要な要素

※重要要素には「○」

アクセシビリティ

• リッチメディア
• インタースティシャル ○
• サイトナビゲーション

UX

• スケーリング ○
• テキストサイズ ○
• タップターゲット、padding ○
• ジェスチャー
• サイト内検索
• キーワードとタイピング
• コンバージョンフレンドリー ○

サイトスピード

• ページスピード

コンテンツ

• 可読性スコア

クロールステータス

• ログファイル解析

リッチメディア

HTML5を活用してビデオや、リッチコンテンツを提供する。サイト上で、ビデオをロード、デコード、再生させる。Flash等サポートされていない形式の使用はしない方がよい。

インタースティシャル

コンバージョンのためにフルスクリーンでインタースティシャル広告を表示させるのは、著しくUXを損なう。これはまだ良いケースで、最悪の場合Googleはインタースティシャルの裏にあるコンテンツを何も見てくれない可能性もある。バナーを活用した方がよい。

サイトナビゲーション

よくデスクトップ版サイトをタブレット版サイトに、そしてモバイル版サイトに中身を引き継いでいくケースがあるが、モバイルはデスクトップよりも表示領域が小さいので、多すぎる選択肢はユーザーを困惑させてしまう。Google Analyticsなどで、「サイト内検索」を見て、デスクトップよりもモバイルの方がサイト検索が多いのであれば、ナビゲーションに手直しが必要な可能性がある。

※ページ右側のサイトでは、カテゴリーページに辿りつくまでに3クリックも要した

スケーリング

縦画面、横画面ともにデバイスの画面サイズに、コンテンツとメディアがスケールするようにすること。CSSで絶対値を使って大きさを指定したり、スケールした際に粗さが目立つような低画質な画像は使わないこと。

テキストサイズ

viewportの範囲でスケールするようにする。16pxをベースのフォントサイズとして必要に応じてスケールさせるように。ユーザーに無為にズームさせないように。

タップターゲット

• タップターゲットの幅を最低でも48px以上に
• タップターゲットの周りは少なくとも32pxは離す
• ボタンをタップするためにズームさせない

ジェスチャー

特にEコマースサイトなどでは、つまむ、ダブルタップなどの一般的なジェスチャーを使えるようにすること。ズームされた時に、粗さが目立つような低画質画像を使用しない。

サイト検索

コンテンツを探しやすくするために、サイト検索をできるようにする。必要に応じてサイト検索で使われている言葉をサイトナビゲーションへ追加する。多くのユーザーがサイト検索が無いと探せないほどに、コンテンツを深い階層に埋め込むのは良くない。

キーボードとタイピング

入力する内容に合わせてキーボードを変更する(URL、Email、数字)クレジットカードの情報などを入力する際に、様々なキーボードを行き来させるのはやめた方が良い。

コンバージョンフレンドリネス

フォーム入力であろうと、電話であろうと、購入であろうと、コンバージョンを簡単にした方がよい。またコンバージョンしようとしてから、ユーザーに3クリック以上させるのはやめた方がよい。

ページスピード

Googleはモバイルページスピードをランキングファクターにするようだが、ランキングに関わらずユーザーのためには配慮すべきである。

コンテンツの可読性

コンテンツ内で複雑な表現は極力避けた方が良い。「新奇性」が高く「難易度」が低いコンテンツはシェアされやすい。

ログファイル解析

ScreamingFrog、botify、Deepcrawlなどのツールを使ってログファイルを解析し、GoogleBot Smartphoneがクロールしているかを確認するとよい。

別々のURLの場合の重要要素

デスクトップとモバイルで個別のページを持っている場合、やるべきことは多い。

URLとコンテンツ

• モバイルからデスクトップ版への<link>属性 ○
• Hreflangリンク ○
• 重複コンテンツ
• クロスリンク
• URL構造

リダイレクト

• 自動リダイレクト ○
• 同等のURL間でのリダイレクト ○
• リダイレクトに反してのページ移動 ○

クロールエラー

• モバイルのみ404
• モバイル404トラッピングページ

サーバー

• クロール率の増加のためのサーバーのキャパシティ ○

双方向の<link>属性

canonicalを設置して、重複コンテンツを回避する。

Hreflangリンク

インターナショナルコンテンツを持っている場合は、

• モバイル他言語版URL ⇒ モバイル版URL　へcanonical
• デスクトップ版他言語版URL ⇒ デスクトップ版URL　へcanonical

クロスリンクを極力なくす

× モバイル版サイト⇒デスクトップ版サイト⇒(リダイレクト)モバイル版サイト
○ モバイル版サイト⇒モバイル版サイト

自動リダイレクト

HTTPでのリダイレクトも、JavaScriptのリダイレクトも両方サポートされている。

別バージョンへのアクセスを可能にする

特にモバイルでの体験が優れていない場合は、尚の事設置した方が良い。個人的にはイベントトラッキングを設置して、どれだけのユーザーが自分でページを選んでいるかを見るとよいと思う。モバイル版を改善する上でのベンチマークになるから。

別ページからホームページへリダイレクトしない

例えばデスクトップ版のカテゴリページから、モバイル版の商品ページにアクセスしたときに、モバイル版のトップページにリダイレクトされるのは最悪。モバイル版の商品ページにリダイレクトされるべき。

モバイル版でコンテンツが存在しないのなら、デスクトップ版に残した方がよい

基本的にデスクトップとモバイルで同等のページを用意すべきだが、もし準備できていないのであれば404エラーページへリダイレクトするのではなく、デスクトップ版のページにユーザーを留めた方が良い。

ダイナミックサービングの場合の重要要素

3つの見るべきポイントがある

• HTTPヘッダを変更することを忘れない・・・ユーザーエージェントを見て、ユーザーを特定のページへ導いている
• ユーザーエージェントのリストを保持する・・・変更されやすいので注意
• 意図しないデスクトップとモバイルでのコンテンツ不一致をなくす

レスポンシブデザインの場合の重要要素

アクセシビリティ

• リソース、ページアセット ○
• Meta Viewportタグ ○
• 画像とリッチメディアのスケーリング
• ブレイクポイント ○

Robots.txtでリソースをブロック

ページスピードのためにやったとしても、ほんの数マイクロ秒しか改善しないので、やらない方がよい。

Meta Viewportタグ

• Width=device-width ⇒ デバイスの物理的な幅にマッチする
• Initial-scale ⇒ 訪問した際にズームした状態でアクセスする
• User-scale ⇒ ズームが可能(値はyesかnoか)

別の属性を使用する場合はカンマで区切る

画像とビデオもレスポンシブであるように

別の画像を別のデバイスで表示する場合は、media queryや<picture>属性を使用した方が良い。これにより、大きな画像をロードして下にスクロールしなければならないということはなくなる。
動画要素はviewportよりも大きくならないように。ビデオの大きさは、media queryやJavaScriptを使って制御する。

ブレイクポイント

GoogleAnalyticsのレポートを利用して、最適なブレイクポイントが設定できているかを確認する。

Web戦略でお困りではないですか？

自然流入を増やしたい…
もっと問い合わせ、売り上げを増やしたい…
15年以上SEOサービスを提供してきたアイオイクスが、貴社の課題を解決するコンサルティングサービスを提供いたします。