WordPress: 表示速度加速プラグインとビジュアルコンポーザーの相性

600 207 Yuramaki

概要

WordPressの表示速度を上げようと試行錯誤したら、Autoptimize(JSとCSSの連結圧縮)プラグインと、ビジュアルコンポーザーの相性がすこぶる悪い。

設定した設定したテキスト・カラムスタイルが、ビジュアルコンポーザーの「フロントエンド編集」内で、リアルタイム表示されなくなる、paddingが消える、など。

これでは、ビジュアルコンポーザーの意味がない。

他にもブーストプラグインがあるので、そちらで代用することにした。

他にも、二、三個掛け合わせるとうまく働かないものがあるかも知れない。

その時の流れ

ワードプレスで夏期特別講座のサイト をこの数日作っていたら、どうも表示が遅い。

どうもデスクトップ表示の時にページ読み込みが3-5秒くらいかかってなんとも重く、消したくなってしまう。

申し込みサイトでこれは致命的だ。あれこれ調べて、プラグインを3つほど入れることに。

プログラムの読み込み順を変えたり(JavaScript To Footer)、画像を軽くしたり(EWWW Image Optimizer)、一回とってきたページ情報をうまく活用する設定をしたり(WP Fastest Cache)・・・。

入れて速度は上がったものの、

Visual Composer(ドラッグ&ドロップで、見たまんま簡単にページレイアウトができるプラグイン)から

見てくれのフロントエンドをいじるたびに、テキストエリアのスタイルが取れる。

ついでに、marginを60pxだなんだと設定しても、別のテキストをいじると消えてしまう。

これではビジュアルコンポーザーの意味がない。はて何が起こっているんだ?

検証。どれが悪さをしてる?

一旦新しく入れたプラグインを停め、一個一個入れ直しながら消去法で調べる。原始的にあっさり見つかる。これが良くなかった。

Autoptimize×Visual Composer

見つかったぞ。

Autoptimizeと、もともと使っているVisual Composerの相性が良くない。

余談:Visual Composerは、私が海外サイトから買ったテンプレートについてきたもの。向こうはテンプレートや余白バランスの美しさ、バックエンドの使いやすさで群を抜きます。英語でもWeb言語はみんな一緒なので導入の壁は低いです。

Autoptimizeは、CSS& JavaScript コードを連結し圧縮して、ウェブサイトの読み込みを最適・高速化するプラグイン。

私もWebはやっているものの、自分でコーディングはやらない(仕組みはわかるけれど、手に感触のないあの文字と格闘するのが大層、性に合わない)ので想像ではありますが・・・

察するに、フロントエンドを「テスト環境」でいじるたびに、CSS&JSの設定を細かく読み書きし直すためなんではないかと。

テスト環境でのテキスト・要素スタイル更新で、CSSやJSの更新と圧縮が中途半端に入るためにうまくスタイルが確定されない、読まれないわけです。

というわけで、プラグイン停止。忘れた頃にまた入れてしまいそうなので、残してはおきます。

なお、補足しておくとこのプラグインが悪いわけではなくて、取り合わせの問題なので、VCを使わない和製のテンプレートなどならいい動作をしてくれるはずです。

本題の速度は解決した

Google PageSpeed Insightsで確認したところ Autoptimizeがなくても、モバイル読み込み1秒程度、パソコンも1秒程に繰り上がったので、問題ないでしょう。よしよし。

Leave a Reply

Your email address will not be published.

jpn/eng»