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

by mottox2

Slide 1

Slide 1 text

SSRを検討する際に SSGも検討しませんか？ 2019.06.01 初夏のJavaScript祭 / @mottox2

Slide 2

Slide 2 text

スライドはSpeakerDeckにアップします。忘れてなければTwitterにツイートしています。 @mottox2 or #jsfes をチェック！

Slide 3

Slide 3 text

フロントエンドエンジニア（Web/iOS） Gatsby, Gridsome maintainer エンジニアの登壇を応援する会 write-blog-every-week お仕事 OSS mottox2 @ ؿٔ٦ٓٝأ8FCؒٝآص، ⾃⼰紹介コミュニティ https://mottox2.com

Slide 4

Slide 4 text

OSS活動 SPA系のサイトジェネレーターをやっています

Slide 5

Slide 5 text

技術書典への参加

Slide 6

Slide 6 text

#jsfes 今⽇登場するフレームワーク Nuxt.js Next.js Gridsome Gatsby 国内で⼈気の⾼いVueアプリケーションのためのフレームワーク。ユニバーサルなSSRや、静的ファイルの⽣成に対応。 Reactアプリケーションのためのフレームワーク。ユニバーサルなSSRや、静的ファイルの⽣成に対応。 Vue製のモダンなサイトジェネレーター。早くて堅牢でSEOに強いサイトが作れる。 React製のモダンなサイトジェネレーター。早くて堅牢でSEOに強いサイトが作れる。海外で⼈気。

Slide 7

Slide 7 text

#jsfes JavaScript好きですか？

Slide 8

Slide 8 text

#jsfes SPA好きですか？

Slide 9

Slide 9 text

#jsfes （私は）SPA⼤好き • Scope付きのCSS • コンポーネント志向なViewの組み⽴て • DOMのdiﬀ操作からの開放 • サーバーサイドと密結合になりにくい • TypeScriptとの親和性が⾼い • 開発環境を⽴てやすい

Slide 10

Slide 10 text

#jsfes でも、リリースで迷うことが多くない？

Slide 11

Slide 11 text

#jsfes SPAのリリースでつきまとう課題 • レンダリングされるまで空⽩なので相対的に遅く感じる • モバイル端末ではレンダリングが遅くなりがち • OGPを動的に変更できない。 • titleタグ、metaタグ周りの話。 • SEO上不利 • Google I/O 2019の発表されたクローラーの改善で解消されそう？

Slide 12

Slide 12 text

#jsfes SPAのリリースでつきまとう課題 • JSが実⾏されるまで空⽩なページが表⽰される。読み込み直後マウント後 JS読み込み&実⾏

Slide 13

Slide 13 text

#jsfes SPAのリリースでつきまとう課題 • vue-cliで作成したプロジェクトのビルド結果読み込むまで画⾯は真っ⽩ metaタグを⼀通りしか設定できない

Slide 14

Slide 14 text

#jsfes 今までのレガシーなWebアプリケーションでは当たり前だったことが、単独では達成できない⼀⾔で⾔うと？

Slide 15

Slide 15 text

#jsfes そこで選択肢に上がるのが SSR(Server Side Redering)

Slide 16

Slide 16 text

#jsfes SSR（Server Side Rendering） • この発表ではSSRをクライアントでもSPAとして動作するものとします。 • サーバー上でレンダリングを⾏い、結果をHTMLとして返す。配信サーバークライアント Node.js レンダリング

Slide 17

Slide 17 text

#jsfes SSRの最⼩コード • Nuxt.jsやGridsomeでも使われているvue-server-rendererの最⼩コード • ClientでSPAとして動作しない。 • 『Vue SSRガイド』 • https://ssr.vuejs.org/ja/ • 実⾏結果『Vue SSRガイド』より

Slide 18

Slide 18 text

#jsfes ユニバーサルなSPA • Nuxt.js/Next.jsはユニバーサル（サーバーでもクライアントでも動作する）なSPAになるように整備してくれている。サーバーサイドで⽣成したHTML クライアントでマウントしてSPAとして動作 JS読み込み&実⾏ユーザーの操作を受け付け始める単純なHTMLとして振る舞う

Slide 19

Slide 19 text

#jsfes • Next.jsの抜粋です。 • zeit/next.js ユニバーサルなSPAのサンプル

Slide 20

Slide 20 text

#jsfes SSR、銀の弾丸ではない • サーバーが必要になる • 考えることが増える • CPU負荷が⼤きく⼤量の処理をさばけない • 回避するためにキャッシュをうまく利⽤する • サーバーとクライアントでの処理の出し分けが必須 • ある程度の知識が必要

Slide 21

Slide 21 text

#jsfes [optional] キャッシュの話 • ⼀度レンダリングした結果を使い回すため、CDN等のキャッシュを利⽤して配信する。 • この際に、ユーザー情報を含めると他のユーザーの情報が⾒えてしまうことがあるので、サーバーサイドではユーザー情報を扱わない。 • クライアントで認証＋認証を伴うAPIを叩く。 • キャッシュの削除タイミングを考える必要がある。

Slide 22

Slide 22 text

#jsfes もう⼀つの選択肢 SSG（Static Site Generator）でPrerendering

Slide 23

Slide 23 text

#jsfes Prerendering • 「事前にSSRを⾏って静的ファイル化しておけば、本番では配信するだけでOK」というアプローチ。 • これらのアプローチを⾏っているのがGatsby/Gridsome、Next.js/ Nuxt.jsのPrerendering。 • これらもユニバーサルなSPAとして振る舞う。 • Prerenderingでもサーバーとクライアントでの処理の出し分けの理解は必要。 • Build-time server-side rendering（Gridsome公式サイトより）

Slide 24

Slide 24 text

#jsfes Prerendering • 事前にファイルを⽣成 • ⽣成例: mottox2/website

Slide 25

Slide 25 text

#jsfes PrerenderingとSSR • 事前に結果を⽣成しておくか、アクセスごとに処理を⾏うかの違い • ⼀旦、SSRのキャッシュは忘れて 1. アクセスを受けて、HTMLを⽣成・配信 2. クライアントはHTMLを受け取って表⽰ 3. JSがマウントされSPAとして動作 Prerendering SSR 1. 事前に⽣成したHTMLを配信 2. クライアントはHTMLを受け取って表⽰ 3. JSがマウントされSPAとして動作

Slide 26

Slide 26 text

#jsfes • 『Rendering on the Web』が詳しい • https://developers.google.com/web/updates/2019/02/rendering-on-the-web PrerenderingとSSR

Slide 27

Slide 27 text

#jsfes Prerenderingの利点 • 考えることが減る。 • サーバー不要。 • キャッシュの削除を考えなくてもよい。 • コストが低い。

Slide 28

Slide 28 text

#jsfes Prerenderingの⽋点 • コンテンツが更新される度にビルドする必要がある。 • 事前にすべてのページに対してHTMLを⽣成する必要がある。 • ページ数が多くなればなるほどビルド時間が伸びる。 • 更新頻度が⾼いとCDNキャッシュの恩恵を受けにくい。 • 他⾔語の静的サイトジェネレーターと⽐べて遅い。 • ユニバーサルなSPAとして動作するコードを出⼒するため。

Slide 29

Slide 29 text

#jsfes Prerenderingの⽋点 Version 1 Version 2 Build & Deploy コンテンツの更新通知(webhook) 過去未来 ⇐ コンテンツの反映までのタイムラグコンテンツの量/ページの量に依存する • コンテンツ更新までの時間軸（反映までに時間がかかる）

Slide 30

Slide 30 text

#jsfes 結局どっちを選べばいいの？

Slide 31

Slide 31 text

#jsfes どっちを選べばいいの？ • コンテンツの更新を瞬時に反映する必要がある。 • コンテンツが頻繁に更新される • コンテンツ量が多い • SSRに対しての理解度が⾼い • 札束で殴る⽤意がある • 多少遅くても許容できる • コンテンツの反映に時間があっても許容できる。 • コンテンツが更新される頻度が低い。 • コンテンツが数百程度 • 考えることを減らしたい • ホスティング料⾦を減らしたい • パフォーマンスにこだわりたい Server Side Renderingを選ぶとよいケース Prerenderingを選ぶとよいケース => コンテンツの性質によって決める。許容できるのであればSSGが楽。

Slide 32

Slide 32 text

#jsfes どっちかに振り切る必要はない • Prerendering→SSRへの移⾏について • Next.jsやNuxt.jsのようなSSRフレームワークでは、Prerenderingも機能として提供されている。 • リリース時はPrerendering、サービスが成⻑したらServer Side Renderingという⼿も • Gatsby => Next.js、Gridsome => Nuxt.jsの移⾏もあり。 • 個⼈的にはおすすめ • ルーティングのルールなど共通部分はあるので⼯数は重くない。

Slide 33

Slide 33 text

#jsfes どっちかに振り切る必要はない • Prerenderingでもアプリケーションになりうる • サイトジェネレーターというとブログやコーポレートサイトを連想させるが、GatsbyやGridsomeはアプリケーションフレームワーク。 • 例) Gatsbyで出来たECサイト https://store.gatsbyjs.org/

Slide 34

Slide 34 text

#jsfes どっちかに振り切る必要はない • すべてのページにPrerenderingを適⽤する必要はない • クライアントのみでレンダリングする箇所の検討も • これだけでも早く感じる JS読み込み&実⾏サーバーでは共通部分だけ表⽰クライアントでAPIを叩いて表⽰

Slide 35

Slide 35 text

#jsfes どっちかに振り切る必要はない • どちらとも利⽤しない選択肢 • 基本的にはB向けのSaaSで、⼀部だけシェア画⾯が必要 • どちらとも利⽤せず、ClientSideだけでレンダリング • シェア⽤画⾯だけ別に⽣成する⽅法などが考えられる。 • SPA技術で作る必要はない。

Slide 36

Slide 36 text

#jsfes まとめ • SSRは考えることが多いのでPrerenderingで要件が達成できるのであればおすすめ。 • 「真っ先にSSR！」じゃなくてPrerenderingも考えてみてください。ショートカットできる箇所も多い。

Slide 37

Slide 37 text

#jsfes Thank you! 2019.06.01 初夏のJavaScript祭 / @mottox2