Moz - SEOとインバウンドマーケティングの実践情報

Service Workerがもつ圧倒的な力。SEO担当者は変化に適応が必要

Service Workerは、PWAの最も注目すべき部分で、今のウェブにとって最も重要な変化の1つだ。SEOの世界でも、この新しい技術の価値はもう見過ごせない

3回に分けてお届けしてきたこの記事も、これで最終回だ。後編となる今回は、PWAを支える2つの技術のうち、残るService Workerについて解説する。

→ まず前編中編を先に読んでおく

「Service Worker」は、PWAの最もエキサイティング部分であり、ウェブの世界に対して行われたこれまでで最も重要な変更の1つだ。ウェブサイトの構築、管理、監査を仕事にしている人なら、だれもがこの強力な新しい技術について知っておく必要がある。

ここからは、

  • Service Workerとは何か
  • Service Workerで何ができるのか
  • Service Workerの実装方法
  • Service WorkerがSEOにもたらす影響

といったことを理解していってほしい。

3. Service Workerがもつ圧倒的な力

最初にはっきりさせておきたいことがある。それは、ここまでで解説してきた「SPA」と、ここから取り上げる「Service Worker(サービス・ワーカー)」は、互いに排他的なものではないということだ。

つまりこの2つは共存するものだということだ。どちらもPWAと呼ばれるものの基盤となっているが、SPAではないPWAをつくることも可能だし、従来の静的なウェブサイト(クライアントサイドでレンダリングする処理がないサイト)にService Workerを統合することもできる(近い将来、そのようなサイトが増える僕は思っている)。

さらに、Service Workerはウェブアプリマニフェストのような他の技術と連動して動作する。この点については、僕の同僚であるマリア・カマネスが、最近公開されたPWAとSEOに関する優れたガイドで詳しく説明している。

だが、何はさておき、PWAの最もエキサイティングな機能を実現しているのはService Workerだ。Service Workerは、ウェブプラットフォームに対して行われたこれまでで最も重要な変更の1つであり、ウェブサイトの構築、管理、監査を仕事にしている人なら、だれもがこの強力な新しい技術について知っておく必要がある

僕と同じく、ジェイク・アーチボルド氏の「Is Service Worker Ready」ページを数年前から熱心にチェックし、ブラウザベンダーによる採用が増えている状況を目にしている人なら、Service Workerを採用するタイミングがまさに今であることがわかるだろう。

ここからは

  • Service Workerとは何か
  • Service Workerで何ができるのか
  • Service Workerの実装方法
  • Service WorkerがSEOにもたらす影響

を見ていくことにしよう。

Service Workerで何ができるのか

Service Workerは、メインのブラウザスレッドの外側で実行される特殊なJavaScriptファイルだ。ブラウザとネットワークの間に立って、次のような機能を実行する。

  • ネットワークリクエストの処理

    ブラウザで発生するネットワークへのリクエストをService Workerが受け取り、どう処理するかを決定して実行する。具体的には、

    • 通常どおりネットワークにアクセスする
    • キャッシュのみを利用する
    • リクエストされた先と異なるソースからまったく新しいレスポンスを作成(HTMLの構築も含まれる)

    などの選択肢があり、これによって表示を高速化したり、ネットワーク接続がない環境でもユーザーが操作を続けられるようにしたりできる。

  • 事前データ読み込み

    Service Workerのインストール中にファイルをプリロード(事前読み込み)することも可能だ。SPAでは、先ほど説明した「App Shell」が含まれるのが普通だが、シンプルな静的ウェブサイトでは、すべてのHTML、CSS、およびJavaScriptをプリロードすることで、オフライン時でも基本機能を維持できる。

  • プッシュ通知

    ネイティブアプリと同じように、プッシュ通知を受け取って表示できる。ユーザーが1回サイトを訪問してプッシュ通知を許可することは必要だが、それ以降は、ブラウザが開いてなくてもウェブサイトからプッシュ通知のメッセージを送り、Service Workerがそれを受け取ってコンピュータ上で表示できる。

  • バックグラウンド同期

    本来ならばすぐにサーバーにデータを送信するような場合でも、オフライン状態であれば、ネットワーク接続状態が戻るまでデータ通信を保留し、あとから処理できる。

    これは、ウェブメールサービスや写真アップロード機能の「送信箱」のような機能だと思えばいい。「リクエストを実行できませんでした。しばらくしてからもう一度やり直してください」といったメッセージを出すことなく、Service Workerが適切なタイミングで処理を実行してくれる。

このような機能のもたらすメリットは、すぐに思いつきそうなユーザビリティにとどまらない。Service Workerは、次のような価値も提供している。

  • ウェブのあちこちでHTTPSの普及を推し進める役割を果たしている(すべての主要ブラウザは、セキュアプロトコルで接続する場合のみService Workerを登録できる)。

  • スピードと動作パフォーマンスに大きな変革をもたらす。

  • キャッシュの効率を最大限に高め、ネットワークへの依存度を最小限に抑えるため、グーグルのPRPLパターンのような新しいアプローチやアイデアをサポートできる。

このように、Service Workerは、次の10億人のウェブユーザーに高速でアクセスしやすいウェブを提供するうえで、重要な役割を果たすことになるだろう。

そう、Service Workerは圧倒的な力をもっているのだ。

Service Workerの実装

ここでは、基本的な方法を下手に説明するより、役に立つリソースへのリンクを紹介したい。なんといっても、ここまで読み進めたあなたは、Service Workerに対する理解をどれほど深める必要があるのかを知るのに最適な状況にあるのだ。

  • Mozillaの開発者向けドキュメントは、Service Workerとその機能について詳しく学ぶのに最適な場所だ。

  • ウェブ開発に関する知識に自信があり試行錯誤しながら学ぶことを楽しめる人なら、グーグルのPWAトレーニングコースを最後まで受けることをぜひお勧めしたい。Service Workerに関する実践的な演習課題が用意されており、基本的なことを学習できる素晴らしい場所だ。

    ただし、自分のJavaScriptのレパートリーにECMAScript 6(ES6)とPromiseをまだ加えていない人は、厳しい試練を覚悟する必要がある。

ここで理解しておくべき重要なこと(そして実験を始めればすぐに気づくであろうこと)は、Service Workerが信じられないほどのレベルのコントロールを開発者に提供するという事実だ。接続性の問題を解決しようとした過去の試み(失敗に終わったアプリケーションキャッシュなど)と違い、Service Workerでは特定のやり方を強制されることはない。今直面している問題を独自のやり方で解決するコードを記述できるツールセットなのだ。

そのせいで、Service Workerは非常に複雑になることがある。Service Workerの登録とインストールは、簡単な作業ではない。Q&AサイトのStack Exchangeに書かれた内容をコピーアンドペーストしてまとめるだけでは、確実に失敗する(真面目な話、このようなことをしてはならない)。

つまり、自分のサイトに適したService Worker用のコードがどこかに転がっていることはない。適切なService Workerを記述したいのであれば、ウェブサイトのインフラ、アーキテクチャ、それに使用パターンを理解する必要があるのだ。ウェブ開発の第一人者であるアンクル・ベン氏も、それが最適な方法だと述べている。大いなる力には大いなる責任が伴うのだ。

最後にもう1つ。どれくらいの数のサイトがすでにService Workerを使用しているのかを知れば、きっと驚くことだろう。そのリストを表示するには、アドレスバーに次のように打ち込んでみるといい:

  • Chromeなら、chrome://serviceworker-internals
  • Firefoxなら、about:debugging#workers

そこに大量に表示されるだろう項目それぞれが、あなたが今まで訪問したサイトのなかでService Workerを利用しているところだ。

Service WorkerとSEO

SEOへの影響という点から見て、Service Workerで最も関連性が高い機能は、Fetch APIを使用してリクエストをハイジャックしたりレスポンスを変更または改ざんしたりできる機能だろう。「ページのソースを表示」タブや開発者向けツールの「ネットワーク」に表示される内容が、サーバーから返された内容と常に同じだとは限らない。キャッシュされたレスポンスだったり、さまざまなソースからService Workerが作成した内容だったりすることもある。

どういうことか自分で試すには、次のようにしてみるといい:

  1. GatsbyJSのホームページに移動する(初期のHTMLを取得する)。
  2. 上部ナビゲーションの「Docs」リンクをクリックする(別のコンテンツを表示する)。
  3. 右クリックして「ページのソースを表示」を選択する。

ページに書かれている文章が、ページのHTMLソース上のどこにも存在しないだろう。ソースに表示されているのは、インラインスクリプトやインラインスタイル、それに空のHTML要素など、Reactで構築された古典的なクライアントサイドのJavaScriptアプリだけだ。「ネットワーク」タブを開いてページを更新しても、「プレビュー」タブと「応答」タブに表示される内容はほとんど同じだ。DOMはJavaScriptで構築されているため、実際のコンテンツは要素インスペクターにのみ表示される。

今度は、同じURL(https://www.gatsbyjs.org/docs/)に対してcURLリクエストを実行するか、Screaming Frogを使用してページをフェッチしてほしい。すべてのコンテンツが表示されるだろう。正しいtitle要素とcanonicalタグ、それにサーバーサイドでレンダリングされたページから生成されるすべての内容が見つかるはずだ。Googlebotのようなクローラーも、これと同じ内容を見ることになる。

※Web担編注: 本記事の編集時点では、上記の前者のようにはならず、後者と同様にブラウザに表示されているコンテンツとHTMLソースが同一であるケースがあった。

このようになる理由は、このウェブサイトがハイブリッドレンダリングを使用しており、(ブラウザにインストールされた)Service Workerが以降のナビゲーションイベントを処理しているためだ。クライアントサイドのアプリケーションはすでに稼働しているので、ドキュメントページの生のHTMLをサーバーから取得する必要はない(コンテンツデータだけを受け取っている)。

そのおかげで、「ページのソースを表示」を選択しても、今ページとして表示されている内容に対応するHTMLが表示されるわけではないのだ。さらに、Service Workerがキャッシュを効果的に使ってくれるおかげで、オフライン時でもこれらのページをリロードできる。

Chromeの開発者ツールを開いて「ネットワーク」タブを見れば、どの応答がService Workerからのものなのかを簡単に確認できる。下図の「from ServiceWorker」という部分を見てほしい。これは、ブラウザがリクエストした内容をService Workerから取得したことを示している。

「アプリケーション」タブでは、現在のページで実行されているService Workerと、そのService Workerによって作成されたさまざまなキャッシュを確認できる。Service Workerを無効にするか迂回して、Service Workerが使用している可能性のある高度な機能をテストすることもできる。

このようなツールの使い方を学ぶことは、Service Workerの実装とテストにおおいに価値がある。ここでは詳しく説明しないが、グーグルのWeb FundamentalsにあるService Workerのデバッグに関するチュートリアルを学習することをお勧めしたい。

この記事ではなるべくプログラミングコードを記載しないようにしているが、ここだけは少し書かせてもらいたい。僕がまとめた以下の例は、シンプルなService WorkerがFetch APIを使用して、どのようにリクエストを処理したり、許可されるコントロールの範囲を設定したりするのかを示したものだ。

結果はこのようになる。

この例(非常に単純化された例であり、本番環境では使えない)で理解してもらいたい重要な点は、リソースのリクエストを処理する方法をきわめて細かくコントロールしていることだ。

上の例では、次のようにリソースのリクエストを処理している:

  1. まずキャッシュがあるか確認し、あればキャッシュを返す
  2. キャッシュがない場合は、ネットワーク通信でリソースを取得できる
  3. ネットワーク通信を利用できない場合は、カスタムページを返す

ここで選択したのは上記のようなシンプルなパターンだが、方法は無限にある。開発者は、ホスト名、ディレクトリ、ファイルタイプ、リクエスト方法、キャッシュの鮮度、その他もろもろに基づいて、リクエストを処理する方法を自由に指定できる。

ページ全体を含むレスポンスはService Workerで作成できる。一般的な手法やアプローチについては、ジェイク・アーチボルド氏の「オフラインクックブック」を見てほしい。

Service Workerの機能について学ぶなら、今が最適なタイミングだ。最新のテクニカルSEOに必要なスキルセットは、ウェブ開発者のスキルセットとかなり共通している。今や、Service Workerのデバッグを含め、すべての主要ブラウザの開発ツールを深く理解することが前提条件になっていると考えてほしい。

4. まとめ

SEO担当者は、変化への適応が必要

SEO担当者にとって、PWAやService Workerがもたらす影響や機会を理解していないことが問題視されることは、ごく最近までまったくと言っていいほどなかった。

これらは検索マーケティングに関連する事柄の辺縁にある最先端の機能だとみなされ、前述のようにJavaScriptに警戒心を抱く多くのSEO担当者は、実際に試してみようともしなかった。

しかし、PWAが急速に普及しつつあるいま、PWAの仕組みを理解しなければ、効果的な仕事をすることはもうすぐできなくなっていくだろう。

テクニカルSEOの実践者(マイク・キング氏の言うSEOエンジニア)として時代に取り残されないようにするには、パラダイムシフトをもたらしているこのような進化の最前線に立つ必要がある。ウェブ開発の知識がないテクニカルSEO担当者はすでに時代遅れなのだ。

そして、検索マーケティングの技術的な側面とコンテンツ的な側面の違いがさらに拡大することは、悪いことではないと僕は考えている。専門家になればいいのだから!

開発チームが新しいサイトを構築するために新たなJavaScriptフレームワークを採用したことを知ったときに、SEO担当者が批判的な反応を示すことは珍しくない。僕も、真新しい技術やフレームワークに惹かれる開発者をからかうような罪を間違いなく犯している。また、外野から見れば傾きかけているようにしか見えない開発スタックという塔に、抽象化や自動化という名の階層を次々と建て増しするような形でJavaScript開発の分野が急速に進化していく状況を揶揄したこともある。

だが、あるフレームワークが選択されている理由や、ある技術がプロダクション環境で利用されるタイミング、そしてそのような決定がSEOに与える影響について、時間をかけて学ぶ理価値は十分にあるのだ。

SPAにおける404の処理方法やサイト内リンクを批判するより、実際の動作を理解したうえで有意義なアドバイスを提供できるようになるほうが、はるかに素晴らしい。ジョノ・オルダーソン氏が「SEOの民主化」と題した講演で述べたように、SEOへの理解と認知度を拡大するには、同じ問題をその場しのぎで何度も修正するより、オープンソースプロジェクトに貢献するほうがはるかに役に立つのだ。

SEOを超えて

最後に伝えたいのは、PWAは非常に革新的な技術であり、間違いなくSEOをはるかに超える影響力をもつということだ。

デジタルマーケティングの他の分野も直接的な影響を受けることになるが、僕の立場から見て最も興味深いのは、アクセス解析やデータ分析にPWAが及ぼす影響だ。

  • あなたがオフラインでも部分的にまたは完全に動作するウェブサイトを運営している場合、オフライン時のことを考慮して分析設定を調整したことがあるだろうか。

  • プッシュ通知の受け取り登録をウェブサイトのKPIとして利用しているのなら、あなたはプッシュ通知を許諾したことを分析ツールにイベントとして送信し、その数を分析ツール上で目標設定して追跡しているだろうか。

ご存知のように、Service WorkerはJavaScriptのwindowオブジェクトにアクセスできないため、「通常の」トラッキングコードではこうしたイベントを追跡できない。その代わりに、Measurement Protocolを使用してヒットを作成し、必要に応じてそれらをキューに入れ、Googleアナリティクスのサーバーに直接送信するようにService Workerを設定する必要がある。

これは、僕が最近関心をもってよく調べている分野だ。PWA分析については、Builtvisibleのブログで僕が執筆した連載記事の最初の投稿を読んでほしい。

僕の話はこれでおしまいだ。最後まで読んでくれてありがとう。質問や意見があれば、以下のコメント欄にメッセージを残すか、Twitterで@tomcbennetまで連絡してほしい。

この記事の下書きに対してフィードバックを寄せてくれたオリビア・メーソン氏ウィル・ナイ氏に感謝する。

この記事が役に立ったらシェア!
みんなが読んでるWeb担メルマガで、あなたも最新情報をチェック
  • SEOやデジタルマーケの最新情報をゲット
  • 事例やインタビューも見逃さない
  • 要チェックのセミナー情報も届く
みんなが読んでるWeb担メルマガで、あなたも最新情報をチェック
  • SEOやデジタルマーケの最新情報をゲット
  • 事例やインタビューも見逃さない
  • 要チェックのセミナー情報も届く

Web業界の転職情報

もっと見る
Sponsored by

人気記事トップ10(過去7日間)

今日の用語

NSFW
Not safe for workの略。直訳すると「職場向けとしては安全ではない ...→用語集へ

連載/特集コーナーから探す

インフォメーション

Web担のメルマガを購読しませんか?
Web担の記事がコンパクトに毎週届くメールマガジン「Web担ウィークリー」は、10万人が読んでいる人気メルマガ。忙しいあなたの情報収集力をアップさせる強い味方で、お得な情報もいち早く入手できます。

Web担に広告を掲載しませんか?
購読者数10万人のメールマガジン広告をはじめとする広告サービスで、御社の認知向上やセミナー集客を強力にお手伝いいたします。

サイトマップ
RSSフィード


Web担を応援して支えてくださっている企業さま [各サービス/製品の紹介はこちらから]