1. 第20回 【WordPress】 プラグイン EWWW Image Optimizer
環境:Debian 9 php 7.0 Apache 2.4.25 MySQL 5.7 Cocoon
目的①:画像ファイルを圧縮する
目的②:「次世代フォーマットでの画像の配信」「webp」ファイル
- 非常にシンプルなプラグインです。
- 取り立てて説明するほどのプラグインかと問われると、少し言葉につまるところがあります。
- 他のプラグインなどと連携させることによって、強力な味方になると思います。
- 気持ちいいほどに「メディアファイル」を管理することができるようになります。
- 「WordPress」本体に負担をかけることなく、「Google Cloud Storage」から配信できるようになります。
- 「PageSpeed Insights」の「次世代フォーマットでの画像の配信」「webp」ファイルで配信ができるようになります。
色々なツールを連携させることで理想的な「メディアファイル」の配信ができます。ですから、改めて「EWWW Image Optimizer」から書いていこうと思います。
- 第20回 WordPressプラグイン 「EWWW Image Optimizer」
- 第21回 WordPressプラグイン 「Media Library Folders for WordPress」
- 第22回 GCP 「Google Cloud Storage」のバケット作成と権限の設定方法
- 第23回 WordPressプラグイン 「WP-Stateless」と「GCS」を連携させ、メディアファイルをGCSから配信させる方法
- 第24回 今まで設定したメディアファイル連携やhttps設定を行うとどうなるか、ついでにサイトアイコン変更
個人的にはシンプルで優れたプラグインだと思います。
- WordPressEWWW Image Optimizer
インストール、有効化
- WordPressEWWW Image Optimizer
設定
- WordPressEWWW Image Optimizer
「WebP」後
1.1 EWWW Image Optimizer インストール
- 「WordPress管理画面」「プラグイン」「新規追加」で「EWWW Image Optimizer」をを検索します。
- 「今すぐインストール」をクリックして、次へ進みます。
1.2 有効化
- 「有効化」をクリックして、次へ進みます。
1.3 EWWW Image Optimizer 設定
- 「ベーシック」タブは初期設定のまま次へ進みます。
以下、読み飛ばしていい部分です。
有料版は「API」など設定することにより非常に強力な圧縮をすることができるようになるそうですが、私は利用したことがありません。
- 私の場合ですが、こういった説明書きをする場合、
強力に圧縮されている「jpg」ファイルと、
ある程度圧縮されている「png」ファイルと、
両方を比較してしまうと、
「劣化した jpg ファイルは単純に見にくい」。そしてイライラする。
「そんなこと、別にさー」と思うかも知れませんが、「WordPressを非常に多く壊しては、作り直してきた結果」そう思うんです。
色々な設定方法、みんな備忘録として公開しています。「自分の備忘録」があると、最初から設定する時、物凄く助かるんですよ。特に、私は2つのサイトで「ロードバランサーを利用する時、利用しない時」の両方の設定があります。
「異なる設定部分が多く」迷います。
WordPressを作り直す時、自分の備忘録を見ます。「劣化した jpg ファイル」より「png ファイル」の方がイライラしません。自分がそう思うんだから、自分以外の人が見たって同じことを思うはず、と考えています。
- ここまで余談です。
1.4 変換タブ設定
- 「変換」タブで、「コンバージョンリンクを非表示」を✔して、設定を保存します。
ここから先は、参考程度のものです。「webp」ファイルで配信する時に必要な設定をメモ書きにしています。
1.5 WebPタブ「ロードバランサー利用なし」
- 「Google Cloud Storage」の「バケット名」:「gcs.tohyo2020.org」
- 「WP-Stateless」の設定で「Bucket Folder」:「media」
- 下記画面、「例、https://storage.googleapis.com/gcs.tohyo2020.org/media/」と設定しています。
- 下記画面は、「WebP」ファイルが配信できる準備が整った「緑色のWebP」が表示されています。
- 「自分のWordPress本体からWebPファイルを配信する」場合は、私のとは異なる設定が必要です。設定例は、下記画面の部分でも記載があるので参考にしてみてください。
1.6 WebPタブ「ロードバランサー利用あり」
- 完全なる「独自ドメイン」での配信ができます。
- 2つのサイトの実際のロゴ画像のURLで違いが分かります。また、サイトアイコン(ファビコン)の違いも確認できます。
- 「https://storage.googleapis.com/gcs.tohyo2020.org/media/polling2020_icon.png」
「Google Cloud Storage」から配信されていますが、外部から見ても「Google Cloud Storage」から配信されているかどうか分かると思います。
- サイトアイコン(ファビコン)も「Google Cloud Storage」のものです。
- 「https://www.tokyo2020unofficial.com/media/sakura_2020.png」
「Google Cloud Storage」から配信されていますが、外部から見たら「Google Cloud Storage」から配信されているかどうか分からないと思います。
- サイトアイコン(ファビコン)も「Tokyo2020 unofficial 非公式」のものです。
1.7 さいごに
「Cloud Flare」を利用することも考えたことがあります。
- 「独自ドメイン」っぽい配信になります。厳密に言うと、
「例、https://cdn.tokyo2020unofficial.com/media/sakura_2020.png」といったサブドメインでの配信になります。
- サイトアイコン(ファビコン)は「独自のロゴ」にはなりません。
結論として、「サブドメイン配信。」かつ「サイトアイコンにはならない。」という配信になる「Cloud Flare」を利用することを見合わせました。
狐につままれる。
ちなみに、「Tokyo2020 unofficial 非公式」のロゴの「URL」ですが、
- 「https://www.tokyo2020unofficial.com/media/sakura_2020.png」
ところが、もう一つ「URL」が存在します。
- 「https://storage.tokyo2020unofficial.com/media/sakura_2020.png」
どちらも、同一の「ロゴファイル」で、「Google Cloud Storage」の「バケット」から配信されています。
- 「storage.tokyo2020unofficial.com」を「Google Cloud Storage」の「バケット名」に設定していて、「異なる2つのURLから同一のファイル」が配信されています。
最初に気づいた時、狐につままれたような感じでした。
【コメント】 ※「メールアドレス不要」