fugafuga.write

日々のログ

Service Worker について調べた

Service Worker とは

Service Worker はブラウザが Web ページとは別にバックグラウンドで実行するスクリプトで、Web ページやユーザのインタラクションを必要としない機能を Web にもたらします。すでに現在、プッシュ通知やバックグラウンド同期が提供されています。さらに将来は定期的な同期、ジオフェンシングなども導入されるでしょう。このチュートリアルで説明する機能は、ネットワークリクエストへの介入や処理機能と、レスポンスをプログラムから操作できるキャッシュ機能です。

なにができるの?

  • プッシュ通知
    • ブラウザを閉じていても通知が届く
  • バックグラウンド同期
    • ブラウザを閉じてもデータ送受信できる
    • オフライン操作
  • データのキャッシュ
    • ページや画像などを保存できる
  • ブラウザからのリクエストをフックしてゴニョゴニョできる

Rails と連携するために

rossta/serviceworker-rails を使う

  • ServiceWokerはHTTPS必須だがlocalhostドメインであればHTTPでも動く

参考

Rails で webpush

zaru/webpush

参考

注意点

  • デバッグ、テスト環境を整備しておく
  • キャッシュの同期、データ容量を考慮
  • プッシュ通知は適切に使用する
    • UXに密接に関わってくる

参考

Action Cableの諸々について調べた

Action Cableとは

WebSocketとRailsのその他の部分をシームレスに統合するためのもの。 Railsで扱っているデータをWebSocketでも扱えたりする。その逆も。

WebSocketについて

WebSocketとは

HTTPなどと同じく通信規格の1つ。Webアプリケーションにおいて双方向通信を実現するために開発されている。

メリット

  • 通信サイズが小さい
  • 双方向通信が可能なのでサーバーからpushできる
  • リアルタイム通信

注意点

  • 接続しっぱなしなので、切断処理や再接続処理をきちんとしていないと問題が起きるかも
  • ws://~の場合、暗号化されていないので機器によっては通信を遮断する可能性がある
    • どこかのプロキシサーバーで引っかかる可能性がある
    • なので、基本的にTLS上で通信するようにする
    • URIスキームはwss://~になる
  • コネクション数の制限
    • 正しく切断していないとポートが枯渇する可能性がある
  • 接続が持続するため、ロードバランサーが有効ではなくなる
    • 負荷分散はクライアント側でやるのが吉
  • サーバー再起動時の再接続処理時に高負荷になる
    • これもクライアントで負荷分散する
    • アクセスするまでにランダムwait入れるなど

IPAによるWebSocketにおける脅威シナリオ

https://www.ipa.go.jp/security/awareness/vendor/programmingv2/web09.html

Action Cableについて

詳しくはこれ : https://railsguides.jp/action_cable_overview.html

仕組み

Pub/Sub方式でサーバーとクライアント間でWebSocket通信を行う。

参考

プリレンダリングについて調べた

プリレンダリングについて調べたので書いておく。

構成と役割

Rails + React + Redux

以下プリレンダリング用のライブラリ

  • prerender
  • prerender_rails
    • https://github.com/prerender/prerender_rails
    • サーバー側で動くRack middleware
    • クローラーからのリクエストかどうか判定する(User Agent と _escaped_fragment_パラメーターで判断)
    • prerenderサービスへのGETリクエストを作成する
    • クローラーにHTMLを返す

Ajaxを使ったWebページをクローリングするための歴史的経緯

_escaped_fragment_とはなんぞや?というところから。

当時(2009年頃)Ajaxを使ったWebページがクローラーでインデックスできないので以下のようなガイドをGoogleが出した。

  1. GoogleのクローラーはURLに#!が含まれているとAjax使ったページだと認識するよ
  2. なのでAjaxを使ったWebページのURLは#ではなく#!を含むようにしておいてね
    • #が使われていると#以降はHTTPリクエストとして認識されないから書き換えてね
    • サーバー側では#!使ったページのスナップショットを用意する必要があるよ
  3. クローラーがURL内の#!を発見すると_escaped_fragment_に置き換えてアクセスしてくるよ
  4. その時は事前に用意したスナップショットをクローラーに返してね
  5. #!をURLに含まないページについては<meta name="fragment" content="!">を設定してね
  6. www.example.comwww.example.com?_escaped_fragment_=にしてアクセスするよ
  7. 私達はパラメーターが付加されたURLを ugly URLと呼んでるよ

WebMaster向けに出されたDocument : https://developers.google.com/webmasters/ajax-crawling/docs/getting-started

この仕様が2018年夏でサポートされなくなる。

Googleによるアナウンス(2015年に出された) : https://webmaster-ja.googleblog.com/2015/10/deprecating-our-ajax-crawling-scheme.html

じゃあどうすればいいの?ということについては、

Google の 2009 年の提案は、もう有効なものではありませんので、今後はプログレッシブ エンハンスメントの原則に沿って開発を進められることを推奨します。たとえば、HTML5 の History API を使用することで、Google のシステムだけでなく幅広いブラウザが履歴にアクセスできるようにすることが可能です。

とのこと。

懸念点

プリレンダリングされたページと実際のページが異なるとクローキングとみなされる場合がある。

Q: JavaScript フレームワークを使用し、Googlebot にはプリレンダリングしたページを提示しています。このままで問題ありませんか? A: 通常、Google のためだけにプリレンダリングする必要はありません。プログレッシブ エンハンスメントの原則に沿いつつ、パフォーマンス最適化のためプリレンダリングを行う場合、プリレンダリングしたコンテンツと、通常のユーザーに対して表示するコンテンツが、見た目上も体験上も同じになるようにしてください。Googlebot に対して提示するコンテンツと、通常のユーザーに対して表示するコンテンツが異なる場合はクローキングと見なされ、ウェブマスター ガイドライン違反と判断されることがあります。

まとめ

クローラーがJavascriptを実行して実際のページを自分でレンダリングできるようになっているため、GoogleのSEOのためにプリレンダリングの仕組みを導入することは有効ではない。

プログレッシブ エンハンスメントの原則に沿ったWebページを作成することが必要になると思われる。

SPAにおけるSEOについて調べた

目的

SPA構成のWebアプリケーションはクライアントでDOMをレンダリングするため、検索エンジンにインデックスされない可能性がある。そのため、SPAでSEOするために必要な情報を集めた

TL;DR

  • SSRとプリレンダリングという2つの方法がある
  • SSR
    • サーバーでDOMレンダリングすること
  • プリレンダリング
    • SEOのためにページをキャッシュすること
  • SSRは導入コスト高い
    • レスポンスがシビアに求められる場合に検討する

SSRについて

1. SSRとは

Server Side Rendering のこと。

通常、ReactやVueなどはブラウザでJavascriptを実行し、コンポーネントのDOMを生成する。 SSRの場合、サーバーでJavascriptを実行し、コンポーネントのDOMを生成、静的なマークアップとしてクライアントに送信する。

Rails + React + hypernova でSSRする例 (AirbnbがSSRライブラリを提供している)

https://qiita.com/noriaki/items/e2dac69b9dd88334dd43

2. SSRのメリット

  • SEOが向上する
    • 検索エンジンのクローラーに完全なページを提供できるため
    • GooglebotなどはJavascriptを実行できるようになってきている
  • コンテンツの表示速度が短縮できる
    • あらかじめページを生成しているため
    • インターネットの速度や処理能力の低いデバイス向け
    • コンテンツの所要時間がコンバージョン率に関連している場合は重要

3. SSRの注意点

  • 実装コストが高い
    • SEOだけであればプリレンダリング(後述)でも効果がある
  • ブラウザ固有のコードを使う場合、気をつけないといけない
    • サーバー側で動かない
  • 特別な処理が必要になる場合がある
    • 外部ライブラリなど
  • サーバーの負荷が増える
    • クライアントで実行する描画処理をサーバーで処理するため

4. SSRよもやま

あなたのアプリケーションに SSR を使用する前に、まず初めに、実際に SSR が必要かどうかを考える必要があります。これは主に、アプリケーションのコンテンツに対する時間の重要性によります。 例えば、最初の負荷の数百ミリ秒がそれほど重要ではない内部的なダッシュボードを構築する場合、SSR は過度なものとなるでしょう。しかし、コンテンツの所要時間が非常に重要な場合は、SSR を使用してできるだけ早く初期ロードパフォーマンスを保つことができます。

プリレンダリングについて

1. プリレンダリングとは

SPAとして構成されたWebページを検索エンジンにインデックスさせたい場合に使う。主にSEO目的。 クローラーからあるページにアクセスがあった場合、そのページをサーバー側でヘッドレスブラウザなどを使ってレンダリングし、静的なHTMLとしてキャッシュしておく。次回、クローラーがそのページアクセスしてきた場合、キャッシュされたページを返す。

レンダリング・ページキャッシュをするためのSaaSがある。

https://prerender.io/documentation

Vueによるプリレンダリングの解説 -> https://ssr.vuejs.org/ja/#ssr-vs-%E3%83%97%E3%83%AA%E3%83%AC%E3%83%B3%E3%83%80%E3%83%AA%E3%83%B3%E3%82%B0-%E4%BA%8B%E5%89%8D%E6%8F%8F%E7%94%BB

2. プリレンダリングのメリット

  • SSRと比較して導入コストが低い
    • クローラーに対してのみ動作する
    • キャッシュするだけ

3. プリレンダリングの注意点

  • 頻繁に内容が更新されるページが多数ある場合
    • 変更が多いとそもそもキャッシュが利かない
    • 数が多いとページをキャッシュするのに時間がかかる

SPA知見

まとめ

対SEOならプリレンダリングで事足りる

参考