Upgrade to Pro — share decks privately, control downloads, hide ads and more …

非フロントエンジニア観点でのMPA・SPA・SSR・SSGの違い

 非フロントエンジニア観点でのMPA・SPA・SSR・SSGの違い

Satoshi Kaneyasu

December 27, 2023
Tweet

More Decks by Satoshi Kaneyasu

Other Decks in Programming

Transcript

  1. ざっくりとした⽐較表 項⽬ MPA SPA SSR SSG 開発のしやすさ 中 ⾼ 中〜⾼

    ⾼ レスポンス 中 ⾼ ⾼ 最⾼ データ量 ⼤ 中 中 ⼩ ネットワーク通信量 ⼤ ⼩ 中 最⼩ SEO ⾼ 低 ⾼ ⾼
  2. MPA (Multi-Page Application) • 画⾯遷移する度にサーバー側で画⾯全体を作ってクライアントに渡す • 例)Wordpress • 画⾯遷移のたびにブラウザの更新ボタンが×になる •

    私たちが使うとモノリシックな作り⽅になりがち • 先にバックエンドを実装して、画⾯の実装が後回しになりがち • 昔⾔われてた「戻るボタン効かない問題」はMPAでも解決可能 • 別にMPAそのものにそんなに問題があるわけではない コレ
  3. MPAの通信の流れ 初回 画⾯全体 リクエスト PHP SQL レスポンス 描画 画像 リクエスト

    レスポンス 描画 CSS リクエスト レスポンス 描画 JS リクエスト レスポンス 実⾏ n回⽬ 画⾯全体 リクエスト PHP SQL レスポンス 描画 画像 リクエスト レスポンス 描画 CSS リクエスト レスポンス 描画 JS リクエスト レスポンス 実⾏ ページ遷移ごとに全ての通信と処理が⾛る
  4. SPA (Single-Page Application) • ⼀発⽬に画⾯⼀式分を返す その後は差分だけ返してクライアント側で描画する • 例)React.js、Vue.js • かなり難しい

    • フロントにFWが存在するという概念⾃体がピンとこない⼈もいる • デザイナーとの分業が⽐較的しやすい • 分業しないと画⾯の変更要望に追いつけない現実もある • SEOが弱い • 検索botは画⾯の差分を動的に作ってくれない、リンクを辿ってくれない • 同じ理由で、Xのサムネイルが出ない
  5. SPAの通信と処理の流れ 初回 画⾯全体 リクエスト PHP SQL レスポンス 描画 画像 リクエスト

    レスポンス 描画 CSS リクエスト レスポンス 描画 JS リクエスト レスポンス 実⾏ n回⽬ 差分データ リクエスト PHP SQL レスポンス 描画 初回に画⾯⼀式を返したあとはあとは差分
  6. SSR (Server-Side Rendering) • MPAとSPAの中間のような技術 • ある程度の画⾯をサーバー側で描画する • 例)Next.js(React.jsの派⽣)、Nuxt.js(Vue.jsの派⽣) •

    サーバー側とクライアント側が混在するのでまた違う難しさ • デザイナーとの分業がしやすい︖ • 私たちから⾒たらピンとこないが、フロント界隈ではメジャーなのかも • ⽐較的SEOが強い • 作れる画⾯はサーバー側で作るので、検索botがリンクを辿ってくれる • Xのサムネイルが出る
  7. SSG (Static Site Generation) • 全ページをサーバーで完全にHTML化して、配置。 リクエストされたらただ返すだけの状態にする技術。 • 記事を投稿したら、全ページ⼀気に作り直して再配置する。 •

    例)Gatsby.js • ものすごく軽くて早い • CMSのようなものと捉えるとものすごく機能不⾜を感じる • 回避策はなくはないが • ランディングページとかに向いてると予想 • 縁がないのでわからない・・・
  8. もう⼀回表 項⽬ MPA SPA SSR SSG 開発のしやすさ 中 ⾼ 中〜⾼

    ⾼ レスポンス 中 ⾼ ⾼ 最⾼ データ量 ⼤ 中 中 ⼩ ネットワーク通信量 ⼤ ⼩ 中 最⼩ SEO ⾼ 低 ⾼ ⾼ 得⼿不得⼿はあるけど特定の技術でないとできない︕ ってのは少ない だからこそ⼀つの技術で突っ⾛るのではなく、 ⽬的に合わせて使い分けたい