SEO Mythbusting エピソード4のまとめ: ウェブパフォーマンスとUXについて

概要

1. 古い・安いデバイスのモバイルウェブについて
2. Googleのパフォーマンス指標
3. GoogleからSEO担当・開発者へのコミュニケーションについて
4. JavaScriptベースのウェブサイトのランキング、インデックスとパフォーマンス
5. JavaScriptより最新HTML、CSSに頼るべきか

Q&A

Samsung社のAda Rose Cannon氏が、Samsung Internetブラウザのアドボケートであり、ウェブのプラットフォームとしての重要性を広める活動をしております。今回はCannon氏からGoogleへの質問だけでなく、逆にGoogle側からの質問にも答えています。
※今回も一部省略や言い換えをしております。

Google Splitt氏：

本日はSEOとウェブのパフォーマンス、UXの関係について話したいので、まずはウェブ開発の際に、注力すべきと思われる点について教えてください。

Samsung Cannon氏：

ウェブが最新のPCだけでなく、全世界のどの環境にでもいる人に対して問題なく動作することを望んでいます。多くの人が何年も前のモデルや安いデバイスを使用しています。現在のウェブはそのような人には届いていない状況です。

Google Splitt氏：

本件は（Google社の）Alex Russel氏の＄100以下のデバイスを利用するユーザーについての素晴らしいトークがありますね。

Samsung Cannon氏：

時間が立てば立つほどモバイルデバイスが良くなっていくという誤解がありますが、そういうわけではなく、層が広がっていくだけです。

Googleが最近パフォーマンス指標（速度）をランキング要素として追加していると聞いていますが、こちらはレンダリング速度やページの品質が低くないかなど、フロントエンドのパフォーマンスのことでしょうか？それとも単純にページが早くロードされるという点でしょうか？

英語のGoogleブログ参照：
Using page speed in mobile search ranking
User experience improvements with page speed in mobile search

Google Splitt氏：

パフォーマンス指標は様々あり、例えばTime To First Byte（最初の1バイトが到着するまでの時間）、Time to Interactive（ページがユーザーの動作に応答できるようになるまでの時間）、First Meaningful Paint（ユーザーにとって意味がある表示ができたタイミング）、またフレームレートなどもあります。クロールし、インデックスのためにページをレンダリングするGooglebotはさほどページの操作を行わないため、例えばスクロールがスムーズにできているかなどの詳細を確認することはできませんが、レンダリング部分は把握できます。ページがユーザーの入力に応答できるようになったタイミング、コンテンツがユーザーに利用される準備ができたタイミングは取得でき、その辺りの指標の組み合わせを見ています。

Samsung Cannon氏：

この間知り合いがReactで作った素晴らしいサイトがGoogleでヒットしていたのに、SEO担当者が利用しているツールでは成果の計測が正しく行えなかった話を聞きました。クライアントサイドレンダリングされているページでもパフォーマンスを正しく計測できるために、GoogleはSEO担当者に最新のSEO指標についてコミュニケーションを取っていますか？

Google Splitt氏：

皆に使用されているツールを直すことはできませんが、SEOのブラックボックスを皆のために開けていきたいとは考えています。SEO担当やツールベンダーとコミュニケーションを取り、指標を伝えたり、Google側でもツールを提供するようにしています。例えば、検索パフォーマンスが確認できるサーチコンソールがあります。
また、「JavaScriptを使えばSEOが壊れる」、「ReactやAngularは使ってはいけない」のような宣言が誤っているという認識を広めたいです。そのような回答は非常に楽な回答でしょうが、正しい回答ではない場合があります。

Samsung Cannon氏：

Splitt氏がChrome Dev SummitでJavaScriptに頼るサイトのレンダリングに最長1週間かかる可能性があるという話をしていたかと思います。そのようなサイトがペナルティを受ける状況にあるということでしょうか？

Google Splitt氏：

ペナルティではないです。ランキングには問題ありません。ただ、インデックスステップには課題が出てきます。（Googlebotが）まずページをレンダリングの待ち行列に追加し、リソースが確保され次第レンダリングを行いますが、その辺りに時間がかかってしまうと、インデックス内コンテンツの更新スピードが下がります。そのため、例えば更新頻度が重要なニュースサイトは注意が必要です。どちらにしても、（JavaScriptの頼りすぎは）ユーザーにあまり良くないためユーザビリティ上の問題も発生すると思います。Googleはユーザーにより良い結果を届けたいですが、ページロードに時間がすごくかかるとすると、それはUX上も良くないと思います。そのため、クローラーのためだけではなく、ユーザーのためにも直すべきところです。

Samsung Cannon氏：

毎日新しいコンテンツを提供するビジネスモデルのサイトであれば、Googleの検索結果が追い付かない可能性があるということですか？

Google Splitt氏：

その通り、インデックスが更新されるまでにタイムラグがある可能性があります。そしてもう一度言いますが、良いUXが非常に大事で、特に古いデバイスではクライアントサイドレンダリングに頼るUIでは良いUXを実現できないと思います。この問題を根本的に解決するにはハイブリッドレンダリングやサーバーサイドレンダリングが適切ですが、それらをやらない場合はクローラーに静的なページを渡すダイナミックレンダリングも回避策としてあります。そうすれば、インデックスは早まります、ただしユーザビリティとUXの問題は解決されません。

Samsung Cannon氏：

それでは、最新のHTMLとCSSに頼った方が無難ということでしょうか？

Google Splitt氏：

そうです。HTML、CSSとJavaScriptで考えると、単純にHTMLとCSSのほうがJavaScriptより強固です。JavaScriptに頼りすぎると、例えば接続が不安定な環境などでトラブルが発生しやすいです。Polyfillやプログレッシブエンハンスメント（積極的強化）を活用し、JavaScriptは注意しつつ利用してください。

Samsung Cannon氏：

Googleから、JavaScriptに頼りすぎないこと、良いHTMLとCSSをうまく活用できることがSEOにメリットがあると聞くと嬉しいです。
お互いの目的が明確であり、Googleが考えていることがわかっていれば、開発者がプラットフォームをうまく活用し、良いサイトを作れると思います。Googleがウェブを豊かな西洋諸国だけではなく、全員に利用しやすくできるように貢献してくれれば素晴らしいです。

まとめ・感想

パフォーマンスの指標については具体的に聞けなかったのが少し物足りなかったですが、今回のゲストのCannon氏のお話が非常に重要だと思いました。
JavaScriptを使いつつ、デバイスや接続環境に優れていないユーザーを見捨てないように考慮することが大事ということがわかり、Googleのパフォーマンスについての考え方がまた少し明確になりました。

次のエピソードはウェブフレームワークについてとのことで、また貴重な話を聞けると思います。