ホーム

🎥

モダンフロントエンドデザインパターン 〜 優れた UX を実現するには 〜 | AWS Dev Day 2023 Tokyo

作成日: 2024-05-07T13:17:00.000Z

最終更新: 2024-08-07T13:15:00.000Z

動画見ながら要点だけメモっておくだけのもの

ユーザ体験の指標

  • Core Web Vitals

    • LCP

      • 2.5秒以内にロードを目指すことが推奨されている

        代替テキスト

    • FCP

      • 1.8秒以内のロードが推奨されている

        代替テキスト

    • FID

      • 100ms以下を目指す

        代替テキスト

  • 開発者体験の指標

    代替テキスト

  • ユーザー体験と開発者体験から見るフロントエンドのレンダリングパターン

レンダリングパターン

CSR（Client Side Rendering）

代替テキスト

  • <div id=”root”></div> のみのHTMLが最初にダウンロードされる
    • JSでページを構成する
    • デメリット
      • 最初にJSでページを構成するまで、ユーザに何もないページを提供することになる
        • サーバーコスト：低
        • クライアントコスト：高
    • JSのサイズが多くなり、ユーザのデバイスが最新ではない傾向から、パフォーマンスの最適化が求められる
      • Code SplittingやLazy Loadによるユーザ体験の向上
        • 必要最低限のJSのみ最初に読み込んでおき、優先度の低いものは遅延読み込みをさせることで、ユーザに必要最低限の機能を最初に提供しておく
          • 完成度(80%) → ユーザーが基本的に利用に支障がない → ユーザに使用してもらいつつ、裏で100%になるようにJSのDLをコントロールする
  • AWSアーキテクチャの例

    • CloudFront + S3

      代替テキスト

    • キャッシュ

      • ユーザのブラウザ = Private Cache
      • CDN = Public Cache
      • オリジンのキャッシュコントロールによってコントロールできる

      代替テキスト

      • webpackにより、ハッシュ値を名前に設定することでキャッシュをクリアする方法が一般的
      • 合わせてデプロイ際には、CDNのキャッシュもクリアする

      代替テキスト

    • Client Side Routingの制御

      代替テキスト

    • CloudFront Functionによる制御

      • CloudFrontでは、2つのレイヤーが存在しており、よりユーザに近いEdge Locationで制御することが推奨される

      代替テキスト

SSR （Server Side Rendering）

  • Hydration

    • 単なる文字列としてサーバー側から返却されるHTMLにイベントなどをアタッチし、HTMLを完成させる

      代替テキスト

      代替テキスト

  • AWS アーキテクチャ

    • SSRするサーバーとデータソース
      • サーバー側でHTMLを構築する際にAPIを介したり、直接DBにリクエストする

    代替テキスト

    • Lambda Edgeを利用するパターン

    代替テキスト

  • SSRのレンダリングプロセス

    • FCPは短縮できる（画面の最初の描画は早い）
    • TTIは、CSRとほぼ変わらない（ユーザが利用できるようになるまでの時間は変わらない）
    • 画面は表示されているのに、ユーザが操作できないといった体験が生まれる可能性があることに注意

    代替テキスト

    代替テキスト

  • SSRの課題

    代替テキスト

    • これらを解決するStreaming HTMLやSelective Hydration

    • Streaming HTML

      • データフェッチが終わったところから、HTMLを部分的に返却していく
        • FCPやTTIを早めることができる

      代替テキスト

    • Selective Hydration

      • ReactのSuspenseなど

      代替テキスト

SSG（Static Site Genetation）

  • prerenderring

  • SSRは、ユーザからのリクエストに応じてHTMLを生成する

  • SSGは、事前にすべてのページを生成する

    • サーバーサイドでのレンダリングやフェッチが不要になり、ユーザに早く届けることができる

  • AWS アーキテクチャ

    • ビルドしたHTMLをS3へ配置

      代替テキスト

  • SSGの得意領域

    • 表示速度に特化

    代替テキスト

    • 注意点

    代替テキスト

ISR（Incremental Static Regeneration）

  • ページに優先度をつけて、必要な分だけ生成することでSSGのビルドにかかる時間という課題を解決する

    代替テキスト

  • Cache

    • 60秒ごとのrevalidate
    • オンデマンド revaidationも選択肢にある

    代替テキスト

Next.jsのホスティングパターン

代替テキスト

  • Serverless

    • Next12までの一部の機能をサポートしていることやLambda@Edgeを利用している点への注意

    代替テキスト

    • Serverless Next.jsの開発は停止している

    代替テキスト

    • Open Nextという方法

      代替テキスト

    • Lambda アダプター

      代替テキスト

      代替テキスト

      代替テキスト

  • Amplify Hosting

    • シンプルに利用できるが、すべての機能をサポートしていない

    代替テキスト

  • Computing

    • 開発コストは上がるが、すべての機能を利用できる

    代替テキスト

まとめ

代替テキスト

おまけ

video

メモ

  • SSR
    • SSRはお客様でトラブルが発生した際に問題の切り分けがしやすい
      • CSRはお客様の環境でwebページを構築してしまうので、お客様環境固有の問題なのか、サービス側が送信したものに不具合があったか分かりにくい
      • SSRの場合は、提供しているものをサーバー側で作っているのでバックアップをとって実際にお客様に渡しているものを把握できる
    • JSが動かない環境でも目的を果たせる（かもしれない）
      • CSRはJSが動かないとほとんど何もできない
      • SSRはサーバー側でHTMLを構築するのでJSが機能しないお客様のフォローもできる