Edited at

SPAを導入する際に必要だったSEO対策についての話 -SSR? Prerendering?-

More than 1 year has passed since last update.

これはDMM.com #2 Advent Calendar 2017の4日目の記事です。

カレンダーのURLはこちら

DMM.com #1 Advent Calendar 2017

DMM.com #2 Advent Calendar 2017

ども!おはこんばんちは!

動画配信サービスでWebエンジニアをしている、17新卒の小芝です!

動画配信サービスに配属されてからは、

フロントエンドの改修やログ収集システムの構築など、

幅広くやらせていただいています!

この記事では、


  • SPAにおけるSEO対策がなぜ必要なのか?

  • 対策するにはどんな候補が存在するのか?

  • どういう基準で、どんな選択を行ったのか?

についてまとめてみました!


5/24 追記

JSサイトのための第4のレンダリング構成としてダイナミックレンダリングをGoogleが発表 #io18 #io18jp

SEOのためのSSRはやらなくても良くなったかも??


ところでSPA(Single Page Application)ってなに?


特徴として、1枚のHTMLページに対してJavaScriptで動的に変更を加えながら、

画面の描画を行うアプリケーションのこと(名前の通り)

また、使用するパーツをコンポーネント化するため、

パーツのカプセル化を実現し、再利用も容易になっている



従来のアプリケーションとは何が違うのか?


  • 従来:コンテンツの切り替えには、ページ全体を読み込む必要がある

  • SPA:都度都度ページ全体の更新する必要がなく、部分的な更新が行える

様々なフレームワーク(VueやReact等)が出てきたおかげで、

世の中にはかなり普及してきているのではないかと思います

ここでは、

「SPAはjsで動的に画面描画を行う」

というところがポイント!


SPAでSEO対策がなんで必要なの?


そもそもSEO(Search Engine Optimization)とは?


ざっくり言うと、検索した時に上位表示させるための様々な手法

(多少語弊はある)


コンテンツをたくさん持つ企業において、SEOはかなり重要!

仕組みとしては、


  • クローラー(Googlebotなど)と呼ばれるロボット型検索エンジンが、Web上のファイルを常に収集

  • 収集したファイルから、様々な要素を基に最適化を行っている

つまり、

クローラーに無視されれば、検索の上位には現れない、、、!


SPAでSEO対策が必要な理由は?

さきほど、SPAは画面の描画にjsを主に使用する、と説明しました

実は、最も気を遣うクローラーの1つであるGooglebotの特徴として、


  • GooglebotのJSエンジンが古い

このことから、動的に更新されたjs部分を、

クローラーが正しく評価できているかわからない問題が存在します!

ちなみに社内で行ったテストではうまく評価してくれなかった、、、

「SPAにしたはいいものの、検索に引っかからない」というのは、

かなり致命的な問題ですね!

ここでは、

「クローラーはjsを正しく評価できない」

というところがポイントです!


どうやって解決すればいい?


一般的な解決方法は?


  • サーバ側であらかじめレンダリングを行い、その結果をクライアントに返す

基本的にはこれに尽きます!

最初からクローラーのjs処理能力に頼らない、ということですね!


どんな手法があるのか?


  • SSR(Server-Side-Rendering)


    • その名の通り、サーバサイドでフロント側の処理を行う(nodejs等)

    • そのため、ページの初期表示が早い

    • SEO対策+ページ表示速度の改善のためにSSRを行う企業は多い

    • その代わり、開発コスト高い&CPU処理能力が必要



  • Prerendering


    • 主にHeadless Browser(GUIのないブラウザ)を用いた手法

    • サーバの中にブラウザを用意して、URLを投げたらレンダリング結果が返ってくるイメージ

    • レンダリング用サーバさえあれば、割と簡単にできそう

    • GoogleChromeの中の人が良さげなのを作っていた(Rendertron

    • 懸念点として、オーバーヘッドやキャッシュをどうするか?などがある



SlideShare等で事例を調べると、ほとんどの企業がSSRを行っており、

Prerenderingの情報はあまり出てこない、、、(日本での事例はなさそう?)

割と最近の記事では、SEO対策ならPrerenderingが楽だよー

ってのがいくつかあり、日本では試してる人がいないだけかな?という印象


いくつかの項目に分けて比較してみた

調べてみると、使用する技術も様々なものがありそうなので、

比較するようにいくつかの項目に分けてまとめてみました!


  • 現在のシステムへの組み込みやすさ

  • 開発コスト

  • パフォーマンス

今回は、元々存在するシステムの改修のため、

PHP(サーバサイド)とVue(フロントエンド)を用いると仮定し、いくつか候補を出しました

手法
用いる技術
組み込みやすさ
開発コスト
パフォーマンス

SSR
PHP+V8js+Vue
(V8js:PHPの中でjs書けるやつ)

(V8jsのおかげでつなぎ込みが容易)
×
(実装のコストはそれなりにかかりそう)

SSR
Nuxtjs
(Vuejs+Nextjs)
×
(もしも最初からSPAで作っているならこれがbestか)

(SSR用に色々用意されていて便利そう)

Prerender
Rendertron
(Headless Browser)

(別途レンダリング用サーバを用意するだけ)

(実装はほぼないが、実験が必要なため)
△?
(要実験)


で、最終的にどれを選んだの?

やはりSEOのためだけにSSRの実装を行うのはコスパが悪いと思い、

事例は少ないですがRendertronを簡単に使ってみることにしました!

今後は、キャッシュ機構やページ表示速度など、

懸念点を含めて色々実験を行っていく予定です、、、

これがイマイチなら組み込みやすさを考慮し、

(PHP+V8js+Vue)を使って仕方なくSSRしようと思います


まとめ


  • SPAなサービスではSEO対策を考慮する必要がある

  • クローラーに気を遣って、あらかじめサーバー側でレンダリングが必要

対策するために、

まずは手っ取り早そうなRendertron(Headless Chrome)を試し、

イマイチであれば、PHP + V8js + Vuejsで実装していこうかなと

Rendertron使ってるよ!

とか、

もっといい方法あるよ!

とかとか、

より良い情報をお持ちの方は、ぜひご紹介ください!

明日はDMM.com #2 Advent Calendar 2017の5日目!

@mukkoさんです!


参考サイト

SSR不要論系