PageSpeed Insightsで公開前のMANIARUを改善する

PROJECT 001 — MANIARUを作る。

STEP 13 / PERFORMANCE

STEP 12までで、公開後の運用に必要なバックアップとセキュリティを確認した。次に、公開前のMANIARUをPageSpeed Insightsで測定し、表示や操作に問題がないかを確かめた。

目標は数字を100にすることではない。測定結果から直すべき問題を見つけ、公開前に対応する必要があるかを判断するために使った。

公開前のサイトをモバイルで測定する

最初はモバイルで測定した。結果は次のとおりだった。

項目 スコア
Performance 78
Accessibility 95
Best Practices 100
SEO 92

主な指標は、FCP 1.1秒、TBT 120ms、Speed Index 2.7秒、LCP 5.6秒、CLS 0だった。

スコアだけを見るのではなく、PageSpeed Insightsが具体的に何を問題として示しているかを確認した。

タップターゲットの問題を修正する

Accessibilityでは、タップターゲットに関する問題が見つかった。スマートフォンでリンクやボタンを操作するときに、タップできる領域に改善の余地があるという内容だった。

これは実際の使いやすさに関わる明確な指摘だったため、公開前に修正することにした。

問題のあるタップ領域を調整したあと、同じようにモバイルで再測定した。

修正後にもう一度測定する

再測定の結果は次のようになった。

項目 修正前 修正後
Performance 78 78
Accessibility 95 100
Best Practices 100 100
SEO 92 92

主な指標は、FCP 1.2秒、TBT 130ms、Speed Index 2.6秒、LCP 5.6秒、CLS 0だった。

Accessibilityは95から100になり、修正した内容が結果にも表れた。一方で、Performanceは78のままだった。測定ごとに一部の数値はわずかに変わっているため、個々の数字だけで単純に良し悪しを決めないようにした。

SEOの指摘は別のSTEPで対応する

SEOが92だった原因として、meta descriptionが設定されていないことも確認できた。

この点はSTEP 11 / SEO & OGPで対応している。この記事では設定内容を繰り返さず、PageSpeed Insightsの確認から次の作業につながった項目として記録しておく。

LCP 5.6秒を残したまま公開する判断

LCPは5.6秒で、改善の余地が残っていた。ただし、「PageSpeedの数字を100にするまで公開しない」という判断にはしなかった。

この時点で、サイトは正常に表示されていた。CLSは0で致命的なレイアウトシフトはなく、Accessibilityで見つかった明確な問題も修正できた。パフォーマンスは公開後も測定しながら改善できる。

そのため、LCPは公開後の改善項目として残し、公開を止める問題とは判断しなかった。

数字ではなく、次の判断に使う

今回PageSpeed Insightsを使って分かったのは、100点を取ることより、指摘から実際の問題を見つけることの方が重要だということだった。

問題を見つけ、直し、再測定する。それでも残った項目については、公開を止めるほどか、それとも運営しながら改善できるかを考える。

数字は完成度を決める答えではなく、次の判断をするための材料として使うことにした。

次のSTEP 14では、MANIARUを公開してよいか、最後の確認を行う。


STEP 12 / SECURITY & BACKUPPROJECT 001 | STEP 14 / FINAL CHECK →