created_at
updated_at
tags
toc

本サイトの AMP 提供の停止とここまでの振り返り

Intro

前回の記事で、奇遇にも本サイトの AMP 対応を落とすことになった。しかし、そうでなくても AMP をどこかでやめることは考えていたため、きっかけの一つが SXG 対応になったのは、順当な流れだと筆者は感じている。

これは AMP がなぜ始まり、なぜトーンダウンしつつあるのか、そしてこれからどうなっていくのか、という流れをまとめるいい機会でもある。

その過程で生み出され、本サイトでも検証を続けてきた Performance Timing API, Core Web Vitals, Signed HTTP Exchange 、そして今構想されている Bento AMP などを踏まえ、一連の流れを覚えている範囲で記録としてまとめておく。

ソースは筆者の主観であり、眺めてきた体感を mozaic.fm の Monthly Web などで話してきたものがベースなので、信頼性や正確性は期待しないで欲しい。

AMP Begins

AMP が発表されたのは 2015 年で、リリースされたのが 2016 年だ。本サイトもその頃作り始め、今サイトを作るならと AMP の対応もほぼ同時に行った。

当時は徐々にモバイルユーザが増え、モバイルファースト Web が叫ばれ始めてしばらく経った頃だ。一方リアルワールドでは PC 版をメディアクエリでスマホ対応したサイトが多く、過度にリッチな表現をビューポートに詰め込みつつ広告が張り巡らされた、とにかく重たいサイトが多かったと思う(今でもあるが)。

当時まだ Google にいた Iliya が HPBN を出したのは 2013 年だった。もともと「SPDY の薄い本」になる予定だったと mozaic に出てくれた時話していたから、出た時期としては HTTP2 になりつつある頃だ。

当時でもまだ Web 黎明期を引きずったエンジニアのノスタルジーによってバイブル視され続けていた High Performance Web Site のプラクティスが古いことを知らしめ、(当時の)モダンパフォーマンスチューニングの啓蒙を Iliya が一手に担っていたように思う。

しかし、彼が一人で啓蒙を続けても、それが届くのはごく一部の意識の高いエンジニアのみで、実際にそのプラクティスが適用されるのも、ごく一部の意識の高い組織に留まる現実があった。

AMP のモチベーションの一つに「Iliya 一人じゃスケールしないから」だと Alex Russel が言っていたみたいな話も、どっかで聞いたけどどこだったか覚えていない。

非機能要件から機能要件へ

パフォーマンスに限らず、セキュリティやアクセシビリティなど、一般的に非機能要件の啓蒙はスケールさせるのがむずかしい。どんなに丁寧に解説した書籍を出しても、それを読むのはごく一部で、読まないその他大勢の数の力の前には圧倒的に無力だ。

これをスケールさせる方法の一つとして、それを機能要件に落とし込み、検証可能な仕様に置き換えるという方法がある。

具体的には、ツールで検証可能にし、そのツールを通ることをテストとしてしまう方法がある。alt 警察が巡回するよりも、alt が無い img を弾くという checker を回すような手法だ。これはセキュリティでも適用できる場面が多い。OWASP Zap や Lighthouse なんかがこれにあたるだろう。ただこれらはまだ任意選択だ。

一歩進めてフレームワークがデフォルトにしてしまう方法がある。例えば XSS 対策のために実際に行うべき適切なエスケープ方法を余すところなく周知するよりも、デフォルトでエスケープがなされるテンプレートエンジンを導入すれば問題の大半は解決する。これを 非常にうまくやったフレームワークの一つに Rails がある。レールに乗っている以上はある程度安全であり、そして Rubyist にとって Rails のレールに乗るのはほぼ機能要件だ。うっかり外れればレビューで叩かれるし、要件として外れないとならない場合は「これから危険を伴うことをする」という意識で開発者は臨める。

さらに最近では Web で発見された様々な脆弱性に対し、適切な制限を課すための仕様が定義され、それらがブラウザでデフォルトになる流れがある。CORP や UA-CH や SameSite Cookie などがその代表例だ。デフォルトになることで、開発者はそれでも動くように作ることになり、正直なんでそんな対策が必要なのかよくわかっていない開発者にも、機能要件を満たすために対策を意識させることができる。

逆をいえば、非機能要件を機能要件に落とし込むことが、非機能要件の成熟と言ってもいいのかもしれない。

AMP は、Iliya が啓蒙していたようなプラクティスを、制限として持つフレームワークとして生まれ、AMP Valid にするという機能要件を満たすためには「遅くなるようなことはできないフレームワーク」という発想で設計されている。

「遅くなるようなことはできない」という制限は、遅くなるようなことを一通りやり尽くしたサイトが導入すると、相対的に速くなるというのが、パフォーマンスという非機能要件に対する一つの答えだったと見ることができる。

そんなもの無くても十分遅くないサイトが作れる開発者にとっては意味がないため、発表時点では筆者も全く興味を持っていなかった。むしろ、「こんなものが流行るわけ無い」と思っていた。これが AMP に対す筆者の大きな誤算だった。

AMP の普及とインセンティブ

そんなフレームワークができたとしても、本やツールと同じで、開発者に届き使われなければ意味がない。しかし自分のサイトに積極的に多くの制限(特に JS のサイズ)をかけたがる組織はない。

実は非機能要件にはもうひとつ、プライオリティという壁が常にある。どんなに精通した開発者がいても、組織において優先度が低かったり、工数や予算が確保できず、「やりたくてもやれない」という場面が往々にしてある。

セキュリティのように、かなり直接的な問題に発展しがちなものでもそんな状態なのに、「うちのサイトは遅いから」「このままでは使いにくいから」などという陳情は「わかるけど次打つキャンペーンの方が優先度高いから」「それよりもこのバグ直さないと」などと横に置かれがちなのは、各位もどこかで覚えがあるのではないだろうか。

そこで Google が提示したのが「AMP に対応すると Search で優遇される」というインセンティブだった。

筆者は当時ピンと来ていなかったし、そんなんで対応するか?と思っていたのを覚えているが、世界はビックリするぐらいこの吊るされた人参に飛びつき、瞬く間に AMP は広まっていった。

特にメディア系のサイトにとって SEO (これも非機能要件な気はするが)は非常にプライオリティが高く、ちょっとでも優位に立てるなら予算が降りる。その結果「よくわからないけどトップダウンで AMP に対応しろと言われた」という組織や「これを逆手に取り上の説得材料としてパフォーマンス改善の実施を取り付ける」など、それぞれモチベーションが違えど、結果として AMP 対応が進み、モバイルサーチの結果に稲妻マークが目立つようになった。

同時期に Facebook による Instant Articles や Apple の Apple News のような、プラットフォームに閉じた仕組みですらある一定の成果を得ていたので、Google にはインセンティブがあれば AMP を普及させられるという自信が少なからずあったのかもしれない。Origin が AMP よりも速かったマイノリティサイトを除けば、その普及はモバイルサイトのパフォーマンスを実際に向上していたのだろう。それが世界規模で起こっていたと考えると、まさしく、良くも悪くも Google らしい「世界の動かし方」だったんだと思う。

AMP の問題

SEO を目的として AMP に対応するのであれば、実際 AMP がどのような仕様でどう挙動するかは、メディアで集客をしたいという部分にモチベーションを感じる層にとってはどうでも良かったのかもしれない。しかし、それでもやはり開発者にとっては納得できない部分もあった。筆者もその一人だ。

まず、当時の本サイトは JS を一切使っていなかった上に思いつく最適化のほとんどを実施していたため、AMP よりも Origin の方が速かった。だからそもそも筆者は AMP が嫌いだった。まあそれも少数派だろう。

もっと大きな問題がドメインだ。AMP は Origin のコピーを Google が収集し、Google ドメインの CDN から配布する。これは AMP HTML というより Google の AMP Cache の仕様だ。検索結果で優位に立つことが目的であれば気にならないかも知れないが、普通に考えるとやはり違和感があり、不満を持つ人も多くいた。それは純粋にアーキテクチャ上の不自然さという真っ当な指摘から、定番の「Google が全部支配している」みたいな陰謀論めいたものまで多く見たように思う。

その不満が一つの形となって現れたのが AMP Letter だ。2018 年だから、AMP が始まって 3 年くらいか。

Letter の中身はそこまで感情的な批判ではなく、存在や効果は認めつつも、ここまでに述べたような技術的問題やエコシステムへの影響を指摘している。今読んでもよくまとめられていると思う。

WebPackaging と SXG

AMP Letter が公開されるのとほぼ同時期、というかなんなら数日前に、タイミングを合わせたかのように AMP から以下のアナウンスがある。

AMP の URL が google.com になる問題は、WebPackaging (というか SXG) で解決していくという話だ。そもそも WebPackaging (SXG + WebBundle) の話が出始めたのは 2016 か 2017 年くらいだったと思う。mozaic.fm の Monthly の初回 ep26 ではすでにしているが、それより前は細かく覚えていない。確か、突然のように MHTML の標準化みたいな話が出てきて、あれよあれよと WebPackaging の話が IETF で始まっていた気がする。

IETF の draft 見ると、WebPackaging には PWA チームも興味があったようだけど、SXG はやはり AMP のモチベーションが大きかったんじゃないだろうか。今思えば、事前に WebPackaging の話を進めながら、なんとかなりそうという段階で Letter に合わせて Answer を出せるように調整していたようにも見える。

SXG を使って署名をすれば AMP Cache から配信しても Origin の URL が表示できるというのは、まさしく AMP のことだけを考えた Patching な仕様に見えてしまいそうだ。しかし、全体の構想として WebPackaging があり、そこには PWA など他の青写真も含まれていたことを知っていたため、その部品と見るならば妥当な方向性ではあると当時感じたのを覚えている。

それでも SXG にはやはり賛否があり、ちょうど Mozilla が Standard Positions を公開するようになったのもこの時期で、SXG は Standard Positions が公開されたほぼ最初から Harmful として表示されていた。なので筆者には Standard Position 自体が SXG に harmful と言うために始まったように見えた。

ちなみに、この harmful に対して、証明書に拡張を追加することで、いわゆる HTTPS に使う証明書が使い回されないような改善が行われた。ただ、その拡張に対応した証明書は Digicert しか発行しておらず、他の CA の対応の話はまだ聞かないため、SXG 普及のボトルネックの一つでもある。

Google としては Mozilla その他のフィードバックを含めて仕様の改善を重ね、2019 年には Chrome に SXG が実装され AMP で SXG に対応する AMP SXG がリリースされた。

本サイトもこれに対応したことで、確かに AMP がヒットしても URL バーには blog.jxck.io が表示されることを確認した。

AMP によって余計なことができなくなり、AMP CDN から配信されコンテンツが速くなり、SXG によって URL も自分のものが表示される。そう聞くとたしかに色々解決してはいるが、なんとなく釈然としない開発者もいるだろうとは思う。

そもそも AMP なんか無くても速くできる人にとっては、やることが増えているだけだ。CDN から配信されるので Origin サーバで行いたい様々な改善もできないし、Access Log すら手に入らない。SXG の証明書を適切に運用し、ライフタイムも管理が必要、amppkger の運用もなかなか癖があるし、色々思うこともあったのを覚えている。

そして CWV へ

AMP Letter には、URL の問題ともう一つ、重要な指摘がされていた。それが「中立的な指標」の問題だ。

要するに AMP は速くする手段として存在するが、AMP がなくても速いコンテンツを作ることができる場合、同じように速くても AMP であることが優遇されるのは不公平ということだ。

速くすることが目的なら、評価すべきは「AMP かどうか」ではなく「速いかどうか」だ。Letter の中では Speed Index などの指標が使えるはずという指摘があり、これは AMP を人参ではなくフレームワークとして理解していた開発者からすれば至極真っ当な意見だと思う。かくいう筆者も同じことを考えていた。

Speed Index は当時割と重視されはじめた指標だった。特に初期ロードにおける画面が真っ白な時間を減らすことは体感的にも妥当な最適化として受け入れられつつあったと思う。

しかし、パフォーマンスが与えるユーザへの体感の変化を数値化するためには一つの指標では足らず、様々な追加の指標が提案された。この頃は Performance Working Group から雨後の筍のように指標が提案されていた時期だった。既に土台として存在した Performance Observer に取り入れられることで標準化されるものもあれば、別途ツールで評価されるものもあった。測定のためのツールやプラグインも増え、さまざまなプラクティスが日々飛び交っていた。

ここで議論された様々な指標の中で、Google は「少なくともこの数値が良ければ、そのサイトは遅くはないだろう」と思える指標を 3 つに絞り、それを Core Web Vitals と定義したのが 2020 年だ。

なんでもかんでも測って評価するというのは効率的ではないため、AMP が行おうとしていた Mobile First なページの UX を改善するために、初期表示が遅くないページを作るという目的が評価できる最小限の指標を、セットにしたものが CWV と見ることができる。

そして、AMP のときと同様に、今まさに Google が行っているのが、CWV のスコアをページランクの指標に反映するというものだ。

つまり、同じ課題に対して AMP は「手段」を提供したが、CWV は「指標」を定義した。そして、ここに AMP と同様の人参をぶら下げることで、CWV のスコアを意識するインセンティブを提示したのだ。

実際 Page Experience として評価されるのは CWV だけでなく、HTTPS であることや、悪質な Ad がないことなどがあがっているが、他はもう前提のようなものと考えると、多くのメディアにとっては「SEO のために CWV を改善する」という OKR が出来上がる。一旦延期され、6 月から徐々に展開され始めた 変更に向けて、CWV の改善は各所で行われている。

CWV は Origin を速くすればよいため、わざわざドメインが変わる AMP や AMP SXG を運用する必要もなくなる。AMP が気に食わなかった開発者は AMP を離れて自分の力で改善をすれば良くなる。なんなら AMP 自体が突き詰めるとある一定以上速くするのが難しいという問題も解決して、AMP より速い Origin も実現できる。そこまでできない組織でも、CWV をとにかく定期的に監視する必要が出るため、一時的なハックではなく継続的な改善を余儀なくされる。

唯一不満が上がりそうなケースは、既に自分たちで計測を行い、検討した結果 SpeedIndex などを Key Metrics として設定していたチームにとっては、いきなり「お前らが見るべきはそれじゃなくて CWV の 3 つだ」と突きつけられることに違和感があるかもしれない。かくいう筆者もそうだった。

といっても、CWV の内容はこれで確定ではなく、見直されていくことが宣言されている。もし本当に SpeedIndex などが含まれるべきと思うなら、フィードバックすべきと話になるだろう。ただ、おそらく既に指標を適切に測定して改善を回せているなら、ある程度「遅くない」状態が維持できているか、維持できていなくても原因が把握できているくらいの状態ではあるだろう。そうであれば指標が CWV に変わったところで大して困らないし、今までやってきたことは無駄じゃないはずなので大した問題にはならないのではないかとも思う。

逆に、パフォーマンスを改善するために指標を道具として利用するのではなく、指標そのものを改善対象にし始めると注意が必要だ。人間は数字を見るといとも簡単にとらわれ、その指標をハックし始めがちだ。「スコアは良いが別に速くない」という状態も無くはない。そうして、指標を対象にしてスコアの上昇をもってサイトを改善した気になっていると、将来 CWV の中身が別の指標になったり、スコアの算出方法が変わったりした場合に、破綻する可能性もある。数値は数値でそういう怖さがある。

すでに初期の CWV (LCP, FID, CLS) の内容は追加や算出方法の変更が予定されており、今年の Google I/O でも、初期表示だけでなくユーザが操作した後の UX に関わる部分も測れるように、CWV を更新していくという話が出ていた。現状の数値だけをごまかしているサイトは、そのうちボロが出る可能性があるため、本質的な改善が求められることになる。

1st Party Bottleneck から 3rd Party Bottleneck へ

「CWV の値」が指標となったことで、「AMP であれば良い」という要件の裏に隠れていたある問題が現前したりもした。それが 3rd Party Bottleneck だ。

実際 1st Party つまり自分たちのコードのボトルネック改善は、自分たちの管理下にあるコードなので、言ってしまえばやるかやらないかの問題だ。特に新規開発なら、気をつけて進めれば、スコアを満たすことなどそこまで難しいことではない。

いくら 1st Party が速くても、それを一瞬で台無しにできるのが 3rd Party 、具体的には Tag Manager の中に貼られた広告や SNS パーツや Analytics のタグだ。これらは自分たちで手を入れられないため、改善といっても実装を変えるといったことはできない。できるのは、タグを入れるか入れないかの選択くらいだ。さらに広告などは、表示のたびに落ちてくるものが違うため、結果も一定とはならない。

これら 3rd Party Tag は、入れれば入れるだけ遅くなることが多いが、広告収益で成り立つメディアなどにおいては、広告を表示してこそサイトに存在意義がある場合もあり、消すという話にはなりにくい。それを最適化するためのアナリティクスも、なんなら複数ベンダのものが入っている場合も多い。

技術的な問題以外に、Tag Manager の中の管理は開発者ではなくマーケティング部門が握っていて、開発者が知らないところで追加されたり、使ってなさそうだから消したくても誰が管理しているかわからないから消せないなどの運用の歪も目立つ。

したがって CWV の改善の本番は、1st Party の改善が終わったあと、3rd Party Tag の中を改善するために、そこを管理するガバナンスのために組織の連携に手を入れるところまで話が膨らみがちだ。しかもボトルネックがそちらである以上 1st Party をちょっと改善したところで、全体としては何も変わっていないというケースも多い。

逆に 3rd Party Tag を消した状態で CWV を測ったらグリーンで、そこにマーケとの交渉を終えて折衷案に整理し終えた 3rd Party Tag を差し込んだらレッドになるような場合は、手詰まりとなる。タグを差し込む位置を工夫したり、読み込みをなんとか遅延させたりして、とにかく初期表示に干渉しないように読み込むぐらいしかできることがなかったりする。

AMP はなんだかんだメジャーなタグはそのまま使うことができていたので、AMP Valid にさえできればそれでよかった。CWV の改善によって 3rd Party タグの問題が浮き彫りになった今後は、CWV への影響を加味して 3rd Party Tag のベンダが選ばれるようになっていくのではと思うこともある。ベンダ側も自社のタグが外されないように、実装の改善を走らせているころなのではないだろうか?

AMP as Framework

CWV という指標によって、「遅くないサイトである」という評価が中立的に行えるようになり、これをもって「AMP であるかどうか」を指標に使う必要がなくなった。結果、AMP は当初の目的を達成し、これ以上優遇される必要がなくなった。さらにいえば、AMP だけど CWV 的に遅いサイトが存在する可能性を考えると、「優遇」は積極的にやめていくべきということにもなる。

これが筆者の理解している AMP が「トーンダウン」しているという現状のバックグラウンドコンテキストだ。

では人参を失った AMP にこれ以上価値は無いのだろうか?

実際、トーンダウンしているのは Google の検索結果の中での話であって、AMP HTML が役目を終えたのかというとそれはまた別の話だと筆者は考える。

そもそも CWV を改善し、グリーンスコアを維持し続けるのは、言うほど簡単ではない。新しく作るサイトならまだしも、運用中のサイトを CWV の測定だけで改善していくのは骨の折れる仕事だ。そういう改善を指揮する人なら、誰かが知らないところで無思慮に入れる変更を見つけては直していく過程で、制限をつけて未然に防ぎたいと思うだろう。それが AMP だ。AMP には、Linter や Checker のように使う上で必要なものは揃っている。自分でイチからルールを積み上げて周知徹底するくらいなら、AMP という選択肢は十分にありえるだろう。

あと、あまり話題にならないが、AMP は現状「世界でもっとも普及した WebComponents ベースのフレームワーク」ということができるのではないだろうか。<img> を <amp-img> にするだけで「画像読み込みのベストプラクティス」が適用されるが、その内部実装を気にする必要はない、というのは WebComponents が目指していた世界そのものであり、AMP はそれを周辺エコシステムと様々な実装知見と合わせて、すでに 5 年程度の運用実績がある。AMP のその点はもっと評価されてもいいと思う。

「検索結果で優遇されるための要件」という責務の降りた AMP も、この「WebComponent ベースのフレームワーク」としていまだ健在だ。そこで、この Web Components ベースのフレームワークとしての AMP (AMP as Framework) をより汎用的に使えるように、Web サイトを作る際に Next.js や Lit HTML などと並んで選択肢に上がるようなフレームワークにする、というのが AMP Project 自体が次に目指す方向として動き出しており、その目的地が Bento AMP だ。

現状の AMP は、カルーセルやアコーディオンといった頻出 UI コンポーネントを持っていながら、bundle された JS が前提だったり、AMP が全体として Valid であることが前提になっていたりと、部分的に取り出して利用するのに適した作りになっていない面もあるため、そのへんも含めてより汎用的にし、さらにコンポーネントを充実させフレームワークとして育っていくのだろう。

一方で他のフレームワークも、「普通に作れば遅くはならない」ような設計にするのが常識になりつつあり、そうであれば AMP よりも使い慣れたフレームワークが選ばれるだろう。AMP には先行者利益があるとはいえ、競争はもっと熾烈になるとは思うが。

トーンダウンというとネガティブに聞こえるかも知れないが、検索結果における優遇はそうなるべくして CWV に移り、そこからやっと AMP as Framework が始まり、徐々にトーンが移っていくのだろう。

SXG と Instant Seamless

AMP は domain を直すために SXG を使ったが、SXG は AMP のためのものではない。

通常の HTML レスポンスも SXG によって署名することができ、それは CDN から配布されてもブラウザ上では Origin の URL で表示できる。

Google の検索結果はこの Non AMP な SXG にも対応を開始し、サイトが SXG を配信していればそれを収集し SXG の CDN から代理で配布するようになった。しかも、ただ検索結果のリンクを SXG に置き換えるだけでなく、prefetch を行うことで、リンクをクリックする前に取得が完了するようになった。

ボトルネックの大半はネットワークアクセスである Web において、クリック時にリソースが Prefetch Cache でヒットし手元に揃っている状態は大きなアドバンテージだ。特にモバイルファーストでパフォーマンスを考える CWV 以降では、初期表示の改善が期待できる点で実施する価値がありそうだ。(また Origin からの配信ではなくなるのだが)

こうした投機的取得で問題になるのは IP リークだ。今回のように検索結果の最初のページに prefetch のリクエストが飛ぶような作りだと、実際にはそのページに遷移しなかったとしても、IP などの情報が Origin には渡っていることになる。しかし、今回の prefetch は Google の検索結果から Google の SXG CDN に対してリクエストが飛ぶだけなので、Origin は何の情報も得ることはない。

このように、SXG が使えるのも、もとはといえば AMP があったからだと考えると、きちんと資産は活用されている。そして、その Non AMP SXG に対応するにあたって、本サイトでは AMP を落とすことになった。

本サイトでは、AMP の対応に始まり、そこから派生した様々な仕様を検証し、その検証の最終地点として AMP の対応を終わることになったと考えると、やはり最初に特に興味があるわけでも好きでもない AMP を検証のために対応しておいたことは、いろいろな Web 技術を検証するために作った本サイトの目的からすると、やっておいてよかったと振り返ると思う。

今後

AMP に対応し、AMP SXG に対応し、Non AMP SXG へ移行したことで AMP を辞めた本サイトだが、その流れで次にやるべきことがあるとすれば Bento AMP の検証ということになる。本サイトは、基本的にフレームワークについては対象外としてるが、順当にピュア WebComponents ライブラリとして成長していくなら、試す価値はあるだろう。その日が来ることも考えて AMP を生成するコード自体はまだ残してある。

そして、まだまだ途中である WebPackaging 関連の仕様や、最近話題の Prerender2 を始めとした Instant & Seamless 関連の API など、広義にはここまでの流れを汲んだ様々な仕様もあるため、引き続きそうした仕様も試しつつ、これからどうなっていくのかを見続けていきたい。

Reference