North Detail / ノースディテール

BLOG ブログ

ブログ
CATEGORY
TECH

そろそろ⚡AMPを理解しておこう

⚡AMP (アクセラレイティッド・モバイル・ページ)とは

GoogleやTwitterなど30社あまりが一緒に行っている『モバイルページのロード時間を短縮(加速)させる』というプロジェクトです。
ザックリ説明すると『AMP HTML』という 独自フレームワーク を使用して構築します。
構築ルール(仕様)はかなり面倒な印象ですが、最初からAMP構築前提であれば、基本的には普通のhtmlコーディングと違いはありません。
逆に言うと既存サイトをAMPに適用させるとなると、そのサイトの特性にもよりますが、結構厄介な作業になると思います。(特にデザイン面)
どのような恩恵があるかというと、スマホ閲覧時に異様なほど速く表示されます。
それこそ正に⚡の如きです。

そして⚡になるためには、画面単体で AMPガイドライン (仕様)に準拠している必要があります。
それと GoogleのCDNにキャッシュされる ことが前提になります。

⚡AMP 最大のメリット(個人的見解です)

表示速度が爆発的に速くなるということは、MFI ※1 の観点からのみならず SEO的に相当有利になります。
今SEO業界を騒がせている Web Vitals ※2 にも当然有利ですし、無条件で Google Discover ※3 (Google砲のことね)に大きなサムネイル画像で掲載されます。

  1. モバイル・ファースト・インデックスの略で、Google はPCサイトではなく、モバイルサイトを評価し検索順位を判断しますって意味
    • 2020年9月(予定)からは100% MFI に移行(公式発表済み)
    • MFI 移行後、PCサイトは一切評価対象から外れます
  2. Webサイトにおけるユーザー体験向上を目指して Google が先日導入した指標
    • ページの表示速度
    • ユーザー操作への反応性
    • 視覚要素の安定性
  3. 検索履歴や位置情報などのデータを基に、ユーザーの興味あるコンテンツを自動的に表示してくれる機能
    • Android・iOS端末の Googleアプリや Google.com で、検索窓直下に表示
    • 1年間で8億人以上のユーザーがDiscover経由でコンテンツにアクセス
    • 新たな流入経路として業界が注目

⚡ AMP構築ガイドライン(の一部)

  • <html ⚡ lang="ja"> もしくは <html amp lang="ja"> @必須
  • <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1"> @必須
  • metaタグ http-equiv とかは使えない
  • <link rel="canonical" href="ほにゃらら"> @必須
  • 外部スタイルシートは使えない
    • head内にamp-custom属性付与で inline記述
    • !important は使えない …マジっす
    • 上限75kbまで …マジっす(2020年2月ごろまでは上限50kbでした><)
    • amp-接頭辞にstyleは充てられない …目もあてられない
  • <script async src="https://cdn.ampproject.org/v0.js"></script> @必須

このような『決まり事』が結構あります。
テンプレートとして割り切れば、どうということはありません…無問題です…おそらく…たぶん。

⚡AMP における javascript の扱いについて

2016年にAMPが発表された頃は 外部 javascript は一切使用できません! が大前提でした。
静的構築サイトでも jQuery などの使用が全盛期だった頃なので、余計に眼を疑いたくなるような衝撃を受けた記憶があります。
それを補うものとして、動的処理などを実装するために AMPコンポーネント なるものが用意されています。
AMP発表当初はスッカスカで「AMPってナニもできないんじゃね?」ってレベルだったものが、日に日に猛烈な勢いで、その質、数ともに増やしていき、ある程度のギミックなどはコンポーネントを使用することで手軽に実装可能となりました。
そして、とうとう2019年8月に試験的に一部公開されていた amp-script が、正式リリースされました。

amp-script というのは、早い話が 外部 javascript です!
まぁ当然の如く、好き放題使用できるはずもなく…下記のような制限があります。

  • 外部 javascript は https で読み込むことが必須
  • ファイルサイズは 150kb 以内(150kb を超えた場合は実行されない…恐ろしや)
  • ユーザーの操作なしに DOM 変更不可(例えば画面表示時にjs実行など)
  • ユーザーアクションから javascript 実行完了まで5秒以内に収める必要がある

今現在は大量にコンポーネントが揃っていますから、それでも補えない実装が必要な場合に amp-script を使用すればよいですね。
と、これのおかげで ReactAngular Vue.js といったライブラリやフレームワークを利用して実装することも可能になったということになります。

⚡AMP における画像表示の扱いについて

まず前提として AMP構築する場合、画像を表示するのに独自タグを使用することが必須になります。
それが amp-img です。

では pictureタグのようにフォールバックが必要な場合はどうすればよいのでしょうか?
ようするにレガシーブラウザでは非対応の WebP とかを使いたい場合はどうするの?って話です。
つい最近とうとう Safari も「WebP を正式にサポートする@Ver.14」と発表したことですし、純粋に画像ファイルサイズが 20~30%軽減するというのは、SEO の観点からも非常に大きいので…まさに
これからの時代 使わない理由が見当たらない 画像フォーマットですね。

で、イロイロと探してみた結果…普通に AMP公式リファレンスにやり方が書いてありました…
結論 amp-img タグの入れ子 って…
※下記で普通に WebP 対応していないブラウザは jpg 表示

<amp-img alt="shibakichi"
  width="550"
  height="368"
  src="img/shibakichi.webp">
  <amp-img alt="shibakichi"
    fallback
    width="550"
    height="368"
    src="img/shibakichi.jpg"></amp-img>
</amp-img>

⚡AMP キャッシュの更新プロセス

AMP キャッシュの更新は、ユーザーにキャッシュを配信したときにオリジナルのコンテンツが更新されていれば、更新されたコンテンツを AMP CDN サーバー が自動で取得しキャッシュし直す仕組みになっています。
※ただし新しいキャッシュが配信されるのは、その次のユーザーに対してです

  1. ユーザーがアクセスすると、オリジナルのページが更新していないかを自動的にチェック
  2. 更新していればキャッシュも更新し、次のユーザーには更新したコンテンツをキャッシュから返す
  3. オリジナルのページが返すヘッダー、たとえば Max-Age を見て更新しているかどうかを判断する
  4. オリジナルのコンテンツに更新がなければ、キャッシュも更新せずそのまま使い続ける

なおサーバーに負荷をかけないために、HTMLドキュメントに対しては最低でも15秒以上の間隔を空けてリクエストします。
画像やリソースに対しては最低でも1分以上の間隔を空けてリクエストします(間隔は将来変更される可能性あり)。

CDN にキャッシュされていることを確認する方法

まずお好きなブラウザを立ち上げて、上の方にある URL が表示されている部分に、調べたいページのキャッシュURL を入れてエンターキーを押し、ampproject.org ドメイン の URL で画面が表示されていればキャッシュされていることとなります。
キャッシュURL は、確認したい画面 URL(http:(s)//は除く)の前に、確認するサイトが https の場合は https://cdn.ampproject.org/c/s/ を、確認するサイトが http の場合は https://cdn.ampproject.org/c/ を入れればOKです。
例) https://cdn.ampproject.org/c/s/ampwa.herokuapp.com/

⚡要チェックサイト&便利サイト

Accelerated Mobile Pages Project - AMP

Learn AMP by Example

AMPコンポーネント一覧

AMP validator

AMPテスト

まとめ

そうそうたる企業が参加しているプロジェクトの割には、実際に html5 やら、レスポンシブウェブデザインやら、Flash 絶滅運動などの時に比べると浸透力が少ないように思います。
さらに SEO 的なメリットが多大にあるのに何故でしょう?

Google は兎にも角にも『表示速度改善』に強烈にチカラを入れています。
AMP に対しても相当有利になる特典を付与してます。
でも結局、制作者・クライアントともに『サイト特性との不一致』だったり『デザイン性・インタラクティブな操作性追求』の方が優先順位が高いということなのでしょうね。
そういう面にあまり気をかけなくてよいサイト(例えばニュースサイトだったり、ブログサイトだったり)が、イの一番に実装に踏み切ったのはそういう流れなのかもしれません。
ただ流行り廃りでポっと出てきた技術ではないですし、特性にハマりさえすれば明らかに必要になる技術ですので、これからも AMP 自体にアンテナを張っておきたいと思います。
個人的意見ですが、ダイナミックサービングなどと組み合わせることで、本当の意味でのモバイルファーストを実現できるのではないか考えております( ̄^ ̄)ゞ

nanba
WRITER:nanba
高い技術力を誇る『NorthDetail』内では珍しい『チカラワザ系コーダー』
主な記事 一覧へ

一覧へ

IS 501383 / ISO 27001