HTMLファーストへの転換でユーザー数が一晩で2倍に！その驚きの舞台裏

最近、WebサイトをHTMLファーストな設計に刷新したところ、なんとユーザー数が一晩で2倍に跳ね上がりました。過剰なJavaScriptによるレンダリングを廃し、原点回帰したことが功を奏したようです。パフォーマンス改善がいかにUXとコンバージョンに直結するかを証明する結果となりました。

対論として：シングルページアプリケーション（SPA）を擁護する記事です。

https://williamkennedy.ninja/javascript/2022/05/03/in-defenc... (https://williamkennedy.ninja/javascript/2022/05/03/in-defence-of-the-single-page-application/)

最近の自分のアプリは、ほとんどHTMX + Go + SQLiteだけで作ってる。大抵のプロジェクトならこれで十分だね。

あるサイトは画像を大量に扱うから、月間10TBのトラフィックがある。そのための構成はこんな感じ：

1. S3（信頼性の高いデータストレージが欲しかったから）
2. その手前にCloudflare（Tiered Cacheを有効にして、POPがオリジンじゃなくCloudflareから取得するようにした）。ブラウザとCloudflareの両方で1年間キャッシュするようにルールを設定して、オリジンのキャッシュポリシーやクエリ文字列を無視するようにしてる。リビジョンが必要な場合はイミュータブルなオブジェクトを使ってるだけだよ。
3. さらにその手前にBunnyCDNを置く

Cloudflareは画像中心のサイトをそのままホストさせてくれないから、コストを大幅に削るためにこの方法をとってる。規約上、画像メインの利用はNGで、HTMLやCSS、JSといったコンテンツのための利用が必須だからね。

S3だけで運用すると、利用料がとんでもないことになるし。

あと、最近はモバイルアプリも作ってるけど、PWAには限界があるね。OSがIndexedDBのストレージを勝手に削除しちゃうから、サインアップやバックエンドを使わないと、ユーザーに信頼できるデータ保存先を提供できないんだ。

どうすればいいんだ？ってことでAndroidはFlutterに乗り換えざるを得なかったんだけど、また別の悩みが。アプリの更新が「審査中」で長時間止まることがあって、それが本当にストレス。同じアプリでもWeb版ならすぐに更新できるのに。

JavaScript、HTML、CSSでアプリを作れて、余計な苦労なしに確実なストレージを使わせてくれるモバイルOSが、なんで存在しないのか不思議でたまらないよ。

PWAみたいにサクッとアップデートできるの、最高なんだけどね。

10年以上前、司法省のGOV.UKで似たようなアプリを作ったことがある。当時はRuby on Railsが標準で対応してなかったから、長いフォームをステップごとに検証して複数ページに分割するフォームウィザードライブラリを自作したんだ。ユーザーがどんな環境でアクセスしてもデジタルサービスを利用できるようにする、っていうのが当時すごく大事な原則だったな。

最近はあまり聞かないけど、「HTML Triptych」の提案[0]は、いつかブラウザに実装されてほしいと思ってる。HTMLフォームからRESTエンドポイントを呼び出すのは良いパターンだしね（入力属性でユーザー補助のバリデーションを行い、リクエストの先で本来のバリデーションを実行する。流れとしてはGET /form => POST /thing => GET /thing/1）。Triptychの機能が実装されれば素晴らしいパターンになるはず！

[0] https://triptychproject.org/ (https://triptychproject.org/)

素晴らしい記事だね。でも、こういうインスピレーションあふれる記事を読むといつも複雑な気持ちになる。シンプルで無駄がなく、動作が軽快で、最新ブラウザへの依存がないサイト、という考え方は大好きだし、自分もそうありたい。

でもそのあと、「自分がReactとか、その時々の流行りの技術を理解できないほど頭が良くないからそう思ってるだけなのか？」なんて考え始めちゃうんだよね。

自分には越えられない理解力の壁がある気がする。Sublimeみたいなシンプルなエディタで「Webページを作って」と言われたら、JS込みでも楽しく作業できるのに。VSCodeやZed、Claude/Copilot/ChatGPTのプラグインがてんこ盛りで、Reactのチュートリアルなんて見せられた日には、脳がフリーズしちゃうよ。

Web開発者じゃない身として、ここの部分が疑問なんだけど：

悲しい結末があった。契約仕事の常として、私は現場を去った。後任者に私が作ったものについて説明した。JavaScriptなしでも常に動くものだと。彼は呆れてこう言った。「でも、それだと俺たちの仕事が増えるじゃないか」

なぜ仕事が増えるの？記事にある手法って、フォームに標準の<input>タグを書いて、一番下に送信ボタンを置くだけだよね。何年も前に自分でWebサイトを作ってた時はそんな感じだったし、そんなに難しくなかったはず。自分の業界知識が足りないだけかもしれないけど、派手なフロントエンドを作るほうがよっぽど大変に思えるんだけど。

この記事は良いし、問題を適切な技術と深さで解決する素晴らしい例だと思う。顧客のドメイン知識を完全に把握しておくことは本当に助けになるしね。

ただ、「シンプルなHTMLはReactより優れている」という書き方は好きじゃないな。同じ話をReact開発者の視点で書くこともできたはずだから。

（補足：サーバーベースのセッション管理とブラウザベースのストレージの複雑さとか、記事でさらっと流されたことについて延々と語れるけど、長くなるからやめておくよ）

HTMLで簡単にできることは、Reactでも簡単にできる。文字通り同じコードだから。Reactでブラウザ標準のHTMLバリデーションを使っちゃいけない理由なんてない。Reactで複雑になりがちなバリデーションロジックは、Astroでやっても結局複雑になる。Astroにはスキーマバリデーションとかがあるし、それをサイトに統合するってことはクライアント側のルーターなども組み込むことになるから、簡単に複雑化の道へ進めてしまうんだ。

それに、この記事の比較対象はオフショアのチームで、おそらく知識も不完全で、プロジェクト構造上、最短時間で最大限の複雑さを生み出すインセンティブが働いていたんだろう。

最後のポイントは厄介だね。請負業者が意図的にやるわけじゃなくても、構造的に過度に複雑にした方が得をするようになっているから、シンプルな道を選ぼうという動機付けが働かないんだ。

とにかく、どんなスタックを選ぼうが、目の前の問題に対して直接的でシンプルな解決策を取るのが一番だね。

（Astroのフォームバリデーションに反対しているわけじゃないよ。ネイティブのHTMLバリデーション以外にも考慮すべきことは多い、ってことを言いたかっただけ）

悲しいことに、自分がしぶしぶ引き継ぐReactプロジェクトのほとんどがこういう結末なんだよね。経験上、ReactはVueやSvelteみたいに「こうあるべき」っていう規約がないからだと思う。あるチームは状態管理にこれを使う、別のチームは全く別のものを使う、ってなって、散らかした挙句に両方のチームが去っていく。でもMBAが追うグラフや数字上は、ギリギリまで生産性が高いように見えるんだよね。結局、最大の犠牲者はユーザーだよ。Facebookですら自社のWebサイトでReactを使いこなせてない。InstagramやFacebookのWeb版を使ってみてよ。ドロップダウンメニューの静的なリストを読み込むだけなのに、スピナーがぐるぐる回る。冗談抜きで、InstagramのWeb版でハンバーガーメニューをクリックすると、何十回もリクエストを送って、ローディングスケルトンを表示して、メニュー項目が見られるようになるまで5秒もかかる。皮肉なことに、2014年頃のFacebookが爆発的に人気だったのは、Reactベースのくだらない仕組みがなかったからだよ。当時はすべてが古き良きハイパーリンクだった。

15年前を思い出すよ。Grailsでバックエンドのセッション管理を使って、レスポンシブなCSSと「多少」のJSで強化したHTMLフォームを作ってたな。当時はブラウザ技術が今ほど進んでなくて、IE7やIE6まで考慮しなきゃいけなくて本当に大変だった。Browserstackもなかったし、広範なQAが必要だったんだ。JSライブラリが進化し続けたのには理由がある。npmもbowerもなかったんだから。その後、Backbone.jsが出て、AngularJS、Angularの破壊的変更、React、Polymerと続いてきた。今のブラウザは標準でできることが多いし、機能強化も楽になった。でも、昔はそうじゃなかった。当時Reactを採用した決断にはそれなりの理由があったし、このケースもそうだったのかもね。

Reactサイトは全然好きじゃないけど、Reactサイトって遅延読み込み（lazy load）とか全然しないの？

大規模なSPAアプリでも、コンポーネントが必要な時だけ読み込まれるならすごく速いよね。

Angular1 -> Vue2 -> Svelte2と渡り歩いて、今はShadow DOMを使わない純粋なWeb Componentsに落ち着いたけど、開発は楽しいし動作も爆速だよ。