日本語訳があるので面倒臭がらずに読んだほうがいいです。
要約
AMPは無意識にユーザーがGoogleエコシステムに留まるようになっており、また検索結果に対してプレミアムな演出や優先順位を与えており、Webの中立性を破壊している、という指摘。
Googleが言うように、Webの速さが懸念ならば、AMPという技術の有無に関わらず特定の速度を満たせば今のAMPと同じような特典を与える、また明示的にGoogleのエコシステム内にいるという演出(おそらくヘッダーを付与するなど)を行う、といった提案。
私見
GoogleのWebの速さに対する懸念も、AMPの実装の邪悪さも、自分は両方よく分かる。
AMPは自分の仕事のドメインとしてチェックしているが、プラグインがGoogleのホワイトリストとして管理されていて、実際には政治力を使って、プラグインを登録させるといったアクションが必要になり、日本のような狭いマーケットの 3rd party なプラグインが登録されづらい。
また技術的にも AMP自体のドキュメントが足りず、AMP対応している会社は、Google のコンサルティングを受けて対応している会社が多そうに見えており、あまり良くない状況に見える。
外野の開発者からすると、GoogleはWebの為にやってるという表向きの立場も、「あわよくば」といった感が透けて見えるのも、どちらも読み取らないといけない。Webの為に、というのも vs Facebook, vs ネイティブアプリ 的なニュアンスがある。
AMP を分解して本質を標準化してほしい
AMPの技術制約は、レンダリングのクリティカルパスなどのフロントエンド的なベストプラクティスとして面白いと思っていて、しかし、特定の技術に対応したサイトを特別扱いして高速化する、という政治的な層が挟まっているのが気持ち悪い。
個人的には、GoogleがAMPを特別扱いしてキャッシュを保存するのをやめて、エントリページとして何をプレロードするか、たとえば選択的に ServiecWorker や ResourceHint を検索画面表示時に起動して先読みする、といった解があるようにも思う。そうすれば体験としては同一になる。代わりにユーザー側のCPUに負荷が掛かるので、オプションで切れるようにする必要もあるが…
現在、 AMPからService Worker を起動する実装は既にあって、これもドメイン跨いでServiceWorkerを起動しているので特例的な感じなのだが、その辺をスペックとして定めてほしい、といった気持ちがある。
Google は今までも実験的なものを出して標準化し直すというフローを繰り返してきたので、今回もうまいこと落とし所を探ってほしいと思う。