2025-01-30
個人用プロダクトのリプレイスとパフォーマンスへの影響
技術スタックの移行
自分用に開発しているプロダクトの開発体験およびパフォーマンスに課題がありこの度移行した。
概要
結論
移行後は、アクセシビリティ、SEO、レスポンシブ性能など、ユーザビリティ向上に貢献する改善が多数見られる。
一方、特に低速通信環境やスマートフォンでのパフォーマンススコア、リクエスト数増加など、一部デメリットも顕在化している。
LightHouse
- メリット: 移行後、アクセシビリティ、ベストプラクティス、SEOが大幅に向上。特にデスクトップでは、アクセシビリティが10ポイント以上改善。
- デメリット: スマートフォンでのパフォーマンススコアは低いままとなっている。
Web Vitals
- メリット: 4G環境では、特にモバイルでのLCPが大幅に改善（約83%改善）。一部の指標でレスポンスが向上。
- デメリット: 3G環境では、デスクトップでLCPが悪化する傾向が見られる。
転送量
- メリット: 転送データ量はほぼ一定または若干減少しているが、
- デメリット: リクエスト数やリソースサイズが増加しており、PCとスマートフォン間で差異が生じている。
※ PCの転送データがスマートフォンより少ない理由は、キャッシュや最適化の違いが考えられる。
課題
単一ファイルでの記述
- これまで、1つのTypescriptファイルにすべての処理を記述してきたため、ファイルが肥大化し管理が困難になっている。
- Reactなどのコンポーネント指向の開発手法に慣れているため、より分割された構造への移行が望ましい。
デザインシステムとの統合
- 自作中のデザインシステムに組み込めるよう、再利用性と拡張性の高いコンポーネント設計が必要である。
初期表示のパフォーマンス
- 初期表示に異常なまでの時間がかかっている。1ページ完結型の実装が、ファイル転送量の増大を招き、パフォーマンス低下の一因となっている可能性がある。
今後の拡張性
- 将来的な機能追加や改善に対応できる柔軟なアーキテクチャへの移行が求められる。
技術スタック
移行前
HTML, Tailwindcss, vite, Firebase
移行後
React, Tailwindcss, Nextjs, Firebase
移行後の変化
色の調整
今までは、Tailwind側で実装されている 50 から 900 までの色をエレメントごとにばらばらに利用していたが、このたび、自作のデザインシステムのテーマに統一した。
また、その際、既存の色構成ではモノクロトーンのコントラスト部分における表現力が著しく限定されることが判明したため、いくつかのベースカラーを拡張し、新たに作成した。
移行に伴う機能変更
既存の不満点を改善するために、新たな機能の追加や既存の関数のリファクタリングを試みた結果、これまで気づかなかった潜在的な問題が多数明らかになった。
一方で、新しいデータ構成へのマイグレーションも実現することができた。
データ取得変更における不整合データの発見
一括取得クエリで算出した合計金額が、移行前後で一致しなかった。
デバッグの結果、初期の段階で途中マイグレーションされたカラムが、明示的なWhere句導入後に取得できなくなっていたことが判明した。
従来はFirebaseのコレクション全体を呼び出していたため漏れがなかったが、今回の変更で不整合なデータが浮き彫りになった。
結果、不整合なデータを特定し、直接修正した。
ユーザー名の不整合
認証方法の変更に伴い、呼び出すカラムが変化した結果、ユーザー名に不整合が発生した。
当初、オブジェクトのキーとしてユーザー名を使用していたため、データアーキテクチャ全体のマイグレーションも検討したが、他のプロダクト部分への影響が少なかったことと、今後のカラム拡張時に対応すればよいと判断した。
そこで、一括更新スクリプトを作成し、ユーザー名を新しいカラム名に基づくデータへ更新した。
まとめ
コンポーネント設計において柔軟性を追求しすぎると、プロダクトのために開発しているにもかかわらず、Propsの受け取り方やデータ処理の美しさ、不要なレンダリングの回避といった点に固執してしまい、本来目指すプロダクト開発から逸れてしまうことがある。
より自分自身のためのプロダクトにするため、何ができるのかを明確かつ分かりやすく表現できるよう、慣れていきたい。