GoogleのAcceleratedMobilePagesについて知っておくべきことすべて

公開: 2022-03-10

クイックサマリー↬ 2015年5月、Facebookは新しいアプリ内パブリッシングプラットフォームであるInstantArticlesを発表しました。 1か月後、Appleは、古いNewsstandエクスペリエンス（基本的にはニュースアプリでいっぱいの豪華なフォルダー）がiOS9でAppleNewsと呼ばれる新しいニュースアグリゲーションおよびディスカバリープラットフォームに置き換えられることを宣言しました。 4か月後、Googleは、Accelerated Mobile Pages（AMP）と呼ばれるオープンソースのウェブベースのソリューションでモバイルニュースの消費に革命を起こす独自の、やや遅れているが野心的な計画を発表する番でした。 Facebook、Apple、そして今やGoogleが出版社の忠誠心と読者の注目の両方を求めて競争する中、わずか数か月で、モバイルデジタルパブリッシングの相対的な静けさがさらに別の本格的なプラットフォーム戦争に突入するのを見てきました。

2015年5月、Facebookは新しいアプリ内パブリッシングプラットフォームであるInstantArticlesを発表しました。 1か月後、Appleは、古いNewsstandエクスペリエンス（基本的にはニュースアプリでいっぱいの豪華なフォルダー）がiOS9でAppleNewsと呼ばれる新しいニュースアグリゲーションおよびディスカバリープラットフォームに置き換えられることを宣言しました。

スマッシングに関するさらなる読み物：

知覚されるパフォーマンス
プリロード：それは何のために良いですか？
HTTP / 2の準備
プログレッシブエンハンスメント
プログレッシブウェブAMP

4か月後、Googleは、Accelerated Mobile Pages（AMP）と呼ばれるオープンソースのウェブベースのソリューションでモバイルニュースの消費に革命を起こす独自の、やや遅れているが野心的な計画を発表する番でした。 Facebook、Apple、そして今やGoogleが出版社の忠誠心と読者の注目の両方を求めて競争する中、わずか数か月で、モバイルデジタルパブリッシングの相対的な静けさがさらに別の本格的なプラットフォーム戦争に突入するのを見てきました。

FacebookとAppleはGoogleでかなり有利なスタートを切っていますが、AMPがすぐに追いつくと信じる理由はたくさんあります（そして、競合他社の一方または両方を超える可能性さえあります）。 GoogleのAcceleratedMobile Pagesの理由、内容、方法を可能な限り迅速かつ効率的に把握する必要がある開発者またはサイト運営者であれば、適切な場所にいます。

ジャンプした後もっと！以下を読み続けてください↓

しかし、問題は何ですか？

解決策について説明する前に、少し時間を取って問題を調査する価値があります。モバイルデバイスで多くの読書をしている場合、携帯電話やタブレットでWebベースのコンテンツを操作することは、ほとんど受け入れられないものから恐ろしいものまでさまざまであることをすでに十分に認識している可能性があります。多くの場合、ページの読み込みが遅く、レンダリングが不規則になり、次の2つの主な理由で予期しない動作をします。

サードパーティの干渉。広告と関連する追跡技術は、すでに帯域幅とCPUに制約のあるデバイスに大量の追加のリクエストを追加するだけでなく、ページが複数のdocument.write()呼び出しをめちゃくちゃにするため、所有されているかのように動作することがよくあります。 New York Timesは最近、iOSコンテンツブロッカーのインストール後にページサイズの大幅な減少とバッテリー寿命の増加を示すテストを行いました。
レスポンシブデザインによる巻き添え被害。ほとんどのレスポンシブデザインのWebサイトは、あらゆるサイズの画面で見栄えがしますが、モバイルで表示すると、デスクトップWebサイトの手荷物が多く含まれていることがよくあります。 Paul IrishがRedditのパフォーマンス監査を行ったとき、彼はオーバーヘッドの大部分がSnooIconと呼ばれるアセットにまでさかのぼることができることを発見しました。マウスオーバー時のオーバーヘッドが増える）—アセットがモバイルデバイス上で頻繁に見られる状況ではありません。

Facebook Instant Articles、Apple News、Accelerated Mobile Pagesを入力してください。Facebook（PDF、3.4 MB）によると、モバイルデバイスでの記事の平均読み込み時間は8秒です。 8秒を永遠と呼ぶことは明らかに誇張ですが、その時間内に2番目のVineビデオにうまく入る可能性があることを考えると、今日の基準では、それは少なくとも1年であると言っても過言ではありません。

Facebook Instant Articles、Apple News、Accelerated MobilePagesの短いデモ。 Facebook InstantArticlesとAppleNewsはアプリ内エクスペリエンスですが、AMPは完全にブラウザーベースであることに注意してください。

AMPはどう違うのですか？

AMPがFacebookInstantArticlesやAppleNewsとどのように異なるかについてのいくつかのコンテキストは、Googleが新しいデジタルパブリッシングイニシアチブのために行った決定のいくつかをより明確にするでしょう。

Facebook InstantArticlesとAppleNewsには、いくつかの共通の特徴があります。

アプリ内エクスペリエンス。読者はモバイルデバイスでFacebookを介してFacebookInstantArticlesにアクセスします。AppleNewsはiOS9に付属するスタンドアロンアプリです。どちらのプラットフォームでも、現在、ユーザーはそれぞれのアプリの外部で特定の形式の記事を表示できません。両方をRSSのアプリケーション固有の更新と考えてください。
シンジケーション主導。 Facebook InstantArticlesとAppleNewsは非常に異なるシンジケーション形式を使用しますが（Apple News FormatはJSONベースであり、Instant Article Markupは多かれ少なかれRSSフィードにラップされたHTMLです）、これらは同様の原則に基づいています。必要なシンジケーション形式。FacebookまたはAppleNewsは、カスタマイズおよび最適化されたレンダラーを使用して、それを丸呑みにし、解析し、美しく高速にします。
経験志向。 Facebook InstantArticlesとAppleNewsはどちらもパフォーマンスに重点を置いていますが、記事の見た目と雰囲気を現代的にすることにも同様に関心があります。どちらのプラットフォームにも、私たちが通常、オーダーメイドの手作りの読書体験に関連付ける滑らかでスムーズな相互作用を可能にするコンポーネントがあります。

対照的に、Accelerated MobilePagesには明確な焦点があります。

Webベースのエクスペリエンス。 AMPドキュメントは、ブラウザまたはWebViewのいずれかでレンダリングされるように設計されています。
アトミックドキュメント。 AMPドキュメントは、AMPランタイムによって検証、解析、および部分的にレンダリングされますが（以下でさらに詳しく説明します）、これらは、のコレクションではなく、独自のWebサーバー（およびオプションでCDNキャッシュ）に存在する完全で独立したドキュメントです。ある時点で記事に変換され、アプリでレンダリングされるメタデータ。
パフォーマンス指向。 AMPは、美学や相互作用パターンよりも、AMPドキュメントのパフォーマンスをはるかに重視しています。 AMPドキュメントが本質的に家庭的なものであるとは限りません（適切なスタイルのFacebook InstantArticlesやAppleNews Articlesと同じくらい魅力的です）が、ランタイムは、次のような派手な視覚効果を提供するよりも、記事をすばやくレンダリングすることに関心があります。クレイジーな小さなジグザグなもの。

AMPとは正確には何ですか？

十分な哲学と高レベルの手振り。詳細を見てみましょう。 Facebook InstantArticlesとAppleNewsに頭を悩ませるのは非常に簡単ですが（これらは本質的に、独自のシンジケーション形式の上に構築されたカスタムレンダラーを備えた派手なニュースアグリゲーターです）、AMPは外れ値です。 2つの理由から、把握するのは少し難しいです。

比較するための単純なモデルはありません。 RSSが新しくなったとき、私たちは皆その力に驚嘆し、その破壊的な可能性について無数の記事やブログ投稿を書き、ホームページが死んだと宣言し（そして再び）、それからそれをすべて忘れ始めました。 Facebook InstantArticlesとAppleNewsは本質的にRSSの再起動ですが、標準の不便さをすべて解消し、それぞれがたまたま1つのアプリケーションでしか機能しない点が異なります。
AMPはクライアントではありません。 。 Facebook Instant Articles、Apple News、およびAMPには、独自のシンジケーション形式やカスタムレンダラーなど、いくつかの共通の要素がありますが、専用のクライアント（ブラウザー以外）がないのはAMPだけです。 AMPは、同業者よりも、それ自体がエンドツーエンド（発行者から読者）のソリューションではなく、ソリューションに組み合わせることができる一連の仕様、規則、およびテクノロジーです。

AMPを完全に焼き上げたケーキではなく、材料のコレクションと考えることがわかったので、これらの個々のコンポーネントが何であるかを見てみましょう。

AMP HTML、
AMPランタイム、
AMPキャッシュ。

AMP HTML

AMPドキュメントはHTMLで記述されていますが、HTMLだけではありません。一部のタグは禁止されていますが、いくつかの新しいタグが導入されています（一部は禁止されたタグを置き換え、一部はインタラクティブ機能をカプセル化するため）。 AMP HTMLは、モバイルパフォーマンスのみを念頭に置いて設計された場合のHTMLのように考えることができます（iPhoneが導入される14年前に導入されたのとは対照的です）。

AMP HTMLは最適なパフォーマンスを実現するように設計されているため、その価値を理解して評価するには、AMPHTMLが解決する問題を理解する必要があります。モバイルデバイスでのWebページの読み込みとレンダリングを損なう3つの最大の要因は次のとおりです。

ペイロードサイズ。レスポンシブウェブデザインは、デバイスごとに1つのウェブサイトを構築し、そこにスクリーンを表示できるため、非常に役立ちました。ただし、これは、デスクトップサイズのペイロード（HTML、JavaScript、CSS、およびアセット）を帯域幅とCPUに非常に制約のあるモバイルデバイスに配信することも意味します。（自分の携帯電話を小さなデスクトップコンピュータと考える人は、モバイルハードウェアにあまりにも多くの信用を与えています。iPhone6sには2 GBのRAMがありますが、ラップトップにはおそらく8または16があります。）
リソースの読み込み。リソースは常に最適な順序で読み込まれるとは限りません。つまり、帯域幅、CPU、RAMは、ユーザーには決して表示されない可能性のあるアセット専用であることがよくあります。さらに、リソースは幅と高さを宣言しないことがよくあります（特に、広告ネットワークを介して提供される場合、またはdocument.write()呼び出しを介して挿入される場合）。これにより、リソースのディメンションが遅延して決定されるため、ページのサイズが変更されるだけでなく、不要なトリガーも発生します。高価なレイアウトの再計算。それが、ウェブページがレーザーを追いかける子猫のように飛び回る原因です。
JavaScriptの実行。ここでJavaScriptのパフォーマンスのトピックを取り上げるつもりはありませんが、最近のWebサイトでは、JavaScriptのパフォーマンスがメガバイト単位で積み重なることがよくあります。デスクトップコンピューターでは識別可能な遅延なしで実行される可能性がありますが、モバイルは依然として非常に異なる環境であると思います。 JavaScriptは最小限に抑えるのが最善です。

モバイルデバイスでの流動的なWebエクスペリエンスに対するこれらの3つの障壁を考えると、AMPHTMLは主に次の3つの目的で存在します。

簡潔さを奨励します。 AMPドキュメントは、デスクトップWebサイトのレスポンシブバージョンではありません。 AMPドキュメントはレスポンシブである可能性がありますが（通常はレスポンシブです）、モバイルコンテキストではレスポンシブです。つまり、AMPドキュメントは、1つのページがどこでも（デスクトップとモバイルで）完全に機能するのではなく、モバイルデバイス間で適切に機能するように特別に設計されています。
外部リソースの読み込みを制御します。 AMPランタイムは、外部リソースのロードを制御して、プロセスが非常に効率的になるようにし、ユーザーの画面に可能な限り迅速かつインテリジェントにコンテンツが表示されるようにします。
インタラクティブ機能をカプセル化します。 AMPドキュメントは、読者に簡単な読書体験を提供するというビジネスに直結する傾向がありますが、それは、それらが現代的でインタラクティブであることができないという意味ではありません。 AMPランタイムは、高度に最適化されたJavaScriptを介してカプセル化された機能を提供するため、開発者は独自に作成することでパフォーマンスを妨げるリスクを回避できます。

AMPHTMLタグ

以下は、AMPHTMLで全面的に禁止されているタグのリストです。

scriptこれは明らかに大きなものです。 JavaScriptでのAMPの位置については、以下で詳しく説明します。今のところ、AMPドキュメントに含まれるスクリプトタグは、AMPランタイムをロードするscriptタグと、オプションでJSONベースのリンクトデータのタグだけであると想定してください。
base baseタグは、十分な注意を払って禁止されているようであり、コミュニティからの苦情があった場合、ホワイトリストに登録される可能性があります。（私の推測では、誰も実際にはどちらの方法も気にしません。）
frameとframesetとにかくモバイル不動産の良い使い方ではないので、良い馬鹿げています。
object 、 param 、 applet 、 embed残念ながら、AMPドキュメントにはFlashまたはJavaアプレットが含まれていません。（それが完全に明白でなかった場合に備えて、それは皮肉でした。）
form要素とinput要素（ buttonタグを除く）フォームのサポートは、スクリプトなしでは使用が制限されているため、最終的にはカプセル化されたコンポーネントとして実装される可能性があります。

次に、リソースの読み込みを最適化し、セキュリティのベストプラクティスを適用するために、対応するHTMLを置き換えるタグのリストを示します。

[amp-img](https://www.ampproject.org/docs/reference/amp-img.html)ビューポートの位置、システムリソース、接続性などの要素を考慮して、 imgタグを置き換え、リソースの読み込みを最適化します。
[amp-video](https://www.ampproject.org/docs/reference/amp-video.html) HTML5 videoタグを置き換えて、ビデオコンテンツを遅延ロードできるようにします（ビューポートを考慮に入れて）。
[amp-audio](https://www.ampproject.org/docs/reference/extended/amp-audio.html)オーディオコンテンツを遅延ロードできるように（ビューポートを考慮して）、HTML5 audioタグを置き換えます。
[amp-iframe](https://www.ampproject.org/docs/reference/extended/amp-iframe.html) amp-iframeタグは、デフォルトでコンテンツのサンドボックス化や制限の適用などを行うことで、セキュリティのベストプラクティスを実施します。ここで、iframeは、AMPドキュメントを支配しないように表示される場合があります。

最後に、JavaScriptを記述しなくても、ドキュメントに機能や双方向性を追加するためにAMPHTMLが導入するすべてのタグを次に示します。

[amp-ad](https://www.ampproject.org/docs/reference/amp-ad.html) amp-adタグを使用すると、AMPランタイムは、他のすべての外部ロードリソースと同じように、広告のロードを管理できます（現在、広告は最後に読み込まれます）。これにより、広告ネットワークからのJavaScriptが親AMPドキュメント内で実行されたり、不要なレイアウト計算がトリガーされたりすることがなくなります。（さようなら、 document.write() ！）
[amp-analytics](https://www.ampproject.org/docs/reference/extended/amp-analytics.html)このミニチュアフレームワークは、分析データをパッケージ化し、サードパーティプロバイダーに送信します。現在、AMPのサポートは、Adobe Analytics、Chartbeat、ClickTale、comScore、Google Analytics、Nielsen、Parse.lyから提供されています。
[amp-pixel](https://www.ampproject.org/docs/reference/amp-pixel.html)これは、Webビーコンの埋め込みに使用され、サーバーに複数のクライアント変数を送信するためのトークンをサポートします。
[amp-carousel](https://www.ampproject.org/docs/reference/extended/amp-carousel.html)この最適化されたコンポーネントは、子画像をインタラクティブな水平方向に表示します。
[amp-lightbox](https://www.ampproject.org/docs/reference/extended/amp-lightbox.html)これにより、読者は全画面の「ライトボックス」ビューで画像を開くことができます。サムネイル画像とフルサイズ画像の両方の指定をサポートします。
[amp-anim](https://www.ampproject.org/docs/reference/extended/amp-anim.html)これは、アニメーションGIFをロードし、非常に必要なプレースホルダー機能を提供します。
[amp-font](https://www.ampproject.org/docs/reference/extended/amp-font.html)カスタムフォントの読み込みタイムアウトを設定し、カスタムフォントが割り当てられた時間内に読み込まれない場合のフォールバックフォントを指定します。
[amp-fit-text](https://www.ampproject.org/docs/reference/extended/amp-fit-text.html) amp-fit-textタグ内のテキストには、最適化されたフォントサイズが自動的に割り当てられます利用可能なスペース。少しパッケージ化された応答性と考えてください。
[amp-list](https://www.ampproject.org/docs/reference/extended/amp-list.html) amp-listタグを使用すると、動的な繰り返しJSONデータを読み込んでから、HTMLを使用してレンダリングできます。テンプレート。（以下のamp-mustacheタグを参照してください。）
[amp-mustache](https://www.ampproject.org/docs/reference/extended/amp-mustache.html)これは、MustacheHTMLテンプレートのレンダリングをサポートします。
[amp-install-serviceworker](https://www.ampproject.org/docs/reference/extended/amp-install-serviceworker.html) AMPキャッシュを使用しないことを選択した場合（以下のキャッシュについて詳しく説明します）、 amp-install-serviceworkerタグは、現在のページのServiceWorkerをロードしてインストールします。サービスワーカーは上手ですが、私の意見では、サービスワーカーに頼るのは少し時期尚早です。
[amp-youtube](https://www.ampproject.org/docs/reference/extended/amp-youtube.html)予想通り、これは指定されたビデオIDでYouTubeビデオを埋め込みます。
[amp-twitter](https://www.ampproject.org/docs/reference/extended/amp-twitter.html)ツイートを埋め込む（Twitterカードはオプション）。
[amp-instagram](https://www.ampproject.org/docs/reference/extended/amp-instagram.html) Instagramの画像を埋め込みます。
[amp-brightcove](https://www.ampproject.org/docs/reference/extended/amp-brightcove.html)このコンポーネントは、Brightcoveからビデオ（およびビデオプレーヤー）をロードして表示します。
[amp-pinterest](https://www.ampproject.org/docs/reference/extended/amp-pinterest.html) AMPドキュメントにPinterestウィジェットまたは[ピン留め]ボタンを埋め込みます。
[amp-vine](https://www.ampproject.org/docs/reference/extended/amp-vine.html)指定したVineビデオをAMPドキュメントに埋め込みます。

amp-プレフィックス付きのタグは正確に標準のHTMLではありませんが、独自仕様ではないことに注意してください。むしろ、これらはJavaScript実装を備えた正当なカスタム要素であり、セキュリティのベストプラクティスを実施し、リモートリソースの読み込みに優先順位を付けます（詳細については、以下の「AMPランタイム」セクションを参照してください）。言い換えれば、AMP HTMLは、受け入れ、拡張、消滅の戦略のように見えるかもしれませんが、実際にはWeb標準の巧妙なアプリケーションであり、カスタムdata-属性とそれほど違いはありません。

AMPHTMLのスタイリング

AMPドキュメントのスタイリングは標準のCSSで行われ、すでにコンテンツをスタイリングする方法と大差ありません。ただし、次の点に注意してください。

すべてのスタイリングは、インラインスタイルシートを使用して行う必要があります。外部にリンクされたスタイルシートや要素レベルのインラインスタイルは使用できません。（外部にリンクされたスタイルシートでは、レイアウトを計算する前に追加のドキュメントをダウンロードする必要があり、インライン要素レベルのスタイルによってドキュメントが肥大化する可能性があります。）
スタイルは50KBに制限されています。 Googleの哲学は、優れたドキュメントや記事には50 KBで十分ですが、優れたWebサイトには不十分であるというものです。
インラインスタイルシートには、 amp-custom属性（つまり、 <style amp-custom> ）が必要です。
@ルール— @font-face （以下のフォントの詳細）、 @keyframes 、および@media —が許可されます。
ユニバーサル（ * ）セレクターや:not()セレクターなど、一部のセレクターには、パフォーマンスに挑戦することが知られている制限があります。
!important修飾子は、AMPランタイムに要素のサイズ設定に関する最後の単語が含まれるようにするために禁止されています。
amp-carouselなどのカスタムAMPコンポーネントのスタイリングは、 .amp-carousel-button-prevなどのデフォルトクラスをオーバーライドするか、 --arrow-colorなどの事前定義されたCSSカスタムプロパティのセットを使用して行われます。
外部から読み込まれるすべてのリソースには、費用のかかるDOMレイアウトの再計算を最小限に抑えるために、幅、高さ、およびレイアウトのプロパティを指定する必要があります（レイアウトについては以下で詳しく説明します）。
GPUで高速化できる（そして再計算をトリガーしない）トランジションとアニメーションが許可されます。現在、 opacityとtransformはホワイトリストに登録されています。

ドキュメントのスタイル設定の詳細については、AMPHTML仕様を参照してください。

A New York Times article formatted as an AMP document — AMPドキュメントとしてフォーマットされたニューヨークタイムズの記事。（拡大版を表示）

フォント

AMPは、いくつかの条件を備えたカスタムフォントを喜んでサポートします。

フォントは、リンクタグまたはCSS @font-faceルールを使用してロードする必要があります。つまり、JavaScriptを使用してフォントをロードすることはできません。
すべてのフォントはHTTPS経由で提供する必要があります。
フォントプロバイダーはホワイトリストに登録する必要があります。現在、ホワイトリストに登録されているプロバイダーはfonts.googleapis.comとfast.fonts.netのみです。しかし、パブリッシャー、広告主、分析プロバイダーがAMPのサポートをどれだけ迅速に追加しているかを考えると、近いうちにさらに多くのことが続くと思います。

レイアウト

レイアウトに対するAMPのアプローチは、次の2つの主要な目標に基づいて考案されました。

ランタイムは、実際にロードされる前に、外部にロードされたすべてのリソースのサイズを推測できる必要があります。これにより、最終的なレイアウトを可能な限り迅速に計算できます。レイアウトが計算されると、広告、画像、音声、動画の読み込みがまだ完了していなくても、記事をレンダリングして読者が操作を開始できます。（そして、これらのリソースが読み込まれると、ドキュメントのレイアウトを更新することで読書体験を妨げることなく、シームレスにレンダリングされます。）
AMPの記事はレスポンシブである必要があります。「AcceleratedMobilePages」という名前が示すように、AMPドキュメントは特にモバイルデバイスを対象としています。したがって、このコンテキストでは、「レスポンシブ」にはデスクトップ解像度は含まれません。むしろ、AMPドキュメントは、人々がまだ使用している小さな古いiPhone 4の遺物から、比較的巨大なiPad Proまで、すべてのモバイルデバイスで見栄えがするはずです。

前者の目標は、主に、外部から読み込まれるすべてのリソースにwidthとheightの属性があるという要件によって達成されます（さらに、スクリプトを制限することでさらに強化され、新しいリソースを制限することができなくなります）。後者は、標準のメディアクエリ、 media属性、 sizes属性、およびAMP固有のlayout属性によって実現されます。

以下は、AMPが現在サポートしているレイアウトの概要です。

nodisplay要素は最初は表示されませんが、ユーザーの操作によって表示をトリガーできます。（これは、 amp-lightboxなどのコンポーネントと組み合わせて使用されます。）
fixed要素の幅と高さは固定されています。つまり、ランタイムは応答動作を適用できません。
responsive私の意見では、これはAMPのレイアウトオプションの中で最も便利で魔法のようなものです。要素は、アスペクト比を維持しながら、割り当てられたスペースを使用します。（基本的に、「これをどの解像度でも見栄えよくしてください。ありがとうございます。」）
fixed-height要素は割り当てられたスペースを使用しますが、固定の高さを維持します（水平方向にスケーリング）。
fill要素は、アスペクト比に関係なく、その要素が入っているコンテナを埋めます。（ width: 100% 、 height: 100% ％と考えてください。）
container要素はコンテナであるため、標準のdiv要素とまったく同じように、その子（親ではなく）がそのサイズを定義できます。

AMPのレイアウトシステムを使用して機能的でわかりやすいドキュメントレイアウトを実現するのは比較的簡単ですが、AMPがサポートするすべてのものと、さまざまなタイプの要素に値がどのように適用されるかを考慮すると、かなりのニュアンスがあります。より詳細な内訳については、AMPレイアウト仕様を参照してください。

SVGはどうですか？

サポートされています！基本的なSVGは、デスクトップブラウザーとモバイルブラウザーの両方で包括的なサポートを享受しており、グラフィックスはベクターよりも応答性が高くないため、AMPとSVGは非常に優れたチームになります。最大の制限は、スクリプトの制限により、JavaScriptを使用してベクターをアニメーション化できないことです。正直なところ、モバイルで行うべきではありません。ただし、SVGに少し息を吹き込む必要がある場合でも、上記のスタイリングセクションで概説したのと同じ制約に従って、CSSアニメーションを使用して息を吹き込むことができます。 SVGはDOMの一部であるため、他の要素と同じように簡単にスタイルを設定したり、アニメーション化したりできることを忘れないでください。

JavaScriptに関するAMPの哲学

ここに良いニュースと悪いニュースがあります。悪いニュースは、AMPドキュメント用のJavaScriptをすぐに作成しないことです。しかし、ある意味では、それは良いニュースでもあります。 AMPはモバイルアプリケーションフレームワークではないことに注意してください。むしろ、それはモバイル記事フレームワークであり、記事はシームレスで流動的な読書体験のために最適化されるべきであるため、クライアント側の重いスクリプトの良いユースケースは実際には多くありません。

そうは言っても、すべてのJavaScriptを永久に禁止することは、非現実的であり、少し厳しいものです。現実には、Webは、広告、分析、インタラクティブ機能などのために、単純で比較的当たり障りのない読書体験のコンテキストでさえ、しばらくの間JavaScriptに依存してきました。さらに、Webの最も優れた点の1つは、そのオープン性と、実験、表現度、創造性に対する一見無限の能力です。これらの多くはJavaScriptを利用しています。

AMPチームは、ユーザーが作成した任意のJavaScriptがパフォーマンスの保証に与える負担と、最新のWeb環境におけるJavaScriptの遍在性と必然性の両方を認識し、次のスクリプトの原則を考案しました。

現時点では、ユーザー作成のJavaScriptはサポートまたは許可されていません。 AMPドキュメントには2種類のスクリプトタグしかありません。リンクトデータタグ（タイプはapplication/ld+json ）と、AMPランタイムと拡張AMPコンポーネントの両方を含めるためのタグです。
AMPプロジェクトの作成者は、モバイル記事の消費に関連してJavaScriptのニーズのほとんどを予測しているため、AMPは代替手段（リンクタグ付きのカスタムフォントや@font-faceルールなどを含むamp-pixel ）をサポートします。 AMPランタイムと互換性のある実装を提供するため、セキュリティとパフォーマンスの両方が保証されます（ amp-ad 、 amp-analytics 、 amp-carouselなど）。
インタラクティブ機能のようなものにJavaScriptを本当に使用する必要がある場合は、機能を個別に構築してから、 [amp-iframe](https://www.ampproject.org/docs/reference/extended/amp-iframe.html)に含めることができます。 [amp-iframe](https://www.ampproject.org/docs/reference/extended/amp-iframe.html)タグ。 amp-iframeに含まれるコンテンツは、リクエストのサイズ変更などのために、親ドキュメントとの限定的な通信も許可されます。
AMPコンポーネントはオープンソース（Apache 2）であり、貢献を受け入れることができるため、新しいコンポーネントが徐々に登場します（実際、この記事の執筆と編集の過程でいくつかの新しいコンポーネントが登場したので、すでに数回更新しています）。 AMPチームは、サービス固有の機能（たとえば、ソーシャルスタートアップ専用のウィジェット）よりも一般化されたコンポーネントを優先しますが、可能な限り幅広いコンテンツに対応するのに十分な多様性を提供することにも取り組んでいます。
最後に、これらのポリシーはすべて変更される可能性があります。 Webワーカー、カスタム要素、Shadow DOMなどのブラウザー機能がより広くサポートされるようになると、ユーザー作成のJavaScriptとカスタムコンポーネントをサポートするためのオプションが、セキュリティとパフォーマンスを保証しながら劇的に拡大します。

AMPコンポーネントの将来の詳細については、「AMPHTMLコンポーネント」仕様の「拡張コンポーネント」セクションを参照してください。

AMPドキュメントの構造

AMP HTMLについてかなりしっかりと理解できたので、定型文を分解してみましょう。

もちろん、AMPドキュメントはdoctype宣言から始めます。

 <!doctype html>

次に、HTMLドキュメントをAMP HTMLとして指定します。これは、信じられないかもしれませんが、 htmlタグの属性として高電圧絵文字を使用します。

 <html >

または、あなたが昔ながらの悪党で、コードを愛らしい絵文字で飾るという考えに頭を悩ませている場合は、代わりにはるかに保守的なamp属性を使用できます。

 <html amp> <!-- A good sign that you're boring! -->

headでは、 utf-8文字エンコードの手順を忘れないでください。

 <meta charset="utf-8">

また、ドキュメントの非AMPバージョンにリンクします（重複コンテンツとして表示されないように、 canonicalとしてマークされています）。

 <link rel="canonical" href="my-non-amp-index.html">

逆に、AMP以外のバージョンには、AMPlifiedドキュメントへの参照が含まれている必要があります。

 <link rel="amphtml" href="my-amp-index.html">

AMPページはモバイルデバイスを対象としているため（GPUラスタライズも必要）、必ずメタviewportタグを含めてください。

 <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">

次のコード行は少し奇妙に見えるでしょう、そしてそれはそうだからです。フォントがロードされて適用される前に、Webページがテキストを短時間レンダリングし、その後、デザイナーが意図したとおりにちらつき、レンダリングし直すことがあることをご存知ですか？以下のタグは、適切なスタイルが設定されるまで、ページの不透明度を0 （非表示）に保ちます。

 <style> body { opacity: 0 } </style> <noscript> <style> body { opacity: 1 } </style> </noscript>

このアプローチの問題は、AMPランタイムの読み込みに失敗した場合、技術的にはページの不透明度が0から1にならない可能性があることです。このような不測の事態を補うために、上記のコードはおそらくこれに近いものに変更されます。

 <style> body { animation: amp-timeout 0x 5s 1 normal forwards; } @keyframes amp-timeout { 0% {opacity: 0;} 100% {opacity: 1;} } </style>

次に行うことは、AMPJavaScriptランタイムを含めることです。

 <script async src="https://cdn.ampproject.org/v0.js"></script>

また、必要な拡張コンポーネントのJavaScript実装を含めます。

 <script async custom-element="amp-youtube" src="https://cdn.ampproject.org/v0/amp-youtube-0.1.js"></script> <script async custom-element="amp-audio" src="https://cdn.ampproject.org/v0/amp-audio-0.1.js"></script> <script async custom-element="amp-carousel" src="https://cdn.ampproject.org/v0/amp-carousel-0.1.js"></script> <script async custom-element="amp-lightbox" src="https://cdn.ampproject.org/v0/amp-lightbox-0.1.js"></script> <script async custom-element="amp-anim" src="https://cdn.ampproject.org/v0/amp-anim-0.1.js"></script> <script async custom-element="amp-twitter" src="https://cdn.ampproject.org/v0/amp-twitter-0.1.js"></script> <!-- etc. -->

（ async属性の使用に注意してください。これはオプションではありません。ブロッキングが少ないほど良いです。）

オプションで、次のように、リンクされた小さなデータを振りかけることができます。

 <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "NewsArticle", "headline": "Turn Your AMP up to 11!", "image": [ "img/cover-opt.jpg" ], "datePublished": "2015-01-11T08:00:00+08:00" } </script>

次に、CSSでlinkタグまたは@font-faceルールを使用して、いくつかのフォントを追加しましょう。

 <link href='https://fonts.googleapis.com/css?family=Roboto+Condensed:300,700' rel='stylesheet' type='text/css'> <link href='https://fonts.googleapis.com/css?family=Lora:400,700,400italic,700italic' rel='stylesheet' type='text/css'>

次に、必要なamp-custom属性を使用して、いくつかのスタイル（50 KB以下の価値）を作成します。

 <style amp-custom>

これで、AMP HTMLについて学習したすべてのことを使用して、多かれ少なかれ標準のHTMLドキュメントを作成する準備が整いました。

AMPランタイム

すべてのランタイムと同様に、AMPランタイムは少しブラックボックスであるため、AMPランタイムにそれほど多くの時間を費やすことはありません。これは、AMPランタイムにアクセスできないということではありません（プロジェクトの他の部分と同様に、オープンソースです）。むしろ、すべての優れたランタイムと同様に、開発者は、それが何をするのかを一般的に理解している限り、それを利用するためにそれがどのように機能するかを正確に知る必要はありません。

AMPランタイムは完全にJavaScriptで実装されており、外部のJavaScriptファイルと同様に、AMPドキュメントに含めることで開始されます。

 <script async src="https://cdn.ampproject.org/v0.js"></script>

そこから、AMPランタイムは主に次の3つのことを行います。

リソースの読み込みと優先順位付けを管理し、
AMPコンポーネントを実装し、
オプションで、AMPHTMLのランタイムバリデーターが含まれます。

バリデーターは、AMP準拠のドキュメントを作成するために重要です。ドキュメントのURLに＃development #development=1を追加するだけでオンにできます。次に、コンソールを開いてレポートカードを表示するだけです。

エラーは次のようになります。

AMP validation errors in the console — コンソールのAMP検証エラー。（拡大版を表示）

きれいで、準拠しているAMPドキュメントは次のようになります。

An AMP document that passes validation — 検証に合格したAMPドキュメント。（拡大版を表示）

（オプションの）AMPキャッシュ

AMPドキュメントは、他のHTMLドキュメントと同様にWebサーバーから提供できますが、特別なAMPキャッシュから提供することもできます。オプションのキャッシュは、いくつかの手法を使用してAMPドキュメントをさらに最適化します。

画像参照は、視聴者のビューポートに合わせて特別にサイズ設定された画像に置き換えることができます。
折り目の上の画像をインライン化して、追加のHTTPリクエストを保存できます。
CSS変数をインライン化して、クライアント側のオーバーヘッドを減らすことができます。
拡張AMPコンポーネントの実装はプリロードできます。
HTMLとCSSを縮小して、ネットワーク（またはこの場合は電波）を介して送信されるバイト数を減らすことができます。

誰でも自分のCDNで自分のAMPキャッシュを実行できます。または、サイト運営者はGoogleを無料で使用できます。グーグルがスケーラビリティについて1つか2つのことを知っているように思われることを考えると、ほとんどのAMP採用者はその申し出に喜んでそれを受け入れるだろうと私は推測しています。（Googleのキャッシュにオプトインする方法に関するドキュメントは近日公開されますが、Googleがすでにインターネットのインデックスを作成してキャッシュしていることを考えると、 linkタグとおそらく追加のmetaを中心に展開することは間違いありません。）

読者はどのようにしてAMPコンテンツを見つけますか？

The fact that AMP document are more or less standard HTML that will render in any modern browser is, in my opinion, a huge advantage (AMP is far more open and inclusive than Facebook Instant Articles or Apple News). But from a practical perspective, it also raises the question of how audiences will find AMP content.

If readers use Google to search from a mobile device, Google can link directly to AMP versions of articles (Google has not said that it will prioritize AMP documents over non-AMP documents, but it has said that it will use “mobile friendliness” as a mobile search signal, so you do the math). In fact, Google has indicated that it will begin sending traffic to AMP pages from Google Search on mobile as early as late February 2016. Discovery and curation engines such as Pinterest may also choose to start directing mobile traffic to AMP pages (with a few infrastructure changes). Finally, websites can redirect their own mobile traffic from responsive versions of articles to their AMP counterparts. But from my perspective, a few pieces of the puzzle are still missing.

Will other search engines direct mobile traffic to AMP articles? (Perhaps not search engines that want to do business with Apple.) Will social networking apps preload AMP documents when users post links to articles, in order to make rendering nearly instantaneous? (Probably not Facebook.) Will mobile browsers start looking for link tags with amphtml relationships? (Chrome, maybe, but probably not mobile Safari.) And will aggregators and news readers out there build specifically for lightning-fast AMP content? (Time to resurrect Google Reader!)

At this point, the answers to most of these questions are the same: to be determined.

See AMP In Action

The easiest way to see AMP in action is to check out Google's search demo. If you're the trusting type, you can watch the video and just assume it all works as well as it's depicted. If you're more the trust-but-verify type, you can go to g.co/ampdemo on your mobile device and try out some AMP pages for yourself (QR code below).

You can also check out the AMP experience through desktop Chrome using Chrome's Developer Tools. あなたがしなければならないのはこれだけです：

Go to g.co/ampdemo in Chrome.
Open the Developer Tools by going to “View” → “Developer” → “Developer Tools.”
Go into device mode by clicking on the little phone icon in the top-left corner.
Pick your favorite device to emulate. (For best results, reload the page in the emulator.)

An AMP document in Chrome Developer Tools — An AMP document in Chrome's Developer Tools.

Who's Adopting AMP?

It's still relatively early days for AMP, so it's hard to tell exactly who is adopting the new format in earnest, and to what extent. That being said, I've already seen several implementations out there in the wild, and according to the AMP FAQ and AMP blog, it's being taken seriously by many major publishers (metered content and subscription access is currently under review), CMS developers, advertisers, and analytics providers. I won't list them all here because I'm sure the landscape will change almost daily, but you can keep an eye on the AMP project's home page and/or the AMP blog for news.

What Do I Think?

よろしくお願いします。 My guess is that just about all publishers will eventually adopt it. If companies like BuzzFeed have taught the industry anything, it's the importance of being in as many places as possible, and that digital publishing should be a technology platform capable of getting content in front of readers wherever they are, as opposed to being a singular destination waiting for readers to come to it.

The investment required to support AMP is also relatively minimal. If a publisher already supports — or plans to support — Facebook Instant Articles and Apple News, then they might as well implement support for AMP as well. While CMS strategies vary widely across the publishing industry, most CMS' have a concept of templates and/or plugins that, once implemented, would do most of the work of converting articles into AMP HTML. (WordPress, the closest thing we have to an industry leader, already has a plugin and plans on supporting AMP for all publishers in January 2016.) And because AMP is far less proprietary than its competition (meaning that it is open source, open to contributions, based on web technologies and client-agnostic), I would expect publishers to feel more comfortable distributing their content in a format that they feel they will have more control over long-term.

The reality is that publishers will back whatever syndication formats and partners will help get their content in front of the maximum number of readers with the least amount of overhead and investment. Right now, we are in the very early stages of a new type of war that is part platform, part format and in which each party will leverage its unique strengths to maneuver itself into the best possible position. At this point, it's far too early to say which will endure and which will become the RSS of tomorrow.

追加リソース

“Introducing the Accelerated Mobile Pages Project, for a Faster, Open Mobile Web” Google Official Blog
Accelerated Mobile Pages Project, official website
Accelerated Mobile Pages, blog
AMP HTML, GitHub
Docs, Accelerated Mobile Pages Project
Nigel Tufnel explaining why his amp goes to 11