LaravelでAMP(Accelerated Mobile Pages)ページを実装する際に大切な事は、開発するWEBアプリケーションによってベストな手法で実装する事です。「どこをAMP対応させるのか」「現在のアプリケーションのベースロジック」そして「AMPの仕様」をよく確認し、設計を行ってから開発に入る事が大切です。

LaravelでAMPページを作成するベストプラクティス

昨年頃から段々と話題になってきた AMP(Accelerated Mobile Pages) ページですが、今や実装も当たり前になりつつあるかなと思いつつ、ここで一度、Laravel で AMP ページを作成する際の自分なりのベストプラクティスをまとめようと思います。
というのも、Laravel で AMP ぺージを作成する方法は１つではありません。ミドルウェアで、コントローラでと、処理の流れも含め実装手段はいくつでもあります。
はっきり言ってどの方法が最も優れているというような結論は出ないと思います。そしてそもそも、そういう話ではないと思っています。
大切な事は、開発する WEB アプリケーションによってベストな手法で実装する事です。
ここでいう「ベスト」というのは、実装の手間を少なくするかとかロジックを最短にする事、色々とこねくり回さなくて済むような手法でという意味です。
AMP ページを作成しようとする時点で既に通常のページが出来上がっている事を想定していますが（新規開発時に企画出来ているともちろんベストです）、AMP ページを作成する為にロジックをあれこれと AMP ぺージ用に組むと、機能追加や修正の際に工数が肥大化し、作業が大変になってしまいます。
なので AMP ページを実装する際には、対象の WEB アプリケーションとを突き合せた設計がとても大切です。
のっけからまとめ的な雰囲気ですが、ここに Laravel で AMP ページを作成する際の一つの実装パターンを紹介します。
<div class="img_wrap"><amp-img layout="responsive" src="/images/posts/46/h4VoJOXuufbctU02jHjT.png" width="1200" height="630" alt="Laravel で AMP ページを作成するロジック図"></div>
この図を基にこれから解説していきます。
<h2 id="css-style開発のロジックについて">CSS, style開発のロジックについて</h2>
まず、スタイル周りについてですが、開発時には SASS で実装し、Webpack でコンパイルを行う流れを推奨します。
ここで一つ補足しておくと、Laravel では SASS などのコンパイルに関して、5.4 以降は Webpack, それ以前では Gulp でのコンパイルを標準で提供しています（厳密に言えば 5.3 以前でも webpack は提供されています）。 API 名称としては
<ul>
<li>5.4 以降 Laravel Mix</li>
<li>5.3 以前 Laravel Elixir</li>
</ul>
という事になります。
本記事ではこれから「webpack でのコンパイル」と記載しますが、どのバージョンであっても、それぞれの API でのプリプロセッサーを使う。という事を指しています。なので、基本的には Laravel5 系であればバージョン関係なく実現は可能です。
それでは本題へ戻ります。図での流れを解説すると、webpack で SASS を CSS にコンパイルする際にいきなり１つのファイルにまとめるのではなく、一度それぞれの SASS ファイルをそれぞれの CSS ファイルにビルドしてから、それを public.css にまとめる。という流れになっています。
こうする事によって、機能・ページ別で CSS を分けられるので、AMP ページに必要なだけのソースをコントローラから取得する事が出来るようになります。
では何故こういった流れにするのか？利点（必要性というべきか）としては、AMP ぺージの CSS に関するルールが関係しています。
AMP ぺージでは、通常ページのように「&#x3C;link rel="stylesheet" href="～">」のようにして CSS ファイルを外部読み込みする事が許可されておらず、head タグ内に「&#x3C;style amp-custom>&#x3C;/style>」として直接記述する必要があり、そしてそれは、50KB 以内という制限があります。
故に、通常ページと同じスタイルを使った場合、50KB の制限をオーバーする可能性があります。（ちなみに bootstrap のコアソースなどは余裕でアウトです）
もちろん制限をオーバーすれば、それは AMP ページとして認められません。
Laravel ではデフォルトの SASS に bootstrap がインクルードされていたりするので、気を付けたいところです。
とはいえ、AMP ぺージの為だけに「そもそも bootstrap は使わない」という選択は違うと思いますので（というか、AMP ページを実装しようと思った時点で既に一通りの通常ページは実装済みの場合が多いので、既に bootstrap を使ってしまっているよ！泣 みたいな事も往々にしてあるでしょう）、bootstrap を使うなら使うで、ビルド時に一度、それぞれの CSS ファイルにビルドしておく事で、AMP ぺージの時には必要なだけの CSS を取得し再構築する事で必要最小限のスタイルを用意できる。という仕組みを構築する事が出来ます。
<h2 id="コントローラのロジックについて">コントローラのロジックについて</h2>
コントローラでは、通常ページと同じロジックで必要なデータの取得をモデルから行うので、基本的には AMP ぺージ用にデータ取得のロジックを変更する必要はありません。
この点に関して突っ込んだ話をすると、<a href="https://webmaster-ja.googleblog.com/2017/11/engaging-users-through-high-quality-amp.html" rel="noopener noreferrer" target="_blank">2017 年 11 月 28 日の Google ウェブマスター向け公式ブログ</a> にて 
「通常ページと AMP ぺージでは同一のコンテンツが配信されるべきである」 
とアナウンスされており、AMP ぺージだから表示内容を制限する。といった考え方は NG となりました。（よくある「続きを読む」みたいな AMP ページは今後淘汰されていくと思われます。）
そういった点からも、モデルからのデータ取得に関しては通常ページと同一でいくべき＝いかに基本ロジックにて通常用と AMP 用の処理が別れないかが大切だと思います。
ちなみに今回のロジックの場合では、
<ul>
<li>通常ページか AMP ぺージかを判定する処理の追加</li>
<li>AMP ぺージの時のみ追加処理を行う処理の追加</li>
</ul>
この２点だけで済む事になります。
<h3 id="通常ページか-amp-かを判定する処理">通常ページか AMP かを判定する処理</h3>
色々な実装方法があると思いますが、一番簡潔にいくのは URL 判定かなと思います。例えば
<ul>
<li>通常ページ： /page</li>
<li>AMP ぺージ： /page.amp</li>
</ul>
とした場合は、簡単な URL の Parse で AMP のリクエストかどうかを判断する事が出来ますので、冒頭で判定して結果を変数に持たせておけば、あとは AMP ぺージか否かで追加処理を実行していけばよいだけになります。
<h3 id="amp-ぺージの時のみ追加処理を行う処理">AMP ぺージの時のみ追加処理を行う処理</h3>
ここについてはまさに、開発する WEB アプリケーションによって様々なパターンがあると思いますが、今回の図に示しているのは 
「モデルから取得したデータに HTML タグやインラインスタイルが含まれるものがある場合」 
を指しています。
つまり、CMS などでユーザによる入力機能を WYSIWYG で構築してる場合などです。ブログシステムや掲示板システムのような場合ですね。
図では「convert HTML source to AMP-HTML 」の部分になります。
ここでは、モデルから受け取ったデータの中の、HTML タグやインラインスタイルが含まれるデータについて、AMP ぺージ用の変換を行うという流れを示しています。
変換の手段としては正規表現がおすすめです。 WYSIWYG などを取り入れている場合には不規則かつ無秩序に HTML タグやスタイルが差し込まれる事も往々にしてあるので、あらゆる書式に対応できる点でおすすめです。
順番はどちらからでも構いませんが、HTML の変換については結構決め打ちで行えるので、まずは HTML タグを AMP ぺージ用に変換してしまうのが良いでしょう。
そして次に、データ内から取り出したスタイルをクラス定義（CSS のクラスです）していき、クラス名に置き換えていきます。
簡単に紹介すると、以下のような変換を行います。
<pre><code class="hljs language-html">&#x3C;p style="AAA:aaa; BBB:bbb;">sample&#x3C;/p>
↓
&#x3C;p class="amp_01">sample&#x3C;/p>
.amp_01 { AAA:aaa; BBB:bbb; }
</code></pre>
全ての置き換えが完了したら、クラス定義した CSS ソースを、必要なものだけ取得した CSS 内に追加する。という流れになります。
これで CSS に関しては、どんなインラインスタイルがあったとしても HTML から除去し、head 内の style amp-custom に乗せ換える事が可能になります。
インラインスタイルの変換に関しては、そのデータにどういったインラインスタイルが存在しているかによって都度行うので、動的にクラス設定を行うようなイメージです。なのでクラス名は機械的なものでよいと思います。（「.a01 」「.a02 」...のような）
先ほど少し触れましたが、CSS に関してはビルドした個別の CSS ファイルから必要なものだけを読み出し、そこにインラインスタイルを変化したスタイル達を追加してあげる事で、その AMP 専用の style amp-custom が完成します。
これで、ビューにデータを渡す直前の時点で必要なデータと CSS が用意できた事になります。
<h2 id="ビューのロジックについて">ビューのロジックについて</h2>
ここも２通りの実装方法があります。ビュー、Laravel ではいわゆる Blade.php を、通常ページと AMP で１つにしてしまう方法と、それぞれを別に分ける方法です。
ビューにどれくらいの記述量があるかにもよりますが、記述量が多いと Blade テンプレートの中で AMP か否かの条件分岐によってあれこれ書くのは結構ごちゃごちゃしてきて見通しが悪くなる（レイアウトで切り出したとしても）場合が多いので、基本的にはビューは分けてしまう方が後々メンテナンスし易いと思います。
個人的には、ビューディレクトリの中に通常用と AMP 用でディレクトリを分けてしまい、共通のコードはレイアウト化しそれぞれで読み込む。といった構造の方が後々メンテナンスしやすいし、冗長にもなりにくいなと思いますが、それももちろんビューのコード量と個人の好みがあるので、規模や好みで決めれば良いと思います。
そして図にもある通り、通常ページの場合は link rel で public/css/public.css を読み込み、AMP の場合は head 内に style amp-custom を設置しその中に生成したスタイルを置く、という流れになります。
この流れを組む事で、通常ページと AMP の場合の重複コードがほぼなくなります。
<h2 id="まとめ">まとめ</h2>
紹介は以上になります。
コントローラの部分で HTML やインラインスタイルを置換する処理を紹介しましたが、通常ページよりも処理が増えるので、処理する量によっては多少オーバーヘッドが発生します。
ですが AMP ページとは、最終的に Goole がキャッシュし、表示してくれるものなので、その辺りの心配はほぼ気にしなくてよいでしょう。（もちろん何事も、やりすぎは良くありません）
Laravel で AMP ページを実装する際には、「どこを AMP 対応させるのか」「現在のアプリケーションのベースロジック」そして「AMP の仕様」をよく確認し、まずは設計を行ってから開発に入る事が大切です。
最後に、2017 年 10 月 8 日(日) に大田区産業プラザ PiO にて開催された「phpcon 2017 」において、株式会社イノベーション 小柳津裕真氏が登壇した <a href="https://speakerdeck.com/yaizuuuu/mobairupeziwobao-su-ni-laraveldeshi-xian-suruampdui-ying-falsezi-dong-hua-number-phpcon2017" rel="noopener noreferrer" target="_blank">「モバイルページを爆速に～ Laravel で実現する AMP 対応の自動化～」</a> のスライドを紹介して終わりにします。
私も会場で拝聴しましたが、ミドルウェアを使って AMP ページを生成するロジックについて話されていたので、本記事を最後まで読んだのであれば是非参考までに目を通すと良いと思います。

昨年頃から段々と話題になってきた AMP(Accelerated Mobile Pages) ページですが、今や実装も当たり前になりつつあるかなと思いつつ、ここで一度、Laravel で AMP ページを作成する際の自分なりのベストプラクティスをまとめようと思います。
というのも、Laravel で AMP ぺージを作成する方法は１つではありません。ミドルウェアで、コントローラでと、処理の流れも含め実装手段はいくつでもあります。
はっきり言ってどの方法が最も優れているというような結論は出ないと思います。そしてそもそも、そういう話ではないと思っています。
大切な事は、開発する WEB アプリケーションによってベストな手法で実装する事です。
ここでいう「ベスト」というのは、実装の手間を少なくするかとかロジックを最短にする事、色々とこねくり回さなくて済むような手法でという意味です。
AMP ページを作成しようとする時点で既に通常のページが出来上がっている事を想定していますが（新規開発時に企画出来ているともちろんベストです）、AMP ページを作成する為にロジックをあれこれと AMP ぺージ用に組むと、機能追加や修正の際に工数が肥大化し、作業が大変になってしまいます。
なので AMP ページを実装する際には、対象の WEB アプリケーションとを突き合せた設計がとても大切です。
のっけからまとめ的な雰囲気ですが、ここに Laravel で AMP ページを作成する際の一つの実装パターンを紹介します。
<div class="img_wrap"><img src="/images/posts/46/h4VoJOXuufbctU02jHjT.png" width="1200" height="630" alt="Laravel で AMP ページを作成するロジック図"></div>
この図を基にこれから解説していきます。
<h2 id="css-style開発のロジックについて">CSS, style開発のロジックについて</h2>
まず、スタイル周りについてですが、開発時には SASS で実装し、Webpack でコンパイルを行う流れを推奨します。
ここで一つ補足しておくと、Laravel では SASS などのコンパイルに関して、5.4 以降は Webpack, それ以前では Gulp でのコンパイルを標準で提供しています（厳密に言えば 5.3 以前でも webpack は提供されています）。 API 名称としては
<ul>
<li>5.4 以降 Laravel Mix</li>
<li>5.3 以前 Laravel Elixir</li>
</ul>
という事になります。
本記事ではこれから「webpack でのコンパイル」と記載しますが、どのバージョンであっても、それぞれの API でのプリプロセッサーを使う。という事を指しています。なので、基本的には Laravel5 系であればバージョン関係なく実現は可能です。
それでは本題へ戻ります。図での流れを解説すると、webpack で SASS を CSS にコンパイルする際にいきなり１つのファイルにまとめるのではなく、一度それぞれの SASS ファイルをそれぞれの CSS ファイルにビルドしてから、それを public.css にまとめる。という流れになっています。
こうする事によって、機能・ページ別で CSS を分けられるので、AMP ページに必要なだけのソースをコントローラから取得する事が出来るようになります。
では何故こういった流れにするのか？利点（必要性というべきか）としては、AMP ぺージの CSS に関するルールが関係しています。
AMP ぺージでは、通常ページのように「&#x3C;link rel="stylesheet" href="～">」のようにして CSS ファイルを外部読み込みする事が許可されておらず、head タグ内に「&#x3C;style amp-custom>&#x3C;/style>」として直接記述する必要があり、そしてそれは、50KB 以内という制限があります。
故に、通常ページと同じスタイルを使った場合、50KB の制限をオーバーする可能性があります。（ちなみに bootstrap のコアソースなどは余裕でアウトです）
もちろん制限をオーバーすれば、それは AMP ページとして認められません。
Laravel ではデフォルトの SASS に bootstrap がインクルードされていたりするので、気を付けたいところです。
とはいえ、AMP ぺージの為だけに「そもそも bootstrap は使わない」という選択は違うと思いますので（というか、AMP ページを実装しようと思った時点で既に一通りの通常ページは実装済みの場合が多いので、既に bootstrap を使ってしまっているよ！泣 みたいな事も往々にしてあるでしょう）、bootstrap を使うなら使うで、ビルド時に一度、それぞれの CSS ファイルにビルドしておく事で、AMP ぺージの時には必要なだけの CSS を取得し再構築する事で必要最小限のスタイルを用意できる。という仕組みを構築する事が出来ます。
<h2 id="コントローラのロジックについて">コントローラのロジックについて</h2>
コントローラでは、通常ページと同じロジックで必要なデータの取得をモデルから行うので、基本的には AMP ぺージ用にデータ取得のロジックを変更する必要はありません。
この点に関して突っ込んだ話をすると、<a href="https://webmaster-ja.googleblog.com/2017/11/engaging-users-through-high-quality-amp.html" rel="noopener noreferrer" target="_blank">2017 年 11 月 28 日の Google ウェブマスター向け公式ブログ</a> にて 
「通常ページと AMP ぺージでは同一のコンテンツが配信されるべきである」 
とアナウンスされており、AMP ぺージだから表示内容を制限する。といった考え方は NG となりました。（よくある「続きを読む」みたいな AMP ページは今後淘汰されていくと思われます。）
そういった点からも、モデルからのデータ取得に関しては通常ページと同一でいくべき＝いかに基本ロジックにて通常用と AMP 用の処理が別れないかが大切だと思います。
ちなみに今回のロジックの場合では、
<ul>
<li>通常ページか AMP ぺージかを判定する処理の追加</li>
<li>AMP ぺージの時のみ追加処理を行う処理の追加</li>
</ul>
この２点だけで済む事になります。
<h3 id="通常ページか-amp-かを判定する処理">通常ページか AMP かを判定する処理</h3>
色々な実装方法があると思いますが、一番簡潔にいくのは URL 判定かなと思います。例えば
<ul>
<li>通常ページ： /page</li>
<li>AMP ぺージ： /page.amp</li>
</ul>
とした場合は、簡単な URL の Parse で AMP のリクエストかどうかを判断する事が出来ますので、冒頭で判定して結果を変数に持たせておけば、あとは AMP ぺージか否かで追加処理を実行していけばよいだけになります。
<h3 id="amp-ぺージの時のみ追加処理を行う処理">AMP ぺージの時のみ追加処理を行う処理</h3>
ここについてはまさに、開発する WEB アプリケーションによって様々なパターンがあると思いますが、今回の図に示しているのは 
「モデルから取得したデータに HTML タグやインラインスタイルが含まれるものがある場合」 
を指しています。
つまり、CMS などでユーザによる入力機能を WYSIWYG で構築してる場合などです。ブログシステムや掲示板システムのような場合ですね。
図では「convert HTML source to AMP-HTML 」の部分になります。
ここでは、モデルから受け取ったデータの中の、HTML タグやインラインスタイルが含まれるデータについて、AMP ぺージ用の変換を行うという流れを示しています。
変換の手段としては正規表現がおすすめです。 WYSIWYG などを取り入れている場合には不規則かつ無秩序に HTML タグやスタイルが差し込まれる事も往々にしてあるので、あらゆる書式に対応できる点でおすすめです。
順番はどちらからでも構いませんが、HTML の変換については結構決め打ちで行えるので、まずは HTML タグを AMP ぺージ用に変換してしまうのが良いでしょう。
そして次に、データ内から取り出したスタイルをクラス定義（CSS のクラスです）していき、クラス名に置き換えていきます。
簡単に紹介すると、以下のような変換を行います。
<pre><code class="hljs language-html">&#x3C;p style="AAA:aaa; BBB:bbb;">sample&#x3C;/p>
↓
&#x3C;p class="amp_01">sample&#x3C;/p>
.amp_01 { AAA:aaa; BBB:bbb; }
</code></pre>
全ての置き換えが完了したら、クラス定義した CSS ソースを、必要なものだけ取得した CSS 内に追加する。という流れになります。
これで CSS に関しては、どんなインラインスタイルがあったとしても HTML から除去し、head 内の style amp-custom に乗せ換える事が可能になります。
インラインスタイルの変換に関しては、そのデータにどういったインラインスタイルが存在しているかによって都度行うので、動的にクラス設定を行うようなイメージです。なのでクラス名は機械的なものでよいと思います。（「.a01 」「.a02 」...のような）
先ほど少し触れましたが、CSS に関してはビルドした個別の CSS ファイルから必要なものだけを読み出し、そこにインラインスタイルを変化したスタイル達を追加してあげる事で、その AMP 専用の style amp-custom が完成します。
これで、ビューにデータを渡す直前の時点で必要なデータと CSS が用意できた事になります。
<h2 id="ビューのロジックについて">ビューのロジックについて</h2>
ここも２通りの実装方法があります。ビュー、Laravel ではいわゆる Blade.php を、通常ページと AMP で１つにしてしまう方法と、それぞれを別に分ける方法です。
ビューにどれくらいの記述量があるかにもよりますが、記述量が多いと Blade テンプレートの中で AMP か否かの条件分岐によってあれこれ書くのは結構ごちゃごちゃしてきて見通しが悪くなる（レイアウトで切り出したとしても）場合が多いので、基本的にはビューは分けてしまう方が後々メンテナンスし易いと思います。
個人的には、ビューディレクトリの中に通常用と AMP 用でディレクトリを分けてしまい、共通のコードはレイアウト化しそれぞれで読み込む。といった構造の方が後々メンテナンスしやすいし、冗長にもなりにくいなと思いますが、それももちろんビューのコード量と個人の好みがあるので、規模や好みで決めれば良いと思います。
そして図にもある通り、通常ページの場合は link rel で public/css/public.css を読み込み、AMP の場合は head 内に style amp-custom を設置しその中に生成したスタイルを置く、という流れになります。
この流れを組む事で、通常ページと AMP の場合の重複コードがほぼなくなります。
<h2 id="まとめ">まとめ</h2>
紹介は以上になります。
コントローラの部分で HTML やインラインスタイルを置換する処理を紹介しましたが、通常ページよりも処理が増えるので、処理する量によっては多少オーバーヘッドが発生します。
ですが AMP ページとは、最終的に Goole がキャッシュし、表示してくれるものなので、その辺りの心配はほぼ気にしなくてよいでしょう。（もちろん何事も、やりすぎは良くありません）
Laravel で AMP ページを実装する際には、「どこを AMP 対応させるのか」「現在のアプリケーションのベースロジック」そして「AMP の仕様」をよく確認し、まずは設計を行ってから開発に入る事が大切です。
最後に、2017 年 10 月 8 日(日) に大田区産業プラザ PiO にて開催された「phpcon 2017 」において、株式会社イノベーション 小柳津裕真氏が登壇した <a href="https://speakerdeck.com/yaizuuuu/mobairupeziwobao-su-ni-laraveldeshi-xian-suruampdui-ying-falsezi-dong-hua-number-phpcon2017" rel="noopener noreferrer" target="_blank">「モバイルページを爆速に～ Laravel で実現する AMP 対応の自動化～」</a> のスライドを紹介して終わりにします。
私も会場で拝聴しましたが、ミドルウェアを使って AMP ページを生成するロジックについて話されていたので、本記事を最後まで読んだのであれば是非参考までに目を通すと良いと思います。

Author