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

297a42b94a1bda236982ec1cd81089b6?s=47 mottox2
June 01, 2019

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

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

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

297a42b94a1bda236982ec1cd81089b6?s=128

mottox2

June 01, 2019
Tweet

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