【35歳未経験でも理解できた】SPAへの進化 | TechDistill

> Source: Qiita_Trend

// Problem

従来のWebアプリケーションでは、ページの一部を更新する場合でも、サーバーからHTML、CSS、JavaScriptを含むページ全体を再取得する必要があった。この挙動は、更新のたびに画面が白転（フリーズ）するユーザー体験の低下を招くだけでなく、サーバー側でも全リソースの再生成と転送が必要となり、通信コストとサーバー負荷を増大させる課題があった。

// Approach

SPAアーキテクチャを採用することで、ページ全体のリロードを回避する。Fetch APIを用いてバックグラウンドでサーバーと通信し、Promiseによって非同期処理の実行順序や成否を制御する。データ交換には軽量なJSON形式を用いることで、必要な情報のみを最小限のコストで取得し、DOM操作によって該当箇所のみを書き換える手法をとる。

// Result

ユーザーに対して、画面遷移を感じさせない滑らかな操作感（UXの向上）を提供できる。また、通信量をデータのみに限定することで、ネットワーク帯域の節約とサーバー負荷の軽減を実現する。本記事は概念的な解説に留まっており、実装における詳細な最適化や、SPA特有のデメリットについては言及していない。

Senior Engineer Insight

> 初学者向けの概念図としては、比喩の選択が適切であり、非同期処理のイメージを掴ませる点において高い教育的価値を持つ。しかし、実戦投入の観点では、SPAの採用は諸刃の剣である。クライアントサイドでの状態管理（State Management）の複雑化、初期ロード時のJavaScript実行コストによるLCP（Largest Contentful Paint）の悪化、およびSEO対策の難化といったトレードオフを考慮しなければならない。大規模・高トラフィックな現場では、SPA単体ではなく、Next.js等を用いたSSR（Server Side Rendering）やISR（Incremental Static Regeneration）との組み合わせによる、レンダリング戦略の最適化が不可欠である。