SSRを検討する際にSSGも検討しませんか？ / ssr or ssg

https://javascript-fes.doorkeeper.jp/events/90894
#jsfes

[2019-06-03更新] 発表版のPDFに差し替え。事例部分は詰めが甘かったため削除。内容をブラッシュアップしてどっかのLTで喋りたいと思います

Transcript

1. SSRを検討する際に SSGも検討しませんか？ 2019.06.01 初夏のJavaScript祭 / @mottox2
2. スライドはSpeakerDeckにアップします。 忘れてなければTwitterにツイートしています。 @mottox2 or #jsfes をチェック！
3. フロントエンドエンジニア（Web/iOS） Gatsby, Gridsome maintainer エンジニアの登壇を応援する会 write-blog-every-week お仕事 OSS mottox2 @ ؿٔ٦ٓٝأ8FCؒٝآص، ⾃⼰紹介 コミュニティ https://mottox2.com
4. OSS活動 SPA系のサイトジェネレーターをやっています
5. 技術書典への参加
6. #jsfes 今⽇登場するフレームワーク Nuxt.js Next.js Gridsome Gatsby 国内で⼈気の⾼いVueアプリケーショ ンのためのフレームワーク。ユニバー サルなSSRや、静的ファイルの⽣成に 対応。 Reactアプリケーションのためのフレー ムワーク。ユニバーサルなSSRや、静的 ファイルの⽣成に対応。 Vue製のモダンなサイトジェネレー ター。早くて堅牢でSEOに強いサイト が作れる。 React製のモダンなサイトジェネレー ター。早くて堅牢でSEOに強いサイト が作れる。海外で⼈気。
7. #jsfes JavaScript好きですか？
8. #jsfes SPA好きですか？
9. #jsfes （私は）SPA⼤好き • Scope付きのCSS • コンポーネント志向なViewの組み⽴て • DOMのdiff操作からの開放 • サーバーサイドと密結合になりにくい • TypeScriptとの親和性が⾼い • 開発環境を⽴てやすい
10. #jsfes でも、リリースで迷うことが多くない？
11. #jsfes SPAのリリースでつきまとう課題 • レンダリングされるまで空⽩なので相対的に遅く感じる • モバイル端末ではレンダリングが遅くなりがち • OGPを動的に変更できない。 • titleタグ、metaタグ周りの話。 • SEO上不利 • Google I/O 2019の発表されたクローラーの改善で解消されそう？
12. #jsfes SPAのリリースでつきまとう課題 • JSが実⾏されるまで空⽩なページが表⽰される。 読み込み直後 マウント後 JS読み込み&実⾏
13. #jsfes SPAのリリースでつきまとう課題 • vue-cliで作成したプロジェクトのビルド結果 読み込むまで画⾯は真っ⽩ metaタグを⼀通りしか設定できない
14. #jsfes 今までのレガシーなWebアプリケーションでは当 たり前だったことが、単独では達成できない ⼀⾔で⾔うと？
15. #jsfes そこで選択肢に上がるのが SSR(Server Side Redering)
16. #jsfes SSR（Server Side Rendering） • この発表ではSSRをクライアントでもSPAとして動作するものとします。 • サーバー上でレンダリングを⾏い、結果をHTMLとして返す。 配信 サーバー クライアント Node.js レンダリング
17. #jsfes SSRの最⼩コード • Nuxt.jsやGridsomeでも使われているvue-server-rendererの最⼩コード • ClientでSPAとして動作しない。 • 『Vue SSRガイド』 • https://ssr.vuejs.org/ja/ • 実⾏結果 『Vue SSRガイド』より
18. #jsfes ユニバーサルなSPA • Nuxt.js/Next.jsはユニバーサル（サーバーでもクライアントでも動作す る）なSPAになるように整備してくれている。 サーバーサイドで⽣成したHTML クライアントでマウントしてSPAとして動作 JS読み込み&実⾏ ユーザーの操作を受け付け始める 単純なHTMLとして振る舞う
19. #jsfes • Next.jsの抜粋です。 • zeit/next.js ユニバーサルなSPAのサンプル
20. #jsfes SSR、銀の弾丸ではない • サーバーが必要になる • 考えることが増える • CPU負荷が⼤きく⼤量の処理をさばけない • 回避するためにキャッシュをうまく利⽤する • サーバーとクライアントでの処理の出し分けが必須 • ある程度の知識が必要
21. #jsfes [optional] キャッシュの話 • ⼀度レンダリングした結果を使い回すため、CDN等のキャッシュを利⽤し て配信する。 • この際に、ユーザー情報を含めると他のユーザーの情報が⾒えてしまうこ とがあるので、サーバーサイドではユーザー情報を扱わない。 • クライアントで認証＋認証を伴うAPIを叩く。 • キャッシュの削除タイミングを考える必要がある。
22. #jsfes もう⼀つの選択肢 SSG（Static Site Generator）でPrerendering
23. #jsfes Prerendering • 「事前にSSRを⾏って静的ファイル化しておけば、本番では配信するだけ でOK」というアプローチ。 • これらのアプローチを⾏っているのがGatsby/Gridsome、Next.js/ Nuxt.jsのPrerendering。 • これらもユニバーサルなSPAとして振る舞う。 • Prerenderingでもサーバーとクライアントでの処理の出し分けの理解は 必要。 • Build-time server-side rendering（Gridsome公式サイトより）
24. #jsfes Prerendering • 事前にファイルを⽣成 • ⽣成例: mottox2/website
25. #jsfes PrerenderingとSSR • 事前に結果を⽣成しておくか、アクセスごとに処理を⾏うかの違い • ⼀旦、SSRのキャッシュは忘れて 1. アクセスを受けて、HTMLを⽣成・配信 2. クライアントはHTMLを受け取って表⽰ 3. JSがマウントされSPAとして動作 Prerendering SSR 1. 事前に⽣成したHTMLを配信 2. クライアントはHTMLを受け取って表⽰ 3. JSがマウントされSPAとして動作
26. #jsfes • 『Rendering on the Web』が詳しい • https://developers.google.com/web/updates/2019/02/rendering-on-the-web PrerenderingとSSR
27. #jsfes Prerenderingの利点 • 考えることが減る。 • サーバー不要。 • キャッシュの削除を考えなくてもよい。 • コストが低い。
28. #jsfes Prerenderingの⽋点 • コンテンツが更新される度にビルドする必要がある。 • 事前にすべてのページに対してHTMLを⽣成する必要がある。 • ページ数が多くなればなるほどビルド時間が伸びる。 • 更新頻度が⾼いとCDNキャッシュの恩恵を受けにくい。 • 他⾔語の静的サイトジェネレーターと⽐べて遅い。 • ユニバーサルなSPAとして動作するコードを出⼒するため。
29. #jsfes Prerenderingの⽋点 Version 1 Version 2 Build & Deploy コンテンツの更新 通知(webhook) 過去 未来 ⇐ コンテンツの反映までのタイムラグ コンテンツの量/ページの量に依存する • コンテンツ更新までの時間軸（反映までに時間がかかる）
30. #jsfes 結局どっちを選べばいいの？
31. #jsfes どっちを選べばいいの？ • コンテンツの更新を瞬時に反映する必要が ある。 • コンテンツが頻繁に更新される • コンテンツ量が多い • SSRに対しての理解度が⾼い • 札束で殴る⽤意がある • 多少遅くても許容できる • コンテンツの反映に時間があっても許容で きる。 • コンテンツが更新される頻度が低い。 • コンテンツが数百程度 • 考えることを減らしたい • ホスティング料⾦を減らしたい • パフォーマンスにこだわりたい Server Side Renderingを選ぶとよいケース Prerenderingを選ぶとよいケース => コンテンツの性質によって決める。許容できるのであればSSGが楽。
32. #jsfes どっちかに振り切る必要はない • Prerendering→SSRへの移⾏について • Next.jsやNuxt.jsのようなSSRフレームワークでは、Prerenderingも機能 として提供されている。 • リリース時はPrerendering、サービスが成⻑したらServer Side Renderingという⼿も • Gatsby => Next.js、Gridsome => Nuxt.jsの移⾏もあり。 • 個⼈的にはおすすめ • ルーティングのルールなど共通部分はあるので⼯数は重くない。
33. #jsfes どっちかに振り切る必要はない • Prerenderingでもアプリケーションになりうる • サイトジェネレーターというとブログやコーポレートサイトを連想させる が、GatsbyやGridsomeはアプリケーションフレームワーク。 • 例) Gatsbyで出来たECサイト https://store.gatsbyjs.org/
34. #jsfes どっちかに振り切る必要はない • すべてのページにPrerenderingを適⽤する必要はない • クライアントのみでレンダリングする箇所の検討も • これだけでも早く感じる JS読み込み&実⾏ サーバーでは共通部分だけ表⽰ クライアントでAPIを叩いて表⽰
35. #jsfes どっちかに振り切る必要はない • どちらとも利⽤しない選択肢 • 基本的にはB向けのSaaSで、⼀部だけシェア画⾯が必要 • どちらとも利⽤せず、ClientSideだけでレンダリング • シェア⽤画⾯だけ別に⽣成する⽅法などが考えられる。 • SPA技術で作る必要はない。
36. #jsfes まとめ • SSRは考えることが多いのでPrerenderingで要件が達成できるのであれば おすすめ。 • 「真っ先にSSR！」じゃなくてPrerenderingも考えてみてください。 ショートカットできる箇所も多い。
37. #jsfes Thank you! 2019.06.01 初夏のJavaScript祭 / @mottox2