Webサイトの表示速度は、読者の体験品質を左右し、コンテンツの価値を伝えるための重要な基盤です。先日、当サイトのパフォーマンスが看過できない水準にあることを認識し、対策を講じることにしました。本記事では、解決策を模索する中で行った思考のプロセス、つまり、ある計画を立て、それに疑問を抱き、最終的に異なる結論へ至った経緯を記録します。
最初の計画：各分野で評価の高いプラグインの組み合わせ
問題解決にあたり、最初に検討したのは、各機能分野で評価の高いプラグインを組み合わせて役割を分担させるアプローチでした。具体的な構想は以下の通りです。
- 画像の最適化: 画像圧縮技術に定評のある「ShortPixel」
- コードの最適化: クリティカルCSSの自動生成機能を持つ「Autoptimize Pro」
- キャッシュ基盤: サーバー標準提供の「LiteSpeed Cache」
それぞれの専門ツールを連携させれば、包括的な高速化が実現できるという考えです。この方法は、多くの情報源で推奨されており、一見すると合理的でした。
計画の再検討：管理の複雑性と潜在的リスク
しかし、この計画を具体化する過程で、いくつかの懸念点が浮上しました。それは、高速化という目的を達成するための手段が、過度に複雑化しているのではないかという問いです。
複数の高性能なプラグインを併用することは、同時に以下のようなリスクを内包する可能性があります。
- 機能の競合: あるプラグインの設定が、意図せず別のプラグインの処理と干渉し、サイトの表示不具合を引き起こす可能性。
- 設定の複雑化: 各プラグインが持つ多数の設定項目をすべて理解し、全体として協調させるための管理コストの増大。
- 将来の保守性: WordPress本体、あるいは利用中のいずれかのプラグインが更新された際に、現在の設定バランスが維持できなくなる可能性。
思考を深めるにつれ、手段の管理に要する労力が、本来の目的である「高速化」そのものよりも大きくなりつつあると感じました。より本質的で、持続可能な解決策を再考する必要がありました。
解決策の転換：LiteSpeed Cacheへの集約と一つの例外
そこで、一度視点を変え、利用しているサーバー環境の標準機能に立ち返ることにしました。当サイトはLiteSpeedサーバー上で稼働しており、標準で「LiteSpeed Cache」プラグインが提供されています。
このプラグインは、キャッシュ機能に留まらず、CSS・JavaScriptの最適化、クリティカルCSS生成、オブジェクトキャッシュといった包括的な最適化機能を備えています。当初外部プラグインに委ねようとした役割の多くを、サーバーと一体開発されたこのプラグイン一つで担えることが分かりました。これにより、管理のシンプルさを確保し、機能競合のリスクを排除できるという結論に至りました。
ただし、一つの機能については、あえて別の選択をすることにしました。それが「画像最適化」です。
画像最適化に関する再考：自動化から手動管理への移行
LiteSpeed Cacheにも、ShortPixelと同様に、画像を自動で最適化する機能は含まれています。これらのプラグインによる自動処理は、手間を削減する上で非常に有効です。しかし、検討を重ねる中で、「自動化の画一性」に対する疑問が生まれました。
画像はコンテンツの質を決定する重要な要素です。それを一律のルールで自動圧縮するのではなく、一枚一枚の特性に合わせて、自身の目でプレビューを確認しながら最適な圧縮率やフォーマットを決定したいと考えるようになりました。
この思想を実現するツールとして、最終的にGoogleが開発したブラウザベースの画像最適化ツール「Squoosh.app」を選択しました。Squooshを選んだ理由は以下の通りです。
- 品質の直接管理: 圧縮後の画質をリアルタイムでプレビューしながら、納得のいくポイントまで細かく調整できます。
- プラグイン不要: WordPressにプラグインを追加することなく、サイトを軽量に保てます。必要な時にブラウザで作業が完結します。
- 先進フォーマットへの対応: JPEGやPNGに加え、より圧縮率の高いWebPやAVIFといった次世代フォーマットへの変換も手軽に行えます。
- ローカル処理: 画像はサーバーにアップロードされず、使用しているブラウザ内で処理が完結するため、セキュリティの観点からも安心できます。
Squooshには画像を一枚ずつしか処理できないという制約がありますが、これを「手間」と捉えるのではなく、「品質を担保するための意図的な工程」と位置づけました。
まとめ
今回の経験を通じて、Webサイトの高速化という課題に対し、「LiteSpeed Cacheによる全体最適化」と「Squooshによる手動での画像最適化」という構成が、現時点での最適解であるという結論に至りました。
問題解決のプロセスは、必ずしも単一の思想で完結するものではありません。当初は複数の専門ツールを組み合わせる「ベスト・オブ・ブリード」戦略を検討し、次に管理のシンプルさを求めて「純正プラグインへの一本化」を考えました。そして最終的に、機能ごとに「自動化」と「手動管理」のどちらが本質的な価値に繋がるかを問い直し、両者を使い分けるという、より解像度の高いアプローチにたどり着きました。
この記事で共有した思考の変遷が、同様にサイトのパフォーマンスと品質の両立に悩む方々にとって、一つの参考となれば幸いです。
ここまでやって、PageSpeed Insights（https://pagespeed.web.dev/）の数値は、41⇒60へ改善いたしました。しかし、60までの改善。これはワードプレスのテンプレートが原因でした。次の記事で説明いたします。
コメント