WordPressの読み込みファイルを調べていると、使っているテーマとは別の名前が付いたCSSとJavaScriptが見つかりました。Envo Extraというプラグイン由来で、合計は93,906バイト。すぐ削除するのではなく、844個のCSSルールとJavaScriptの対象を調べ、実際に必要だった1つの指定だけを子テーマへ移して停止しました。
Envo Extraが3ファイルを読み込んでいた
対象になったファイルは次の3本です。
| ファイル | サイズ |
|---|---|
gutenberg.css | 67,799 B |
style.css | 24,846 B |
envo.js | 1,261 B |
| 合計 | 93,906 B |
僕のサイトはTwenty Sixteenの子テーマです。それなのに、ファイル名やCSSクラスを見ると .envo-* やWooCommerce向けの指定が大量に含まれていました。
WordPress.orgにあるEnvo Extraの説明を確認すると、Enwoo、Envo Royal、EnvoThemes製のWooCommerceテーマ向けの拡張プラグインです。FAQにも、それらのテーマでのみ機能すると明記されています。
つまりTwenty Sixteenでは、本来の機能が動く組み合わせではありません。それでもフロント画面ではCSSとJavaScriptが読み込まれていました。
844ルール中、このサイトに当たったのは4個
ただし、「別テーマ用だから全部無意味」と決めつけるのも危険です。テーマ固有のクラス以外に、body や a のような一般的なセレクタが含まれていれば、現在の見た目に影響している可能性があります。
そこで、Envo ExtraのCSSルール844個を、実際のページ要素と照合しました。該当したのは4系統です。
ここでいうCSSルールとは、「どの要素に、どんな見た目を適用するか」をひとまとめにした設定です。たとえば a { color: blue; } は、すべてのリンクを青くする1つのCSSルールです。
{ } の中に色や余白など複数の指定が書かれていても、それ全体で1ルールとして数えます。844は行数やファイル数ではなく、Envo Extraの2つのCSSファイルに含まれていたルールの総数です。
| ルール | 調査結果 |
|---|---|
body のExtendify用CSS変数 | Extendifyを使っておらず参照元なし |
.is-layout-flex | WordPress本体と同じ指定で重複 |
.gutenberg-on article { margin-bottom: 0 } | 親テーマ側の後勝ちルールに負けており無効 |
a, a:hover, a:focus | text-decoration は親テーマと重複。transition: 0.3s だけ有効 |
見た目に残っていたのは、リンクの色が0.3秒かけて変わる transition だけでした。
「トップへ戻る」はこのプラグインの機能ではなかった
途中で一度、判断を間違えました。右下に表示される「トップへ戻る」ボタンは、Envo Extraが出していると思い込み、代替のCSSとJavaScriptを作りかけました。
しかし、envo.js の中身を読むと、操作対象は #return-to-top と .woo-float-info です。僕のサイトにはどちらの要素もありません。
実際のボタンは .page_top_btn で、スタイルを提供していたのはVK All in One Expansion Unitでした。つまり、Envo ExtraのJavaScriptはこのサイトでは何もしていませんでした。
見た目が似た機能や、プラグイン名から受ける印象だけで所有者を決めると、不要な代替実装を作ってしまいます。要素のclassやidと、CSS・JavaScriptの参照先を突き合わせる必要があります。
必要な1宣言だけ子テーマへ移した
プラグイン停止後もリンクの動きを維持するため、子テーマの style.css に次の指定を追加しました。
a,
a:hover,
a:focus {
transition: 0.3s;
}Envo Extra側には text-decoration: none もありましたが、Twenty Sixteenが同じ指定を持ち、しかも後から読み込まれていたため、引き継ぐ必要はありません。
追加したCSSはコメントを含めて474 B増えました。プラグインはすぐ削除せず、まず「停止」にして様子を見る運用にしています。問題が見つかったときに戻しやすくするためです。
予測と実測が1バイト単位で一致した
停止後は envo.js、gutenberg.css、gutenberg-on の痕跡がすべて0件になりました。
| 項目 | 変更前 | 変更後 |
|---|---|---|
| 自サイトのCSS/JS | 35本・868,223 B | 32本・774,791 B |
| 削減量 | 93,432 B |
計算は 93,906 − 474 = 93,432 B です。事前の予測と変更後の実測が1バイト単位で一致しました。
表示面も数値で確認しています。
- リンクの
transitionは0.3秒を維持 - 「トップへ戻る」ボタンは存在し、
position: fixedのまま - ソーシャルアイコンは
display: flexを維持 - 記事下余白は112pxのまま
- コンソールエラーは0件
記事下の余白が変わらなかったことで、Envo Extraの margin-bottom: 0 はもともと負けていた、という事前の判断も裏付けられました。
プラグイン数ではなく、実際の仕事を見る
WordPressの高速化では「プラグインを減らす」とよく言われます。しかし、個数だけでは判断できません。1つで大きな処理をするプラグインもあれば、必要な機能を効率よく提供するプラグインもあります。
今回問題だったのは、プラグインが入っていたこと自体ではなく、このテーマでは機能していないのに約94 KBを全ページで読み込んでいたことです。
逆に、たった1行でも今の見た目へ効いている指定があれば、何も確認せず止めると変化します。僕は「公式の対象テーマを確認する」「CSSが当たる要素を数える」「JavaScriptが探す要素を確認する」「必要な指定だけ引き継ぐ」「停止後に数値で確認する」の順で整理しました。
プラグインを削除するかどうかは、そのあとで決めれば十分です。
参考リンク
