ユーザー体験を向上させるサーバーサイドレンダリングJavaScript — 歴史と利点
この記事は Goodpatch Advent Calendar 2017 — Qiita 22日目の記事です。
Web業界にいる方なら、ここ数年の間で一度は「サーバーサイドレンダリング」という言葉を聞いたことがあるかもしれません。これは一体どのような技術を指しているのでしょうか？
この記事ではその簡単な概要と、実際にプロジェクトに導入して実感した利点と注意点を紹介します。
サーバーサイドレンダリングとは？
「サーバーサイドレンダリング」とは一体なんでしょうか？混乱を避けるため厳密な説明は避けますが、少なくとも私たちWebデベロッパーのここ数年の文脈においては、 「(元々ブラウザ上でしか動かなかった)JavaScriptをサーバー内部で実行して、HTMLを生成すること」を指します。
これによって初期表示の際にユーザーが待たされることがなくなるなどのメリットがあります。
また、以下は「サーバーサイドレンダリング」とほとんど同じ意味で使われることが多いです:
- ユニバーサルJavaScript
- アイソモーフィックJavaScript
以降の説明では、よりその性質を端的にあらわしている「アイソモーフィックJavaScript」という言葉を使っていきます。
アイソモーフィック(Isomorphic) とは、「同型の」という意味で、同じJavaScriptのコードがサーバー(Node.js)とクライアント(ブラウザ)両方で実行されることを意味します。
アイソモーフィックJavaScriptの歴史
Isomorphic JavaScript — Wikipediaによると、最初にこれらの言葉が登場したのは2011年頃だったようです。その頃はまだサーバーサイドレンダリングに必須のNode.jsも登場して間もなかったので、まだまだ実用的ではないなという印象でした。
しかし2015年頃に、金融系サービスのPaypalが エンジニアブログでNode.jsを本番運用していることを発表するなど、徐々にその実用性が注目されていき、またそのためのフレームワークも開発されていきました。同時期にAirbnbもフロントエンド開発にアイソモーフィックJavaScriptを採用していることをスライドで公開しています。
現在はNode.jsも仕様が以前より安定し、主なフロントエンドフレームワークである Angular, Vue.js, React もサーバーサイドレンダリングを積極的にサポートするなど、以前よりもずっと開発がしやすくなっています。
アイソモーフィックJavaScriptの利点
アイソモーフィックJavaScriptの利点は以下の様なものです(Airbnbのスライドから意訳して引用):
• パフォーマンス — 初期ロード時間
• SEO — クロールされやすいシングルページアプリケーション
• 柔軟性 — サーバー/クライアント両方で動くコード
• メンテナンス性 — ロジックの重複を低減
SEO
SEOに関しては、以前は「クローラーはJavaScriptによって生成されたWebページを正常にロードできないから」という理由で重要視されることが多かったですが、2015年にGoogle がGoogle公式ブログで以下のように発表するなど、あまり問題ではなくなってきています(とはいえ、その当時は対応が完璧ではなかったこともあり、SEOを改善するために様々なハックを施す必要がありました)。
Today, as long as you’re not blocking Googlebot from crawling your JavaScript or CSS files, we are generally able to render and understand your web pages like modern browsers.
パフォーマンス
現在ではむしろ、初期レンダリングが各個人のブラウザではなくサーバーサイドで行われることで初期表示が早くなり、ユーザー体験が改善されることの方が重要でしょう。
JavaScriptのコードの量( = 複雑性)は、大きな画像をWebページに挿入する場合とは比較にならないほど初期レンダリングにクリティカルな影響を与えます。
開発効率の向上
また、開発者の視点からすると、開発効率が上がることも大きな利点です。重複したロジックを低減できることはもちろん、 CSS Modules を導入できたり、 MVCパターンで言うところのViewの部分をフロントエンドが一貫して担当することで、MVC各機能の独立性が増し、クリティカルパスが発生しにくくなるなど、様々な利点があります。
実際、ここ一年で私が関わった関わった3つのプロジェクトのうち、2つでSPAによる開発とし、さらにそのうちの1つをアイソモーフィックJavaScriptで開発しましたが、バックエンドはAPIを返すだけでよくなったためロジックやパフォーマンスチューンに集中することができ、フロントエンドはバックエンドの組み込みやテンプレートの準備などを待たずに開発ができるようになりました。
また、アイソモーフィックJavaScript(SPA)を使用する場合は、ほとんどの場合Vue.jsやReactのようなフレームワークを導入することとなるため、結果的にフロントエンドのコードがコンポーネント単位で独立し、長期的な保守性も向上しました。
アイソモーフィックJavaScriptの注意点
多くの利点があるアイソモーフィックJavaScriptですが、採用に当たっていくつか注意しなければいけない点があります。
- 情報量 — 日本語の情報が少ない
- 堅牢性 — エラーハンドリングやテストなどが必須に
- サーバー — Node.jsをサポートしたサーバー
日本語情報の少なさ
以下は Google Trendsの検索ボリュームの比較です。日本語での検索ボリュームの少なさが目立ちます(「server side rendering」は検索ボリュームが大きすぎるなどの理由で除外しました)。
堅牢なコードの重要性
最も注意しなければならないポイントは堅牢性でしょう。
アイソモーフィックJavaScriptは、サーバーサイドの一部をフロントエンドが担当することになるため、一言で言えばフロントエンドのカバーする範囲が従来よりも広くなります。
従来のWebアプリケーションでは、仮にエラーハンドリングをしなかったとしてもそのセッション中のアプリケーションが停止するだけで済みましたが、アイソモーフィックJavaScriptでは、フロントエンドのエラーの影響がサーバー全体に及ぶ可能性があります。
例えばGETパラメーター( http://example.com/?param=fooの ?param=foo の部分)によって挙動を変えるアプリケーションがあった場合、パラメーターから受け取った値を適切に処理しなければ、サーバー全体に関わるセキュリティリスクになりえます。
エラーハンドリグやサニタイズ、単体テスト、セキュリティに関わる処理は別途用意したAPIサーバーを通じて行い、JavaScript側に機密情報を含む処理を実装しないようにするなど、今までよりも多くのことができるようになった分、より多くのことに気つけなくてはなりません。
Next Step
次回はどのようにアイソモーフィックなWebアプリケーションを構築していくのか、実際のコードを交えて紹介したいと思います。
フィードバック・感想がありましたらコメントまたは @Sundaycrafts までいただければと思います。
Thank you for reading😃
