SSRを避けるためにやっていること / ssr-alternative

297a42b94a1bda236982ec1cd81089b6?s=47 mottox2
December 09, 2019

SSRを避けるためにやっていること / ssr-alternative

Ginza.js #7の発表資料です

297a42b94a1bda236982ec1cd81089b6?s=128

mottox2

December 09, 2019
Tweet

Transcript

  1. 2019.12.9 Ginza.js #7 / @mottox2 SSRを避けるために やっていること SSRに頼らない表⽰速度の改善

  2. アプリケーションエンジニア Gatsby, Gridsome, Next.js, etc JSXでpptxをつくるライブラリを作ってます お仕事 Watching mottox2 @

    ؿٔ٦ٓٝأ8FCؒٝآص، ⾃⼰紹介 ひとこと
  3. #ginzajs

  4. #ginzajs 最近のお気もち SSRやりたくない ‣ 管理するサーバーが増える ‣ サーバーレスであってもHostingとFunctionで密結合なデプロイが必要 ‣ キャッシュを考え始めると沼、対応しないとTTFBが死ぬ。 ‣

    他の⼈に引き継ぎにくい、採⽤要件が上がる ‣ (トラブルで呼び出されても対応できないタイミングがある) ‣ 等々…
  5. #ginzajs SSR/SPA ‣ 今⽇話す「SSR」はSPAの⽂脈でhydrationしているやつ ‣ Next.jsやNuxt.jsでやってる感じのやつ

  6. #ginzajs そもそもなぜSSR/SPAだったのか? ‣ SSRを考慮するケース。だいたいConsumer向き。 ‣ ステート管理が複雑ではない ‣ ユーザー⽬線ではSPAである必然性は低い ‣ 開発者体験(DX)をあげるために選択されがち

    ‣ ただし、SEO・SNS⽤にレンダリングを⾏いたい ‣ 表⽰速度的にもSSRがほしい ‣ SPAを選ぶことで得られる開発者体験・それによる提供速度の向上 ‣ はたして、SSRを⼊れたときに同じことを⾔えるか?
  7. #ginzajs SPA+SSRは開発者体験・開発速度に寄与するか? ‣ SSRによって開発体験が悪くなっているように思える。 ‣ DXを上げるためにSPAを選択したのにSSRで消耗していない?全体でよくなっているのか? ‣ LaravelとかRailsで作る⽅がよい可能性すらある ‣ pjaxとかRailsのTurbolinksなど使えばページ遷移は早くできる

    DXが良い DXが悪い SPAによるDX SSRによるDX 全体としてDXはよくなっているのか?
  8. #ginzajs じゃあ、どうするか? ‣ SSRを避ければDXの良いまま開発できそう ‣ 特に開発初期、SSRを避けるためにやっていることをお話します。 ‣ フロントエンド開発基盤専任がいないプロダクト想定です。

  9. #ginzajs 解決するべき課題 1. 検索エンジン向きのSEO 2. SNS向きのOGP出⼒ 3. 表⽰速度の問題 Lambda@EdgeやPrerendering系の サービスで対応する感じ

    Googleがいい感じにやってくれるようになった
  10. #ginzajs なぜ表⽰速度? ‣ 初回訪問時の表⽰速度が問題になる ‣ よくあるindex.htmlの例 ‣ JSを読み込んで実⾏するまで真っ⽩ <!doctype html>

    <html lang="en"> <head> <meta charset="utf-8" /> <link rel="icon" href="/favicon.ico" /> <meta name="viewport" content="width=device-widt <meta name="theme-color" content="#000000" /> <meta name="description" content="Web site creat <link rel="apple-touch-icon" href="/logo192.png" <link rel="manifest" href="/manifest.json" /> <title>React App</title> <link href="/static/css/main.d1b05096.chunk.css" </head> <body><noscript>You need to enable JavaScript to r <div id="root"></div> <script><!— !! —></script> <script src="/static/js/2.6c6eb89e.chunk.js"></s <script src="/static/js/main.e41c5136.chunk.js"> </body> </html> ⼀般的なSPA HTML表⽰後 JS実⾏後
  11. #ginzajs なぜ表⽰速度? ‣ Twitterからアクセスしたときに感じるがっかり体験 ‣ 通信状況や端末の性能によるところがある ‣ B向けプロダクトでは問題になりにくい ‣ 通信制限、格安スマホなど…

    ‣ 年齢層が低いほど⽉末の環境がやばい ‣ 2回⽬以降ならキャッシュを効かせられる ‣ C向けサービスだと初回訪問が重要 ‣ キャッシュやServiceWorkerで2回⽬は早くできる ‣ 「俺のスマホでは早い」は当然。回線も端末も強いでしょ ‣ 残念ながらSSRが必要なプロダクトほど、遅い環境が多い印象
  12. #ginzajs 改善の⽅針 1. JSのサイズを減らし通信・パースの時間をへらす • Code Splitting、重いライブラリを避ける 2. 初期表⽰を早くする、早く⾒せる •

    事前レンダリング
  13. #ginzajs バンドルサイズの削減 初期表⽰の改善(1) ‣ SPAのJSは⽐較的⼤きくなりがち、jQueryとか⽬じゃないこともある ‣ 何も考えず作ったやつだど、そのままだと全ページ分のJSができる ‣ 特定のページでしか使っていないドデカライブラリが全ページに影響を及ぼす ‣

    適切なCodeSplittingを⾏うとよい ‣ Next.js、Nuxt.jsはルーティングで分けてJSを作ってくれる。 ‣ Lighthouseで「メインスレッド処理の最⼩化」が警告に出てたら注意 ‣ 重いライブラリと読み込み⽅に注意する
  14. #ginzajs HTMLのプリレンダリング 初期表⽰の改善(2) ‣ LighthouseやPageSpeed Insightのこの時間、スマホだと⻑い ‣ HTMLが空でめちゃくちゃ⻑く感じる ‣ JSが実⾏されるまえに表⽰されるHTMLを⽤意する

  15. #ginzajs HTMLのプリレンダリング 初期表⽰の改善(2) ‣ ビルド時にSPAをレンダリングしてHTMLを事前に⽤意しておく ‣ react-snapshotを利⽤する(create-react-app) ‣ Static HTML

    exportを利⽤する(Next.js) ‣ Gatsby的なアプローチ
  16. #ginzajs HTMLのプリレンダリング - 戦略 初期表⽰の改善(2) ‣ コンテンツによって⽣成される動的ページが問題。 ‣ 事前のレンダリングでコンテンツを決定できない`/posts`、`/posts/:id`のようなページ ‣

    動的に⽣成されるコンテンツに関しては、コンテンツ部分をクライアントでレンダリングを⾏う。
  17. #ginzajs HTMLのプリレンダリング - 応⽤ 初期表⽰の改善(2) ‣ プレースホルダー(Skeleton)を⼊れると更に早く感じる ‣ ただし、⼈によってはレビューで漏れがち ‣

    開発環境だと(環境がよく)気づきにくいのはわかる
  18. #ginzajs ありそうな質問 ‣ 本番でつかえるの? ‣ Next.jsアプリケーション(without SSR)で本番に⼊れました。 ‣ CDNキャッシュにのると、LighthouseのPerformanceは90点台になる。 ‣

    SEOってどうなの? ‣ ブラウザでレンダリングされたコンテンツのインデックスを確認している。 ‣ 今のところ問題なさそう。ただし、⻑期的な影響はまだわかっていない。 コンテンツのプレースホルダー
  19. #ginzajs ありそうな質問 ‣ 本番でつかえるの? ‣ Next.jsアプリケーション(without SSR)で本番に⼊れました。 ‣ CDNキャッシュにのると、LighthouseのPerformanceは90点台になる。 ‣

    SEOってどうなの? ‣ ブラウザでレンダリングされたコンテンツのインデックスを確認している。 ‣ 今のところ問題なさそう。ただし、⻑期的な影響はまだわかっていない。 コンテンツのプレースホルダー
  20. #ginzajs まとめ ‣ SSRがなくてもなんとかなるかもしれない。 ‣ ただ、トリッキーさはあるのでSSRとは別に考えることが増える。

  21. #ginzajs フレームワークに乗りたい ‣ Next.jsとかNuxt.jsがだいたい解決してくれる ‣ 雑な使い⽅してもいい感じにしてくれる ‣ 我々はうまい使い⽅を探っていき、フィードバックを送る努⼒をしたい ‣ 安易に「SSRしないから使わない」といって中を⾒ないのはもったいない!

    ‣ 巨⼈の肩に乗って楽をしよう ‣ webpack.config.jsも書かなくてもいいし ‣ 基盤部分のドキュメントを書かなくてもいいし ‣ 引き継ぎも楽 Appendix
  22. #ginzajs Next.jsの最適化に注⽬ ‣ バンドルサイズの削減が更に進んでいく流れ ‣ Next.jsはChromeチームとコラボレートしている ‣ モダンブラウザとレガシーブラウザで別バンドルを⽤意 ‣ async/awaitあたりのPolyfill

    ‣ Code Splittingのロジック変更 ‣ 今までは割合でcommons chunkを作っていたのをロジック変更 ‣ 別件でStatic HTML Export周りの改善も進みそう Appendix
  23. Thank you! 2019.12.9 Ginza.js #7 / @mottox2