文責
新規プロダクト開発部の伊勢（ id:hayatoise ）です。
新規プロダクト開発部は一休の新規事業の開発とデザインを担当する部署です。現在、新規プロダクト開発部は主に『一休.comスパ』、『一休コンシェルジュ』および『KIWAMINO』を担当しています。
はじめに
エグゼクティブや秘書の方々が会食先を探す際のお悩みを解消するためのオウンドメディア『KIWAMINO』をローンチしました。
『KIWAMINO』は WordPress をベースに Canonical AMP サイトにしました。AMP とは、ウェブ高速化のための HTML フレームワークです。そして、Canonical AMP サイトとは、全てのページが AMP で構成されているサイトのことです。
企業が運営しているサイトで WordPress + AMP plugin でカノニカル AMP サイトを作る時代になったんですねぇ。素晴らしい。 https://t.co/BnjRYROiLy
— 金谷 武明 (@jumpingknee) July 23, 2019
こちらのツイートから分かる通り、WordPress と Google が提供する AMP プラグイン（以下、AMP プラグイン）で Canonical AMP サイトを構成することはまだ事例としては少ないようです。
そこで、『KIWAMINO』をどうやって構築したのか紹介します。加えて、なぜ WordPress と AMP プラグインで Canonical AMP サイトを構成したのかについても説明します。
『KIWAMINO』をどうやって構築したのか
さくらの VPS 上に Docker で Nginx、WordPress ( PHP-FPM ) および MariaDB のコンテナを作成しました。そして、AMP プラグインで Canonical AMP サイトにしました。CDN は Fastly と imgIX を導入しています。
WordPress と AMP プラグインで Canonical AMP サイトを構成した方法
WordPress の構築もさることながら AMP プラグインで Canonical AMP サイトにすることもカンタンです。
まず WordPress を構築し、Twenty Ten 以降 Twenty Nineteen までのコアテーマを有効にします。そして、AMP プラグインも有効にします。
AMP プラグインの設定画面の Experiences 項目の Website にチェックを入れます。次に、Website Mode 項目を Standard にすると Canonical AMP サイトになります。以上です。
前述した通り、AMP HTML を書く必要はありません。AMP プラグインが HTML を自動で変換するからです。
<img src="https://resq.img-ikyu.com/asset/image/about/bn_about.png" alt="KIWAMINOについて" >
例えば、img タグを記述すると...
<amp-img src="https://resq.img-ikyu.com/asset/image/about/sd_bn_about.png" alt="KIWAMINOについて" width="640" height="400" class="amp-wp-unknown-size amp-wp-unknown-width amp-wp-unknown-height amp-wp-enforced-sizes i-amphtml-element i-amphtml-layout-intrinsic i-amphtml-layout-size-defined i-amphtml-layout" layout="intrinsic" i-amphtml-layout="intrinsic"> <i-amphtml-sizer class="i-amphtml-sizer"> <img alt="" role="presentation" aria-hidden="true" class="i-amphtml-intrinsic-sizer" src="data:image/svg+xml;charset=utf-8,<svg height="400px" width="640px" xmlns="http://www.w3.org/2000/svg" version="1.1"/>"> </i-amphtml-sizer> <noscript> <img src="https://resq.img-ikyu.com/asset/image/about/sd_bn_about.png" alt="KIWAMINOについて" width="640" height="400" class="amp-wp-unknown-size amp-wp-unknown-width amp-wp-unknown-height"> </noscript> <img decoding="async" alt="KIWAMINOについて" src="https://resq.img-ikyu.com/asset/image/about/sd_bn_about.png" class="i-amphtml-fill-content i-amphtml-replaced-content"> </amp-img>
表示する際は上記のような AMP HTML に自動で変換されます。
AMP プラグインの設定画面の Experiences 項目の Stories にチェックを入れると、開発コストを掛けることなく記事と同様に WYSIWYG で AMP Stories を作成することが可能になります。
インフラ
- さくらの VPS（ 2G プラン ）
- Fastly
- imgIX（ 画像に特化した CDN です。詳しくはこちら ）
ミドルウェア
- Docker
- Nginx
- PHP-FPM
- MariaDB
さくらの VPS 上に WordPress を構築せず、Docker を使用した理由は同じ環境を構築しやすいからです。
もう一つのオウンドメディア『一休コンシェルジュ』はローカル、ステージングおよびプロダクション環境が揃っておらず、ステージング環境でテストしたのにも関わらず何度か事故を起こしてしまいました。
この経験から各環境を統一することが比較的容易な Docker を採用しました。
WordPress
- WordPress Core（ 常に最新版を使用 ）
- AMP（ HTML を AMP HTML に自動で変換 ）
- Fastly（ コンテンツの投稿、更新および削除を検知して自動でキャッシュをパージ ）
- Media Cloud（ S3 と imgIX の設定と連携を一括で可能に ）
- Yoast SEO（ SEO 関連の設定を最適化 ）
- Glue for Yoast SEO & AMP（ Yoast SEO の AMP 対応版 ）
- WP Pusher（ 任意のブランチへのマージを検知して自動で差分をデプロイ ）
WordPress Core のメジャーバージョンを除いて、全てのアップデートを自動に設定しています。
Lighthouse
修正できる点はいくつか残っていますが、Lighthouse の Performance スコアは常に 99 前後です。
なぜ WordPress と AMP プラグインで Canonical AMP サイトを構成したのか
WordPress と AMP プラグインで Canonical AMP サイトを構成した理由は以下の 3 つです。
(1) AMP の制約によって、サイトスピードが速くなるから
(2) エンジニア・デザイナーの学習および開発コストが低いから
(3) 巨大な組織・コミュニティの恩恵を受けられるから
(1) AMP の制約によって、サイトスピードが速くなるから
AMP の制約上、CSS および JavaScript のファイルサイズは軽くせざるを得ないので、それらがサイトスピードを必然的に妨げることがなくなります。
AMP は CSS の総量を 50 KB 以下にしなければなりません。また、JavaScript に関しては AMP が提供する公式のコンポーネントしか使えません。
したがって、CSS および JavaScript ファイルは必然的に軽量化されます。その結果、半強制的にサイトスピードを保つことができます。
(2) エンジニア・デザイナーの学習および開発コストが低いから
AMP プラグインが HTML を AMP HTML に自動で変換するため、デザイナーの学習コストは殆ど掛かりません。さらに Canonical AMP サイトにすると通常ページと AMP ページの二重管理がなくなるので、開発コストも低下します。
(3) 巨大な組織・コミュニティの恩恵を受けられるから
インターネット上の約 3 分の 1 のサイトは WordPress で動いているので、情報が沢山あります。かゆいところに手が届かないこともありますが、基本的に検索すれば大抵の技術的問題を解決することができます。したがって、エンジニアであれば誰でも担当できると思います。
当然、外注する場合も候補になり得る人材が沢山いるので、依頼しやすいかと思います。プラグインも豊富なので、その気になれば非エンジニアが新機能を追加してみることも可能です。
オウンドメディアを運営する上で欲しいと感じる機能は全てプラグインとして提供されていると言っても過言ではありません。巨大なコミュニティの元だからこそ得られるメリットが多々あります。
大半のオウンドメディアは Google 経由のトラフィックに依存しているかと思います。その良し悪しは別として AMP を採用することで、Google 経由の多くのユーザの体験が良くなります。その結果、それが SEO 対策になり、流入数の向上も見込めます。
さらに、AMP の制約を守り続けることでサイトスピードが維持されるため、サイト全体の離脱率も高まりにくいです。AMP 提供元の Google がプラグインを開発しているので、安心してプラグインに頼ることができます。サイトを放置しても自動でアップデートされるので、細かい仕様変更でエンジニアの手を借りる必要がなくなります。
おわりに
『KIWAMINO』は WordPress と AMP プラグインで Canonical AMP サイトにしました。WordPress と Canonical AMP を採用した理由は 3 つです。
(1) AMP の制約によって、サイトスピードが速くなるから
(2) エンジニア・デザイナーの学習および開発コストが低いから
(3) 巨大な組織・コミュニティの恩恵を受けられるから
以下、実際に運用してみた結果です。
(1) 数ヶ月間、実運用しましたが、問題なくサイトスピードは保たれています。少し困っていることは AMP プラグインが新しい JavaScript ファイルを検知した際、管理画面でそのファイルを許可するまで AMP が無効になることです。それ以外は特に困っていません。
(2) 予想通り、エンジニア・デザイナーの学習および開発コストは低かったです。
『KIWAMINO』のデザインを担当した方に技術ブログに掲載することは伝えず、Slack の DM で質問しました。
hayatoise「AMP HTML は一切書いたことがなかったという認識で OK ですね?!」
designer「YES! でも今も書いてる認識はないですけどね〜うふふ」
AMP プラグインは HTML を AMP HTML に自動で変換してくれます。なので、デザイナーの方は一切 AMP HTML を書く必要がないです。HTML と CSS の知識だけでコーディングが可能です。本人も一切書いてる認識はないようです。新しい技術を採用しましたが、デザイナーの学習および開発コストは殆ど高まっていません。
また、エンジニアの学習および開発コストも殆ど高まっていません。一度、AMP プラグインと他のプラグインが競合し、AMP エラーが発生しました。しかし、WordPress に関する情報量が多かったため、あまり詰まること無く問題を解決できました。オウンドメディアを開発する程度だと、AMP の学習コストは殆ど必要ないことも分かりました。
(3) 前述した通り、WordPress に関する情報量は非常に多いです。大抵の問題の解決方法は検索すれば見つかります。今のところ、あまり詰まったことはありません。
また、ちょっと機能を試したい時、WordPress プラグインに頼れることは非常に有り難いです。例えば、記事内でアンケートを取りたいと言われた場合、それを可能とするプラグインが存在するので、インストールするだけでビジネスサイドに提供できます。
結論、WordPress, Twenty Nineteen & AMP Plugin で Canonical AMP サイトは良いぞ
