PHPPlugins
ワードプレスでの企業サイト制作では画像をカスタムフィールドで入力するケースがほとんどです。プラグインAdvanced Custom Fieldsは画像を扱う際にも非常に便利ですが、サイズの取り扱いなどについてはやや注意点もあります。実際にサンプル画像をアップロードして確認してみたいと思います。
2019年3月5日
Advanced Custom Fieldsの画像の扱い方
アップロード画像の基本的な読み込み方
それではサンプル用に「発芽したばかりの大根の芽」の画像を用意しました。これを実際にアップロードしてみたいと思います。
original1.jpg（1500px/997px）をアップロードしますと以下のようにオリジナル画像に加えて4種類の画像が生成されます。これがワードプレスの標準仕様です（画像サイズをメディア設定画面で変更していない場合）。
実際に使用する場合は以下のように記述します。プラグインAdvanced Custom Fieldsの設定は以下のようにしています。
// フィールド名 img
// フィールドタイプ 画像
// 返り値 配列
<img class="lazy" data-original="<?php $image = get_field('img'); echo $image[sizes][large]; ?>">
↓
original1-1024×681.jpgが読み込まれる
<img class="lazy" data-original="<?php $image = get_field('img'); echo $image[sizes][medium_large]; ?>">
↓
original1-768×510.jpgが読み込まれる
<img class="lazy" data-original="<?php $image = get_field('img'); echo $image[sizes][medium]; ?>">
↓
original1-300×199.jpgが読み込まれる
<img class="lazy" data-original="<?php $image = get_field('img'); echo $image[sizes][thumbnail]; ?>">
↓
original1-150×150.jpgが読み込まれる
上記のように[large]、[medium_large]、[medium]、[thumbnail]の指定に従って対応するサイズの画像が読み込まれます。オリジナルの元画像を呼び出す指定はこの記述方法にはありません（返り値をURLにしてthe_field()またはecho get_field()にすれば元画像が読み込まれます）。
1024px未満の画像をアップロードするときは注意
それでは今度は少し小さいoriginal2.jpg（1000px/665px）をアップロードしてみます。最大サイズが1024px未満の場合は1024pxのサイズが生成されません。同様に元画像が768px未満ですと768pxのサイズも生成されません。ではこの場合の記述はどうなるでしょうか。
<img class="lazy" data-original="<?php $image = get_field('img'); echo $image[sizes][large]; ?>">
↓
original2.jpg（元画像）が読み込まれる
<img class="lazy" data-original="<?php $image = get_field('img'); echo $image[sizes][medium_large]; ?>">
↓
original2-768×510.jpgが読み込まれる
<img class="lazy" data-original="<?php $image = get_field('img'); echo $image[sizes][medium]; ?>">
↓
original2-300×199.jpgが読み込まれる
<img class="lazy" data-original="<?php $image = get_field('img'); echo $image[sizes][thumbnail]; ?>">
↓
original2-150×150.jpgが読み込まれる
ここで注意したいのは最大サイズが1024px未満のアップロード画像に対して[large]と指定すると元画像が読み込まれてしまうということです。元画像を軽量化していない場合はかなり重たい画像が読み込まれることになります。これはSEO対策上、あまり好ましくありません。
それでは今度はoriginal3.jpg（1024px/681px）をアップロードしてみます。
結果は上記の通りで1024pxだった元画像が改めて1024pxにリサイズされています。サイズは変わりませんが容量が非常に軽くなっていることがわかります。
このような一連の確認作業から言えることは、実際に画面に表示するサイズに合わせて[large]、[medium_large]などの適切な記述をしておけば、アップロードする画像をリサイズする必要はあまりないということです。むしろ、1024px未満にリサイズしてしまったことで元画像が読み込まれるようなケースはできるだけ避けたいところです。
企業サイトの場合は画像のアップロードをクライアントが行うことも多いですから、このあたりは運用上の注意点として伝えておくべきことかもしれません。
画像の軽量化性能を圧縮サイトと比較
それではワードプレスの標準の画像圧縮性能も確認してみます。先ほど使用しましたoriginal3.jpgを使用して、有名な画像圧縮サイトで軽量化したものと比較してみましょう。結果は以下のようになりました。
■元画像original3.jpg（647KB 1024px/681px）を軽量化した結果
ワードプレスの標準リサイズ => 150KB
Compressor.io => 139KB
TinyPNG => 111KB
※全てサイズは元画像と同じ1024px/681px
ワードプレスの軽量化性能は標準でもかなり高いと言えますが、大きな画像を多用するようなサイトでは画像圧縮系のプラグインなどを使用してより軽量化してもいいかもしれません。
以下にご参考までに実際に軽量化した画像を掲載します。単体でそれぞれを見ればどの画像も特に問題は無いと思います。ただし、並べて比較しますと圧縮率が一番高かったTinyPNGの画像が他の画像より劣化が大きいかなとは思います。
以上で「Advanced Custom Fieldsの画像取り扱い注意点」の解説を終わります。
Tweet
