AMPとは?モバイルページのパフォーマンスを上げる秘密とその歴史

モバイルWebサービスに、いま革命が起きています。

Googleが現在推進しているAMP(Accelerated Mobile Pages)は、Webパフォーマンスの速さを再重視する方針を取るものです。レスポンシブデザインの時代に築かれた常識を覆すような、利用者の意識変化をもたらしています。

そもそもAMPとは何でしょうか?
どんな要素がAMPの台頭を支えているのでしょうか?
そしてこのWebパフォーマンス新時代においてWebデザインはどのように変わっていくのでしょうか?

そもそも AMP とは ??

AMPとは、スマホやタブレットなどモバイル端末でウェブページを高速に表示するためにGoogleが進めるプロジェクトないし規格を意味します。2016年よりGoogleの検索結果において、AMP対応ページは「雷」マークで識別されるようになりました。

AMP対応ページは非常に早く読み込みが可能で、Googleによれば従来のモバイルWebページよりも85%早くロードできるとのこと。

雷マークがAMPの目印!

早く読み込める理由は以下の2つ。

  • ウェブページ自体が通常よりも簡略化したAMP HTMLで記述されており、そこで読み込むJavaScriptファイルも特別な仕様にしているため(AMP対応ページは、コンテンツオーナーがそれぞれ作らなければならない)
  • AMP対応ページをGoogleの専用サーバーがあらかじめキャッシュしているため(一般には、Google検索から記事リンクをタップすると記事掲載サイトのサーバーにアクセスすることになるが、AMP対応ページでは記事のサイトのサーバーに直接アクセスすることなく、Googleの専用サーバーにアクセスできる)

AMPを早期に取り入れた、いわゆるアーリーアダプターには大きな見返りがあったという結果が出ており、中には、AMPの実装後コンバージョンとトラフィックにおいて70-100%もの上昇がみられた会社もあるということです。

AMPが導入される以前から、読み込み時間がいかにWebサイトの成功に大きな影響を持つかについてはあらゆる統計が取り上げてきました。Googleの報告によると、検索結果からリンクをクリックして読み込みに3秒以上かかったら、53%のユーザーはそのサイトを見ることを諦めるとのこと。もしその検索に一日10万ドルの売上があるオンラインストアへのリンクがあった場合、最初のページの一秒の読み込みの遅れは年間250万ドルの損失につながるといえます。コンマ何秒という僅かな時間の差も、会社の最終収益に大きく関わってくるのです。

読み込み時間が及ぼす打撃

GEORGE ANDERSON / 216digital

AMP が生まれるまで:Webパフォーマンスの歴史

企業はなぜAMPを求めているのでしょうか。その答えは簡単です。

モバイルユーザーはほぼ一瞬で快適にコンテンツにアクセスできることで、彼らはそのままサイトの閲覧を続けてくれます。そして最終的にコンバージョンにつながるのです。

しかしユーザーは、どうして表示速度が遅いことに我慢できなくなっているのでしょうか?

スマホの歴史年表

2000年代半ば:初期のスマートフォン

Blackberryをはじめとする初期のスマートフォンによって、2000年代始めから半ば頃にかけて、大衆のモバイルインターネットの利用が始まりました。限られた処理能力と遅い接続速度しか持たないこのデバイスには、反応が遅く重たい閲覧環境しか期待できませんでした。
いうまでもなく、人気も控えめであまり定着しませんでした。

スマホの祖先blackberry

出典:Bla1Ze / CrackBerry

2008年:「アプリ」の登場

iPhoneの登場とApp Storeのリリースは、モバイルWebの人気に火を付け、モバイルでのWeb利用は一般的となりました。

端末にインストールするアプリは、タスクごとの目的に細かく焦点を合わせて設計され、それぞれが任された単一のタスクをより早くこなすことを重視されました。その結果、それまでのモバイルWebにあった表示速度のわずらわしさのないユーザー体験を可能にしました。ここでの「短い読み込み時間とモバイル向けに最適化されたデザイン」が、のちにAMPの基本理念へと繋がっていくのです。

Edayのタスク焦点型アプリ

▲初期のiPhone向けeBayアプリは、必要なタスクに焦点を絞ることでシンプルさを追求するという理念の現れ(出典:WP-Smooth

2010年:多様なタッチスクリーン端末とレスポンシブデザイン

そして2010年代。スマートフォン、タブレット、両者の特徴を備えた「ファブレット」……タッチスクリーンを搭載したさまざまなデバイスが市場に登場しました。Webサービスやアプリを提供する企業は、それぞれのプラットフォーム向けにアプリをいくつも設計することはせず、どうにかして多様なタッチスクリーン端末で共通したUXを提供する方法を模索しました。

レスポンシブWebデザイン(RWD)は、アプリに代わる「コスパのいい」何かがあればという希望と、どんなデバイスを選んでもその環境に応じたWeb体験をしたいというユーザーの期待を満たす必要から生まれてきました。

さまざまな大きさのタッチスクリーン機器たち

出典:Addy Osmani / Next steps

2014年:「スマホ対応」表示

レスポンシブデザインにより、モバイルに最適化されたレイアウト対応が増えていく中、Googleは検索結果にスマホ対応(Mobile-friendly)ラベルを導入しました。これはリンク先のページが、レスポンシブデザインやその他のフレームワークを使用して、小さい画面の閲覧に最適化されていることをユーザーに知らせるための表示です。

スマホ向けmobilefriendly表示

2016年:PWA=プログレッシブウェブアプリ と AMP

レスポンシブデザインがかなり広く適応されるようになったことで、Googleは「スマホ対応」バッヂから撤退しました。その当時、検索結果の85%がスマホ最適化されていたと発表があり、わざわざ表示する必要がなくなったのでしょう。

ユーザーにとって、もはやモバイルに最適化されたレイアウトは最低基準であり、ユーザーの期待を上回って満足感を与えるのは、格別に読み込みが早くて操作が楽なサイトだけなのです。この記事のテーマであるAMPや、PWA(Proggressive Web Application:アプリのようなWebサイト)は、こうした「アプリのような操作性をWebページに求める」というさらなる要求を満たすために登場しました。

レスポンシブデザインを採用のプラットフォーム

▲「Pure Formulas」のオンライン販売サイトではこのようにPWAを採用。PWAのページ遷移の事例としてご覧ください。

レスポンシブデザインの時代は終わった

レスポンシブデザインは、今日までのモバイル最適化の中心的な役割を果たしてきましたが、高いWebパフォーマンスの新時代を実現するものではないといえます。

「ひとつのコードベースで全てのタッチスクリーンに対応する」というアプローチは、すべての事業者にモバイル向けのWeb設計を可能にしましたが、その実装者のほとんどが、不用意な実装がもたらす結果についてきちんと考えていませんでした。デスクトップサイズを想定して作られたデータが、より小さい処理媒体と処理容量に、デバイスのパフォーマンスへの配慮がなく押し込まれた結果、表示速度の遅い過剰に複雑なモバイルUXを大量に生み出してしまいました。

また最近、Webサイトのコンテンツ配信を手助けするツールが多すぎることも、表示速度の低下に加担しています。これらのWebツールは、JavaScriptのような重いスクリプト言語を使って、画像・フォント・広告やソーシャルコンテンツを外部ソースからWebサイトに引っ張ってきています。それらの工夫のためのリクエストが積み重なって、パフォーマンスに悪影響を及ぼします。
特にレスポンシブサイトでは、モバイルの端末が無理やり重いスクリプト言語に適応させられているため、その影響は大きく、モバイルWebの閲覧者にとってWebツールがもたらす機能は結局無意味なものになります。

スマホなどの小画面の媒体では、ページのデザインだけでなく、水面下のコードにおいてもそれぞれに対応したWeb体験が必要なのです。この「ローディング時間を短縮するためのコードの簡素化」に対する新しい問題意識こそ、AMPを象徴するものです。

企業はレスポンシブデザインの現状から脱するべく、AMPやPWAのような解決策に目を向け、顧客がより満足できるようなUXを提供したいと思っています。

AMP  は「悪者」なのか?

AMPプロジェクトは、その運営方法ゆえにそれ相応の批判を受けています。AMPサイトをGoogleのURLに表示させるためには、WebサイトのコンテンツをGoogleが開発したデベロッパーツール一式を使って、Googleが承認したHTMLのサブセットでコーディングしなければなりません。何人かの有名なデベロッパーは、AMPを「Webの精神に反する(anti-web)」として厳しい批評を発信しており、Googleは将来他者のコンテンツをコントロールするためのさらに悪質な方法を取る恐れがあると指摘しています。

この懐疑論を信じるかはそれぞれにお任せするとしても、AMPがユーザーの求めるものを提供しているという点については誰も否定できないでしょう。AMPはネットユーザーの「待ち時間なしでコンテンツにアクセスしたい」という要求を叶えるものであり、一般的なユーザーはGoogleのドメインでのアクセスという点については特に気にしないでしょう。

GoogleによるAMPの成長データ

▲図のように、AMPプロジェクトによる自社統計では、企業採用率とユーザーエンゲージメントの高さが示されています(出典:David besbris / AMP BLOG)

AMP がもたらすWebの未来

AMPで作られたページが検索結果に増えるにつれ、企業はサイトの表示速度の競争で優位に立とうと競い合い、このスピード重視という動きはますます拍車がかかるでしょう。

また「一つのコードベースで全てに対応できる」というアプローチにも変化が訪れ、設計者は制限された環境の下で、どこでどのようにコンテンツが届くかをより制御するようになる時代へと変わるでしょう。

レスポンシブデザインの頃のレイアウト最適化策から、AMPにみられるパフォーマンス最適化策への方針転換は、モバイルユーザーの目から見れば来るべき時代へのほんの一歩でしかありません。おそらく基準は完全にリセットされ、残りのWebもAMPの事例に追随することになるでしょう。

また2018年3月に発表されたAMPプロジェクトからは、AMP以外の即時にアクセスできる選択肢の登場がまさに目の前に迫っていることがうかがえます。

我々はAMPから学んだことを活かし、AMP以外のWebコンテンツでも即時読み込みが可能になるようなWebの標準規格の創出に取り組んでいます。(中略)AMPは多くの選択肢の中の一つになるかもしれませんが、しかし我々が自信を持って薦めるただ一つのオプションでもあり続けるでしょう。

どうやらGoogleはAMPによってWebのフレームワークを独占するつもりではなく、Googleはパフォーマンスの高いUX環境を作る主導的な立場にAMPを据えたいのではないかと思われます。Googleのこのような立場からは、将来の自由競争が予想され、先ほど紹介したような「高パフォーマンスサイトにはGoogle検索からしかアクセスできない未来が来る」という陰謀論を打破することとなるでしょう。

未来への予測

これまでは、モバイルWebの動作性を改善することに重点が置かれてきましたが、これは「モバイルの接続や処理能力がデスクトップデバイスに比べてパフォーマンスが低い」という前提に立ってこそ意味をもつ方針です。

しかし、AMPをより画面の大きい端末に適用してはいけない理由もありません。この方向性はPWAのデベロップメントにも反映されており、端末に応じて最適化されるアプリのようなUXをデスクトップでも利用できるような取り組みへと重点が移りつつあります。

初期のPWA

▲初期のデスクトップPWAの例(出典: The Financial Times

Web開発は改善され、現在AMPで見られるような読み込み時間での閲覧が可能になると予想されます。そうした高パフォーマンスのサイトが多数を占めてくると、そのうちAMPの「雷」マークもお役御免になるでしょう。Google検索の「スマホ対応」の表示がレスポンシブデザインの台頭で廃れていったように、「歴史は繰り返す」ものなのかもしれませんね。

そうなるとひょっとすれば、「もっとも早い」だけでなく、「もっとも楽しみがいのある」体験を目指すレースが繰り広げられるかもしれません。そうなれば、UXデザインへの取り組みが再び重要課題になってくるのかもしれません。

まとめ

筆者は個人的には、AMPなんて必要なければよかったのにと思っています。モバイルパフォーマンスにおいて、Google開発のHTMLでしか、ユーザーが我慢できる読み込み時間を提供できない状況がそもそもおかしいのです。

AMPプロジェクトの衝撃が、Webサイトのオーナーやデベロッパー、そしてソフトウェア会社の目を覚ましてくれればと思っています。これをきっかけに、彼らには一歩引いたところから自らの判断を冷静に見て、それがどのようにサービスのパフォーマンスと、最終的にUXに影響するか、いま一度しっかり考えてほしいです。

Webデザイナーやユーザーと同様に、筆者も「パフォーマンス時代」の到来にわくわくしています。この時代の訪れは間違いなくWebの在り方に大きな影響を与えるでしょうし、高い動作性を求めることや、単純にページの読み込み時間早くするというステージには留まらないでしょう。読み込み時間の短縮というのは、満足度の高いUXのひとつの要素にすぎません。高速のローディングに加えて、直観的で楽しみやすい体験がもたらさせる未来を、予想せずにはいられません。

(原文:Mitch Lenton 翻訳:Yuko Nakamura)

 

合わせて読みたい!↓

SHARE

RELATED

  • お問い合わせ
  • お問い合わせ
  • お問い合わせ