Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
SSRとCSRの狭間で〜ハイパフォーマンスWebサービスを夢見るフロントエンドエンジニアの闘い〜
Search
Hiroaki KARASAWA
June 29, 2019
Technology
0
290
SSRとCSRの狭間で〜ハイパフォーマンスWebサービスを夢見るフロントエンドエンジニアの闘い〜
BigLT Aizu 2019
Hiroaki KARASAWA
June 29, 2019
Tweet
Share
More Decks by Hiroaki KARASAWA
See All by Hiroaki KARASAWA
成功する技術選定について
karszawa
2
1.6k
飲食店のインフラサービス “ダイニー” のトラブル対応のすべて
karszawa
0
7
Google Cloud のモニタリング製品を徹底活用してみた
karszawa
0
35
ダウンタイム 30 秒で AlloyDB に移行した話
karszawa
0
98
DMS で AlloyDB に簡単移行!
karszawa
0
40
【現場の本音】App Engine から Cloud Run に移行してみた
karszawa
0
130
cls-hooked による実行コンテキストの保存と利用
karszawa
0
780
Hasura の Relationship と権限管理
karszawa
0
820
React Native + Expo のバージョンアップと互換性の維持に関する運用と絶技
karszawa
0
770
Other Decks in Technology
See All in Technology
AIアプリケーション開発でAzure AI Searchを使いこなすためには
isidaitc
1
260
論文紹介 ”Long-Context LLMs Meet RAG: Overcoming Challenges for Long Inputs in RAG” @GDG Tokyo
shukob
0
240
アクセシブルなマークアップの上に成り立つユーザーファーストなドロップダウンメニューの実装 / 20250127_cloudsign_User1st_FE
bengo4com
1
1.1k
やっちゃえ誤自宅Nutanix
yukiafronia
0
330
バクラクの組織とアーキテクチャ(要約)2025/01版
shkomine
4
550
Japan AWS Jr. Championsがお届けするre:Invent2024のハイライト ~ラスベガスで見てきた景色~
fukuchiiinu
0
1.1k
Windows Server 2025 へのアップグレードではまった話
tamaiyutaro
2
240
インシデントキーメトリクスによるインシデント対応の改善 / Improving Incident Response using Incident Key Metrics
nari_ex
0
3k
生成AIを活用した機能を、顧客に提供するまでに乗り越えた『4つの壁』
toshiblues
1
170
横断SREの立ち上げと、AWSセキュリティへの取り組みの軌跡
rvirus0817
3
3.7k
HCP Terraformで実現するPlatform Engineering/nikkei-tech-talk-29
nikkei_engineer_recruiting
0
200
srekaigi2025-hajimete-ippo-aws
masakichieng
0
140
Featured
See All Featured
Building an army of robots
kneath
302
45k
Reflections from 52 weeks, 52 projects
jeffersonlam
348
20k
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
6
510
Building a Scalable Design System with Sketch
lauravandoore
460
33k
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.3k
Git: the NoSQL Database
bkeepers
PRO
427
64k
A Tale of Four Properties
chriscoyier
157
23k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.8k
GraphQLとの向き合い方2022年版
quramy
44
13k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Transcript
1 Confidential - Do Not Share SSR と CSR の狭間で
〜ハイパフォーマンス Web サービスを夢見るフロントエンドエンジニアの闘い〜 bigLT 2019 aizu / June 29, 2019. @karszawa
2 Confidential - Do Not Share Web Front-end Engineer Joined
Mercari as newgrads in April 2019. Twitter @karszawa React / TypeScript / vscode / Chrome Hiroaki KARASAWA
3 Confidential - Do Not Share 今日話すこと 2019年にWebサービスを開発する上で まずはじめに考えないといけない パフォーマンスのこと
4 Confidential - Do Not Share 今日話すこと But about Architecture
Not about Libraries SSR, CSR, or others React, Vue, Angular...
5 Confidential - Do Not Share 今日話すこと 1. Web技術の変化とパフォーマンス改善の歴史 2.
CSR / SSR ↔ Client / Server Side Rendering 3. 今年、一押しの技術 4. まとめ
6 Confidential - Do Not Share Web技術の変化とパフォーマンス改善の歴史 Keywords: Front-end libraries,
Performance issues, HTTP Archive
7 Confidential - Do Not Share Web Front-end の歴史は巨大化と抑制の繰り返し 2006
2010 2015 2019 jQuery Backbone.js, AngularJS React, Redux TypeScript, TDD 動的なサイトが 簡単に作れる! 「現在の状態」が 管理できる! 状態の「更新」がき れいに書ける! 巨大なコードベー スでも見通しが良く なる!
8 Confidential - Do Not Share HTTP Archive データ転送量の中央値はPCで4倍、モバイルで7倍!
9 Confidential - Do Not Share まとめ パフォーマンスを保ちつつ立派なアプリケーションを提供しなければ行けないという のが今日の Web
エンジニアの課題
10 Confidential - Do Not Share Client / Server Side
Rendering Keywords: Front-end libraries, Performance issues, HTTP Archive
11 Confidential - Do Not Share CSR: Client Side Rendering
• 2014 年ぐらいからのトレンド 「今年、一押しの技術」まであと 5年…! • 問題① React ライブラリが通信容量を圧迫する • 問題② React の実行はパフォーマンスの問題を起こす React などの vDOM ライブラリで HTML をクライアントで動的に生成
12 Confidential - Do Not Share SSR: Server Side Rendering
サーバーで動かせば良いよね → SSR: Server Side Rendering • サーバーのリソースはお金や工夫で解決できる • HTML だけ送信すればリソース送信量も減少する(こともある) 「SSR と CSR の中間的な方策はたくさんある」 今日は3つの既存手法と今年イチオシの手法を紹介する React のレンダリングはサーバーサイドでもできる
13 Confidential - Do Not Share ブラウザでのパフォーマンスを測るメトリクスについて TTFB (Time to
First Byte) → 最初のリクエストを帰ってくるまで FP (First Paint) → 最初の描画が発生するまで FCP (First Contentful Paint) → メインコンテンツが描画されるまで TTI (Time to Interactive) → ユーザー操作を受け付けるまで ページが表示される段階ごとにいろいろな指標(メトリクス)がある
14 Confidential - Do Not Share Static SSR • サーバーの責務は
静的ファイルの送信 だけ • サーバーは置いてあるコードを返すだけなので FCP は最速 • JS がないので当然 TTI は最速 • すべてのページをデプロイのたびに作り直さないといけないので コンテンツが限定的でないと使えない デプロイ時に HTML/CSS をビルドしてリソースを静的配信する
15 Confidential - Do Not Share CSR with Pre-rendering •
サーバーの責務は 静的ファイル の送信だけ • 速い FP • 遅い FCP & TTI App Shell だけをプリレンダリングして、ユーザー固有部分は CSR
16 Confidential - Do Not Share SSR with Hydration •
サーバーでは HTML 作成のため • クライアントではイベントハンドラの登録のため Pros/Cons • 速い FCP • 遅い TTI → 見えてるのに反応しない → 不気味の谷 サーバーとクライアントで2度レンダリングを行う
17 Confidential - Do Not Share 今年、一押しの技術 Keywords: Progressive Hydration
18 Confidential - Do Not Share Streaming SSR • 最速の
FP 速い FCP • 不気味の谷はバレにくくなったがデータ転送量はむしろ増加 HTML をチャンクに分割して送信し徐々にレンダリングする
19 Confidential - Do Not Share Progressive Hydration • ビューポートに入った要素だけ処理をダウンロードして実行する
◦ 現在は IntersectionObserver と dynamic import を用いて Hacky な実装ができる ◦ 今年中には React が標準対応しそう • TTI の減少 • データ送信量の絶対量が減少 見えてる要素だけ Hydration (イベントハンドラの登録)を行う
20 Confidential - Do Not Share まとめ
21 Confidential - Do Not Share それぞれの方法に長所・短所がある サービスごとに適切な方法を選ぼう
22 Confidential - Do Not Share 画像をはめた説明のときに使用してください。 ここにタイトルをいれる Rendering on
the Web | Web | Google Developers https://developers.google.com/web/updates/2019/02/rendering-on-the-web
23 Confidential - Do Not Share Thank you! About Mercari
About me 新卒採用中! 通年インターン募集中! @karszawa