動的な配信…ダイナミックサービングの基本を学んでモバイルフレンドリーに対応しよう!【初心者向け】

dynamic-serving

動的な配信(Dynamic-Serving)とはページをリクエストしてきたユーザーのユーザーエージェント(User-Agent)の情報によってサーバーでデバイスやブラウザを識別し、その情報に基づき、同じurlで異なるhtmlに配信を振り分ける手法です。

この動的な配信(Dynamic-Serving)の手法はgoogleもモバイルフレンドリーに対応する為のひとつの方法として取り上げています。

動的な配信(Dynamic-Serving)によって、pc、モバイルなどデバイスごとにページを振り分ける方法は、少し変則的なものも含めればいくつか考えられるのですが、今回はデザイナーやフロントサイドエンジニアの観点から見れば一番スタンダードな方法と思われる、.htaccessファイルによるサーバーでの振り分け方法を紹介したいと思います。

.htaccessファイルにmod_rewriteの設定を記述する【初心者向け】

.htaccessファイルとはサーバーに対する設定の変更や新たな指定を記述する為のファイルです。レンタルサーバーなどでroot権限を持たない場合は.htaccessファイルを使用することになります。Apache(サーバー)のmod_rewriteモジュールでデバイスごとにページを振り分ける基本的な設定を、.htaccessファイルに記述して解説していきます。

Rewrite ファイルディレクトリ構成

dynamic-s-dev

mod_rewriteとはapache(サーバー)がurl書き換えの為に用意したモジュール(部品)です。.htaccessは上のディレクトリ構成での記述であって、ディレクトリの構成が変われば記述も違うものになります。

それでは.htaccessファイルの記述の内容について簡単に説明します。

<IfModule mod_rewrite.c>~</IfModule>

サーバーにmod_rewriteが利用できるか確認します。利用できない場合、この記述を省くとエラーになります。

RewriteEngine On

mod_rewriteの機能を有効化するという記述になります。Offと記述すれば無効化します。.htaccessファイルを設置したディレクトリから下の範囲で有効になります。.htaccessファイルは、ディレクトリ単位で設定することができ、下のディレクトリに別の.htaccessファイルを設置した場合そのディレクトリより下のディレクトリではそのファイルの設定が優先されます。

RewriteBase /

RewriteBaseはRewrite処理のベースとなるURLを指定します。「/」を指定することで、どのディレクトリに設置を行った場合でも必ずドキュメントルートからのパスになります。

説明の中のディレクト構成上では「https://your-domain.com」を指します。

この処理に関しては、RewriteBaseをしっかり把握することが、ひとつのポイントになってきます。

RewriteCond %{HTTP_USER_AGENT}(iPad|Android)

RewriteCondとは、URL書き換えのルール、条件を指定するmod_rewriteモジュールの構文です。RewriteCondの条件が満たされた場合、RewriteRule ^(.*)$ sp/$1 [L,NS]の処理が行われ、それ以外は直下の処理は無視され、次の処理に移ります。

%{HTTP_USER_AGENT}(iPad|Android)は簡単に言い換えれば、「ページの閲覧を求めるユーザーのUSER_AGENT情報の中にipadもしくはAndroidの文字列にマッチする文字列が含まれるか」ということです。含まれれば、直下のRewriteRuleの処理に入ります。

RewriteRule ^(.*)$ sp/$1 [L,NS]

RewriteRuleとは、URLをどのように書き換えるかを指定するmod_rewriteモジュールの構文です。

「^(.*)$」はこの説明上ではbaseのURLがhttps://your-domain.comでRewriteBaseの「/」で区切ってあるので、https://your-domain.com/index.htmlの「index.html」の部分になります。sp/$1の$1の部分にこの「index.html」が入ります。結果、「index.html」は「sp/index.html」に書き換えられます。

最後に[]で囲まれたRewriteフラグですが、「L」は ’last’ の略で書き換えの処理が行われたら次の処理には進まないことを意味します。「NS」は大文字小文字を区別しないことを表します。

RewriteCond、RewriteRule 、とmod_rewriteモジュールのディレクティブを流して説明をしてきて、.htaccessの記述の内容を簡単に日本語にRewriteすると「https://your-domain.com/index.htmlにアクセスしてきたユーザーのUser-Agentの情報の中に、iphoneなどの文字列が含まれれば、https://your-domain.com/sp/index.htmlのファイルを呼び出して下さい。終了。」というような感じです。

RewriteCond %{REQUEST_URI} ^/(pc|sp)/・・・・・RewriteRule .* – [L]

最後になりましたが説明します。先に日本語に言い換えると「リクエストしてきたURLの中にpcもしくはspの文字が含まれていたら、なにも書き換えない」です。

まず、RewriteRuleの書き換えというのは逆も真なので、もし、[L]のフラグが外れたらmainディレクトリとspディレクトリをグルグル回ります。あとはユーザーが誤ってリクエストした時の対処です。

「ム!!!これ必要なの?」となんとなく思った方がいれば、その方は読めている証拠ですし 疑問- – ->考える はこの世界とても重要なので正解だと思います。(快…感!)…ただ一応この世界、サーバーも含めてバックエンドの奥の奥に行くほど自分ではなく他人(主にアメリカ人)の領域です。動きに支障がなければ「危ない場所には鍵を掛ける」くらいの気持ちでいきましょう。

同じような理由でpc、sp の各ディレクトリ下の.htaccessファイルに以下を記述しておきましょう。

以上でmod_rewriteでのurl書き換えについては説明を終わりにしたいたおもいます。しかしながらこれだけでは、現在のインターネットの状況を鑑みると少し弱点があります。それはキャッシュの問題です。その問題に対処するにはVary HTTP ヘッダーの設定がマストであるとgoogleは述べています。ここからはキャッシュの問題、Vary HTTP ヘッダーとは何?といったことについて書いていきたいと思います。

キャッシュサーバーの知識は必須!昨今のインターネットの仕組み。

通常、インターネットの通信はデータを要求するユーザー側のクライアントサイド、要求されたデータを返すサーバーサイドの二者間通信のイメージがありますが、現在のインターネットではその二者の間に様々な仕組みが組み込まれています。そのひとつがキャッシュもしくはキャッシュサーバーです。

キャッシュサーバーとはユーザーの要求に対してメインサーバー(ウェブサーバー)で処理をした後のデータを保存しておく為のサーバーです。ユーザーの要求に対してメインサーバーで処理後のほぼ静的なデータを返し、動的な処理は行わない為、ユーザーへのレスポンスは高速化され、また、メインサーバー本体への負荷も軽減します。

動的配信とコンテンツキャッシュ

少し復習になりますが、動的配信は、ひとつのURLでユーザーエージェント(User-Agent)の情報によって複数のデータから選別してデバイスに応じたコンテンツを返します。これに対してキャッシュサーバーは処理されたコンテンツをキャッシュしてユーザーに返すだけで、ユーザーエージェント(User-Agent)による選別は基本おこないません。

キャッシュサーバーは何もしなければ、ユーザーがアクセスしてきたひとつのURLに対してひとつのコンテンツを返すだけで、ユーザーエージェント(User-Agent)による選別はしない為、パソコンからアクセスしてきたユーザーに対してスマートフォン用のコンテンツを返す間違いを起こす可能性があります。

また同じような問題がgoogleのインデックスでも起こりえます。googlebotが同じURLで二つ以上のコンテンツがあることをうまく認識できないケースが出てきます。

ここで必要になるのがこれから述べるvaryの設定になります。vary httpヘッダーを設定することで、コンテンツの返信を間違うような問題を極力抑えることができるようになります。

Vary Httpヘッダーとその指定方法

インターネットの通信はアクセス、レスポンスともにその通信に必要なデータをいくつかのパートに分けてやり取りしています。Httpヘッダーもそのひとつで、データの追加や削除も可能です。VaryもHttpヘッダーとして追加できるフォーマットのひとつで、指定したプロパティーごとに、その内容を確認するようキャッシュサーバーに対して要求する役割を持ちます。

Varyの設定はさほど難しいものではなく、User-Agentでコンテンツを分岐している場合は以下の1行を.htaccessファイルに追加するだけです。

この指定をしておけば、キャッシュサーバーはUser-Agentに応じたコンテンツを認識し、返すことができるようになります。

また、google botもコンテンツを認識しやすくなります。そのことはseoやモバイルフレンドリーなどの観点からもより有効です。

Vary Httpヘッダー設定の確認

Vary Httpヘッダーの設定を確認するには、Google Search Console内のFetch as Googleというツールを使用します。

User-Agent設定前

fecth-as-google

User-Agent設定後

fecth-as-google

Fetch as Googleでプロパティーにあなたの確認したいサイトを設定して、「取得してレンダリング」ではなく通常の「取得」ボタンを押せば確認できます。Googlebotが実際に認識しているかどうかも重要なのでブラウザよりはFetch as Googleで検証することをgoogleは推奨しています。Fetch as Googleで確認できれば、Googlebotも認識することができます。

動的な配信(Dynamic-Serving)まとめ

動的な配信も含め何かの振り分けにユーザーエージェント(User-Agent)を利用しているケースでは、新しいデバイスが登場したり、プログラムの書き方にアップデートがあった場合などで問題が生じるケースも出てくる為、常に最新の情報を入手できる環境と管理が重要になります。制作側としては常にそのことを頭に置いておきましょう。それではまた。

0

コメントして下さい

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です