JavaScriptを用いてウェブサイトのUIを構築する際によく利用されるのが「React」というFacebook製のライブラリです。ReactではJSXという記法を用いてコンポーネントを構築していきますが、その際にどういう方法でスタイリングを行うかはユーザーの手に任されています。その中でも比較的多く用いられているのが「普通のCSSを利用する方法」と、スタイル設定もJavaScript内で完結させる「CSS in JS」の2つなのですが、この2つについてパフォーマンスへの影響はどれくらい違うのかをフロントエンドエンジニアのトーマス・プストニクさんが計測してブログにまとめています。

Real-world CSS vs. CSS-in-JS performance comparison - Tomas Pustelnik's personal website

https://pustelto.com/blog/css-vs-css-in-js-perf/

プストニクさんは実際に業務で利用されているReactアプリをベースに、CSS in JS用のライブラリとして「styled-components」を利用したバージョンと、純粋なCSSを用いるものとして「Linaria」を利用したバージョンでページ表示時のパフォーマンスを比較したとのこと。計測に用いたアプリはサーバーサイドレンダリングを使っておらず、全ての要素がクライアント側でレンダリングされていると述べられています。

計測には「Home」と「Search」の2つのページが用いられています。まず、ダウンロードサイズの変化は下の画像の通りで、スラッシュが入っている項目はgzip圧縮されたサイズと非圧縮のサイズとのこと。いずれのページにおいても右列のLinariaの方がCSSのサイズは増えるものの、トータルではわずかにサイズダウンしていることが分かります。



一方、ページ内で利用されていない余分なJavaScript・CSSのコード量を表すカバレッジの指標では、Linariaの方が未使用のCSSサイズが大きく、JavaScriptと合わせてもstyled-componentsに軍配が上がる形に。



プストニクさんはGoogle製のパフォーマンス監査ツールである「Lighthouse」でも計測を行ってみたとのこと。「Home」と「Search」の2つのページにおいて3回計測して平均をとったグラフが以下で、青で示されているLinariaが両ページともにすべての項目で読み込み時間が短く、優れているという結果になっています。以下が「Home」の計測結果。



そしてこっちが「Search」の計測結果です。



計測に用いたページのうち、「Home」ページでのLighthouseの結果を開発者ツールのパフォーマンスタブで表示すると下の画像のようになります。上の3つがstyled-componentsのもので下の3つがLinariaのもの。



上の中身を要素ごとにグラフにまとめると下の画像の通りで、「Home」の計測結果を見てみると、JavaScriptのコード量が少ない分、Linariaが「Scripting」および「Total Blocking Time」で圧勝する形となりました。



もう一つのページの「Search」ページの方でも同様の結果に。



プストニクさんは、今回の結果を見たうえで、ページの表示時に実行するJavaScriptの量を増やしてしまう「CSS in JS」は、特にインターネット接続が遅かったり通信料が高額だったりするローエンドのデバイスや地域において、ウェブサイトの表示に大きな影響を与えると結論付けています。プストニクさんが次にライブラリの選定を行う際には、純粋なCSSを利用するか、今回の計測で用いたLinariaのようなビルド時にCSS in JSのコードからCSSを抽出してくれるツールを利用したいとのことです。