こんにちは、Webエンジニアの永井です。
今回は、何かと便利な next/image ですが、特に効果がなかった話です。
某ECサイトのプロジェクトで、パフォーマンス改善の一環としてnext/image の導入を検討しました。ですが、パフォーマンス計測で思うような改善が見られなかったので、導入は見送りになりました。
その際の、導入検討の経緯から改善されなかった原因などをまとめていきます。
導入検討の経緯
PageSpeed Insightsでパフォーマンスを計測すると、「改善できる項目」として以下の点が挙げられていました。
こちらを見ると、画像関連の指摘には全て 「`<img>` の代わりに `next/image` の使用」が推奨されています。そのため、next/image を導入して試してみることになりました。
パフォーマンス計測の結果
next/imageを導入した際のパフォーマンス計測の結果を見ていきます。
計測にはPageSpeed Insights APIを利用して、導入前後で10回ずつ計測した値の平均を比較しています。
SCORE | FCP(s) | TTI(s) | SI(s) | BT(ms) | TLCP(s) | CLS | |
|---|---|---|---|---|---|---|---|
Before Average | 61.6 | 0.3 | 2.98 | 2.68 | 289 | 3.41 | 0.025 |
After Average | 60.5 | 0.3 | 2.64 | 3.25 | 256 | 4.02 | 0.0325 |
After - Before | -1.1 | 0 | -0.34 | 0.57 | -33 | 0.61 | 0.0075 |
全体的に誤差の範囲で特に改善されていないことが分かります。
パフォーマンス改善されなかった原因
next/imageの主な機能として、「画像の最適化」や「画像の遅延読み込み」があります。本プロジェクトでは、過去に「画像圧縮によるファイルサイズの最適化」や「画像の遅延読み込み」といった対応を既に行っていました。そのため、next/imageによる効果が少なく、パフォーマンスの改善が見られなかったと思われます。
実際に、「導入検討の経緯」であげていた画像の指摘に関しては改善されていましたが、PSIのスコアに影響あるほどの改善ではありませんでした。
このような対応をされていない場合は、next/imageを導入することでパフォーマンスが改善し、スコアも高くなることが見込めると思います。
next/imageの使いにくい点
<img>をnext/imageに置き換えるにあたり、使いにくい点があったので合わせて紹介します。
サイズを指定する必要がある
next/imageを利用するには、事前に高さや幅といったサイズを指定する必要があります。<img>はサイズを指定しなくても画像そのもののサイズで描画してくれますが、next/imageではそれができません。
サイズを指定しないやり方もありますが、<img>と比べると実装が複雑になってしまうので、使いにくさがあります。元々のコードでサイズが指定されていればスムーズに置き換えることができますが、そうでない場合は置き換えが大変になります。
本プロジェクトの場合、パフォーマンスが改善されない点に加えて、実装が複雑になってしまう点も考慮して見送りとなりました。
まとめ
next/imageでパフォーマンスが改善されなかった話を紹介しました。
新規プロジェクトであれば、導入しても基本的に問題ないと思いますが、リファクタリングなどで導入を検討されている場合は、これまでの実装内容を踏まえ、効果があるかどうか、しっかりと検証する必要がありそうです。