ノロノロ魔改造WPサイトでも一旦リセット|市販テーマを“壊さず”高速化・標準化した記録
自身で運営するサイトは、大なり小なりですが「魔改造」っぽいことが起きやすいです。結果として「表示が遅い」ということが起き、閲覧している人にとってはイライラ。運営している人にとっては機会損失につながる場合もあります。
Soleilのウェブサイトも若干遅く(7.0にした時に診断してますが遅かった)、ちゃんと標準化しておかないとな。と思っておりましてSWDのサービスとして記録を作ってみました。実際のサービスもこのような流れになるので、ご紹介します。
目次
症状の確認
通常はお申し込みいただいた後、悩まれている相談をもとに、初回診断(診断のみの場合は¥3,300税込)を行うかどうか?をご相談します。今回は自身のサイトなので、そのまま初回診断へ。
症状としては、表示や動作などは問題のある箇所はなく、セキュリティに関しても大きく邪魔をしている様子もありませんでしたが、表示までの時間がとてもかかる(重い)症状が気になるという感じです。
申し込みとか欲しいのにアクセスが重いのは機会損失になるので何とかしないとな。
調査はあくまで予測ですが、サーバーやデータベースやプラグインなどを最初に疑います。しかし大丈夫そう。ただPageSpeed Insightsでは、LCP・TBTが長い(680msくらい)と出てたので、たぶんJSの読み込みで時間食ってるんじゃないかな?という見立てです。

診断をより深めるためにサイトの中を見ると、functions.phpを経由してjsを全てのページに読み込む仕様になってました。これ自体(functions.phpで読み込むこと)は決して悪いことじゃなく、通常のサイト運用では結構やってます。どのページでも必要なスクリプトならそう読み込むことが正解なわけですし。
ただ、全部が全部読み込んでOKっていうのはちょっと違くて、全く使わないのにJSとかCSS読み込んでんだよなあ、ってなるとブラウザで見る時どうしても読み込みにかかる時間が重なってしまい、結果として遅くなるということです。

診断結果
調査及び診断をした場合(初回診断後)、下記のような診断書兼お見積書をお渡しします。診断後はそのまま修復依頼をいただくことも可能ですし、お付き合いのある制作会社様や自身で行う場合の指標として活用いただくことも可能です。今回は「うちのサイト」なのでそのまま進みます。



今回お見せしている診断書は、最後までやった後の診断書なので「作業ログ」や「完了報告」も載っちゃってますが、通常ご発注いただいた時のみ症状について詳しく記載するようになります。
修正説明①:読み込み箇所分解
まずは、JSをfunctions.phpで全部読み込みます!をやめにします。次のステップに向けて、JSが何だったか?をもう一度切り分けるために、どこで何が動いているか?をJSの役割と照らし合わせて分担を整理しました。ファイルはバラバラでしたが、読み込みを統一していたので、条件分岐(決まったページの時だけ読み込まれなさい!という命令)をこの時点で行いました。
| JS | 主な役割 |
|---|---|
| アニメーション系JS | テーマ依存じゃないJSがあって、それはCSS装飾にアニメーションをつけるために書いたJSでした。 |
| フォーム系JS | プラグインのフォームにもうちょっと利便性のある機能をつけるために、 制御系のJSを書いた時のJSでした。 |
| reCAPTCHAのJS | セキュリティつけた時に追記したやつでした。 |
| ダッシュアイコンのJS | WPのダッシュアイコンっていうアイコン機能をログインしなくても使えるようにする時に必要で書いたJSでした。 |
| その他JS | 必要に応じて追加したのがあと3つほどありました。 |
修正説明②:mu-plugin化
テーマやプラグイン依存になりがちな部分でも、より「運用」に近い機能(CF7制御系・reCAPTCHA制御・Site Kit連携など)は運用層に寄せるためにmu-plugin(必須プラグイン)に分化します。
こうすることで、市販テーマによくあるテーマのアップデートにも強く耐えられます。自作テーマの場合でも、セキュリティや保守、表示のキモになる部分をテーマ側で、運用に近い部分をmu-pluginに分けることで、機能の責任分化ができて更新しやすく、事前のエラーチェックの場合にも原因追及が楽になります。
修正説明③:画像のWebp化
わかりやすいことですが、画像を軽くします。でもここまで①・②まで詰めていけば「あとは画像を軽くするだけだぜ!」っていう状態になるので、かえってわかりやすかったりします。functions.phpを魔改造している場合なんかだと、画像の形式変えて軽くしても表示事故を起こしたりします。okkane-。
軽量化の中で、今まで更新してきておざなりだった「プログラムの責任の所在」を一緒に整理することで、物質的な整頓だけでなく心理的な整頓にもなるので、これから先の運用でも不安が減りそうです。特にAPIとかで外のサイトと繋がることが多くなっていく中では、「APIという配線がちゃんと整備・配備されている」というのはメンテナンスにおいては最重要です。
「高速化」より大事だったこと
今回重要だったのは、単にスピードスコアの点数を上げることではなく、“問題箇所を切り分けられるWordPress”へ戻すことでした。いわば初期状態から、WP側にとっての最適化された状態にどこまで近づけるか?という感じです。
でもせっかくなんで、点数の結果としては、こんな感じ
| 項目 | Before | After |
|---|---|---|
| FCP(何か見えるまでの時間) | 1.2秒 | 0.7秒 |
| LCP(メインコンテンツ表示までの時間) | 3.7秒 | 2.8秒 |
| TBT(JSによってブロックされた時間) | 680mm秒 | 120mm秒 |
| CLS(表示がズレで誤タップ?って数) | 0 | 0 |
TBTの激減ぶりに感涙ですな。これによって、単純に表示速度も速くなったし、それ以上に責任分化されたので、今後の運用も安心というわけです。
ここまでで作業としては完了となり、診断書兼報告書に症状・実施内容・今後の対策や気をつけた方がいいかもしれないということをまとめて、現場納品をいたします。
通常のサービスでは、エラーからの復旧や特急お直しを除き、ローカル環境にて作業を行いサイトに納品させていただきますので、HPが表示されない期間なく、安心してサイト健康診断・改善対策サービスをご利用いただけます。
まとめに
WPサイトは使い続けていく中で重くなったりすることが多く、プラグインを止めても、更新しても、サーバー情報と睨めっこしても解決しないこともあります。SWDではWPの標準化を軸に改善点を提案し、ご了承いただいた後に安全に作業をすすめご満足いただけるように心がけております。
- 自社サイトも重い
- 何が原因か分からない
- pluginを減らしても改善しない
- 更新が怖い
そんな場合は、まず健康診断からご相談ください。


この記事へのコメントはありません。