Primer Design Systemは、GitHubにおけるボタン、バナー、パンくずリストなどのユーザー体験を構成する基本コンポーネントを提供しています。これらのコンポーネントは、さまざまなシナリオでアクセシブルかつ柔軟で、高いパフォーマンスを発揮する必要があります。
2023年、一部のページでコンポーネント数が急速に増加し、既存のCSS-in-JSソリューションに次のような問題が生じました。
- スタイルがクライアント側で初期化されるため、初回ページの読み込みに時間がかかりました。
- スタイルの収集処理をクライアントから切り離すことで、サーバーサイドレンダリングのパフォーマンスが低下しました。
- ページ上のコンポーネント数が増えるにつれて、スタイルの更新が制御できなくなりました。
Primerチームは、クライアントとサーバーのコストをなくし、移行中にGitHubで不具合を引き起こさないソリューションを探しました。CSS Modulesにより、ローカルCSS機能を利用しながら、CSS-in-JSに期待される一定レベルのカプセル化を維持できました。スタイルはJavaScriptソースの隣にあるCSSファイルに記述し、クラス名はデフォルトでローカルスコープとなるため、クライアントやサーバーのランタイムは必要ありません。代わりに、スタイルはHTMLとともに配信されるCSSファイルにまとめられます。
移行にあたっては、各コンポーネントで次の手順を実施しました。
- 既存のスタイルをCSS Modulesに変換する新しいファイルを追加しました。
- 古いスタイルと新しいスタイルを切り替える機能フラグを使用しました。
- ビジュアルリグレッションテストにより、スクリーンショットが同一であることを確認しました。
- フラグをチーム、GitHubの従業員、そしてすべてのユーザーへと段階的に有効化しました。
このプロセスにより、早期のフィードバックを得ることができました。2024年12月には、PrimerのすべてのコンポーネントがCSS Modulesへ移行されました。
重要な理由
この変更は、コンポーネント数が増加するインターフェースでは、スタイル管理が開発者体験だけでなく、ページの読み込みやサーバー側の処理コストにも影響することを示しています。スタイルをランタイムで処理するのではなく、HTMLとともに配信されるファイルにまとめることで、クライアント側とサーバー側に追加の負荷を生じさせる処理の削減を目指しています。移行を機能フラグとビジュアルリグレッションテストによって段階的に進めたことは、広く利用されるデザインシステムにおいて、ユーザーに目に見える不具合を生じさせずに技術的な変更を試すうえで重要です。早期にフィードバックを得たことで、問題をコードのレベルだけでなく、チームやユーザーが実際に目にする画面を通じても追跡できました。ただし、この記事は、このアプローチがPrimer以外のデザインシステムでどのような結果をもたらすかについての評価を示していません。