「Netflix が React やめて 50% 高速化」という記事が話題なので React のそもそもの嬉しさを語ります。

11月 02, 2017 / Posted by 恩田 崇 / 0 Comments

Netflix functions without client-side React, and it’s a good thing

またまた衝撃的なニュースが飛び込んできました。Netflix が React を使うのをやめて、昔ながらのサーバーサイドレンダリングに戻して、ランディングページを 50% 高速化した、と言うものです。

結論から言えば、Netflix は React の使いどころを見誤っていたんではないか、と思います。

Isomorphic JavaScript

フロントエンド界隈では、React の Next.js をはじめとして、クライアントと同じコードをサーバーサイドの Node.js で走らせて、ロードの高速化や SEO 対策を行おう、という isomorphic な SSR アプローチが盛んです。

ですが、ブラウザと Node.js で動く isomorphic javascript を実現しようとすると、ハマりどころがたくさんあります。例えば、良くないとはされていますが、往々にして最終手段になる DOM を直接操作するような逃げ道は取ることはできません。

加えて、単純に文字列を組み立てるだけの昔ながらのサーバーサイドレンダリングと異なり、クライアントフレームワークはコンポーネントツリーや仮想DOMという中間層を組み立ててから、文字列にシリアライズする必要があるため、本質的にオーバーヘッドが大きくなります。もともとコンポーネントでビューを整理して構築することが目的のフレームワークなのに、SSR のためのチューニングを行うのは本末転倒に思えます。

その SSR はホントに必要?

猫も杓子も SSR といった最近の風調ですが、そもそも SSR はほんとに必要とされているのでしょうか?

いったん落ちついて、React のようなクライアントフレームワークを駆使する複雑な UI を持つような Web アプリケーションってどんなものか考えてみましょう。

有名どころでは、開発元の Facebook に Twitter, Slack, Feedly が React を利用しています。いずれも高度な UI を持つ SPA ですね。サイトの性格的に毎日のように使われます。タブをずっと開きっぱなしでそもそも閉じることがない、という使い方をしている人も多いでしょう。

業務システム系も複雑な UI を持ち、React が活躍する局面の多い種類の Web アプリになります。日々の業務で使うものだから、当然ながら毎日使われ、画面は開きっぱなしになっているでしょう。

毎日使えばキャッシュされる

頻繁に使われるサイトのリソースはブラウザがキャッシュします。

たしかに一番最初に使うときは、たくさんのリソースをロードするので、表示までそれなりに待つことになります。ですが、一度キャッシュに乗ってしまえば、それ以降の表示ではロードは不要です。すなわち、JavaScript の評価と実行、すなわちクライアントレンダリング処理だけが行われるだけです。

キャッシュに乗ってしまえば、それなりの規模の Web アプリであっても、今の標準的な PC であれば、最初に何か表示されるまで (First Painting) は1秒程度ですし、利用できるようになるまでにかかる時間 (Time to Interactive) も2~3秒といったところでしょうか。アプリの作りや複雑さにもよりますが、私の手元のマシンでは Slack は TTI までは5秒弱、Twitter は1秒程度といった感じです。

ServiceWorker を使えば、キャッシュ容量の少ないスマートフォンでも、確実にキャッシュさせることができます。今はまだ Android でしか利用できませんが、Safari も ServiceWorker の実装を始めています。

SEO が重要なサイト

ちなみに、SEO が重要なサイトではどうでしょうか。

多くの場合はコンテンツが中心となりインタラクティブな要素は限られます。高度な UI を持つ Web アプリ系であっても、Google の検索結果 (SERP) に上位表示されてほしいのは、アプリをアピールするためのランディングページで、もちろんコンテンツがメインです。

昔ながらの文字列を組み立てるサーバーサイドレンダリングで十分です。インタラクティブな処理もクライアント側でゼロから DOM を組み立てる React や Angular ではなく、html にメタ情報を追加して動的な処理を実現できる Vue.js が、アーキテクチャの点でも軽量さでも適切な選択になるでしょう。

さらなる高速化や SEO 効果を期待するなら、AMP という選択肢もあります。Google に掲載される新しいページの 77% は AMP だ、という情報もあります。

結論

月並みで当たり前の結論になってしまいますが、こういったキャッチーなニュースに踊らされず、自分たちの Web サイト、 Web アプリの性質にあわせた、適切なアプローチを取りましょう、ということですね。

とはいえ、フロントエンドがますます高機能していく現在、React がその強みを発揮するような場面はむしろ増えている、と言うべき、というのが MMJ の結論です。

 

Tags: , , , ,