
最近のWordPressは記事作成支援のブロックエディタが優秀。画像を記事中に埋めるときちんとサイズ別に送信するようになっているので狭い画面向けに小さいサイズの画像が送信できる。これは送信データ量と転送遅延の低減につながるので好ましい。
ブロックエディタ(Gutenbergエディタ)を使ってメディアライブラリから画像を選んで記事に入れるだけ。とっても簡単だけど個人的には大嫌い。
1 2 3 4 5 6 7 8 9 10 11 12 13 | <figure class="wp-block-image size-large">
<img loading="lazy"
width="1024"
height="682"
src="https://example.com/wp-content/uploads/2022/06/hoge-1024x682.jpg"
alt="画像の説明"
class="wp-image-199"
srcset="https://example.com/wp-content/uploads/2022/06/hoge-1024x682.jpg 1024w,
https://example.com/wp-content/uploads/2022/06/hoge-300x200.jpg 300w,
https://example.com/wp-content/uploads/2022/06/hoge-768x512.jpg 768w,
https://example.com/wp-content/uploads/2022/06/hoge.jpg 1040w"
sizes="(max-width: 1024px) 100vw, 1024px" />
</figure>
|
ブロックエディタで画像を挿入した場合の画像タグ(HTML)の出力例。ここでは見やすいよう13行に分けているが、実際は1〜3行で出力される。本来はsrcで指定される画像がブラウザで表示されるが、srcsetが指定されている場合はそちらが優先。この例ではスマホのような狭画面では300wで指定された画像が、もう少し幅広のブラウザだと768wで指定された画像が、ブラウザのウィンドウ幅が1024px近くまたはそれ以上であれば1024Wで指定された画像が出力される。
「がとらぼ」の中の人はHTML手書き派なのでブロックエディタは性に合わない。旧来のエディタ、それも「ビジュアルエディタ」ではなく「テキストエディタ」を使っている。できるだけ単純化するようにしているので皆が思うほどはHTMLタグを書くことはない感じ。
で、画像タグも単純化して書きたいので
<img src="/dir/imagefile.avif" width="1200" height="1000" alt="画像説明" />
のようにしたい。間違いが少なくて済むし。srcsetで複数の画像のURLを書くのは手間だしコードの視認性が悪くなるし間違いの元。
しかし、この書き方だと大きなサイズの画像があると必ずその大サイズの画像が送信されることになるのでPageSpeed Insightsでの評価が僅かに下がる。画像サイズや数にもよるかとは思われるが微妙に1点とか2点ほど削られることになり100点が取れないことが増える。PageSpeed Insightsで100点取れなくてはならないという訳では全くないが気分が良くない。
ケースによっては100点を得られることもあるが、画像のように「適切なサイズの画像」という指摘は間違いなく食らうことになる。
そこで、WordPressのテキストエディタでは <img src="/dir/画像大.avif" width="1200" height="1000" alt="画像説明" /> の様に 書いてWordPressのデータベースに保存。ページ表示時にそれを読み出して「自動変換」して <img src="/dir/imagefile.avif" width="1200" height="1000" alt="画像説明" srcset="/dir/画像小.avif 320w, /dir/画像中.avif 640w, /dir/画像大.avif 800w" /> の様に出力させたい。
WordPressで使用しているテーマのfunctions.phpに追加/wordpress-path/wp-content/themes/your-theme/functions.php
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 | function bny_img_srcset_attachments( $content ) {
$buf = '<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body>';
$buf .= $content;
$dom = new DOMDocument();
@$dom->loadHTML($buf, LIBXML_HTML_NODEFDTD | LIBXML_NOERROR);
foreach ($dom->getElementsByTagName('img') as $node) {
$nodes[] = $node;
}
if (isset($nodes)){
foreach ($nodes as $node) {
$nsrc = $node->getAttribute('src');
$nwidth = $node->getAttribute('width');
if (!$node->hasAttribute('srcset')) {
if(strpos($nsrc,'wp-content/uploads') === false){
$exten = '.' . pathinfo($nsrc, PATHINFO_EXTENSION);
$srcset = str_replace ($exten , "-320$exten", $nsrc) . ' 320w, ';
$srcset .= str_replace ($exten , "-640$exten", $nsrc) . ' 640w, ';
if ($node->hasAttribute('width')) {
$srcset .= $nsrc . ' ' . $nwidth . 'w';
}
$node->setAttribute('srcset', $srcset);
if ($node->hasAttribute('width')) {
$sizeval = '(max-width: 360px) 320px, (max-width: 680px) 640px, ' . $nwidth .'px';
$node->setAttribute('sizes', $sizeval);
}
}
}
}
}
unset($nodes);
$buf = preg_replace('/^\<html\>.*?\<body\>/', '', $dom->saveHTML());
$buf = preg_replace('/\<\/body\>.*?\<\/html\>\n/', '', $buf);
return $buf;
}
add_filter( 'the_content', 'bny_img_srcset_attachments', 10, 2 );
|
記事本文(HTML)をXMLのDOMとして読み込みimgタグにsrcset属性を付けるという処理。単純な文字列の置換だとどうしてもヘンに漏れる可能性があるのでXMLの要素に属性を付ける方が確実(と思っている)。
ただし、記事本文の中でタグの閉じ忘れがあると勝手に補完されることがあるので注意。
通常は補完されて困ることはないだろうが意図的にイレギュラーなコードにしていると勝手に補完されて造り手の意図と違う表示になる。造り手のミスで不完全なXML(HTML)になっていた場合でも望まれない箇所で補完されることでレイアウト崩れが発生する可能性も無くはない。
2022年9月11日修正:
上のPHPコードで一部修正を行いました。WordPress標準が出すのを真似たsizesを付けていたところ、PageSpeed Insightsではサイズの最適化がなされていないという評価になることがあったので画面幅が360px以下であれば320w用、画面幅が680px以下であれば640w、それ以上であれば元の画像幅というクドい指定にした。元の画像幅が360px, 680px以下である可能性もあるだろうが問題無いはず。
もちろん、少サイズ, 中サイズの画像は別途用意する必要がある。ImageMagickが入っているシステム用のスクリプトを用意した。
img_small.sh (新規)1 2 3 4 5 6 7 8 9 10 11 12 13 14 | #!/usr/local/bin/bash
#引数にpathを指定して実行のこと。
if [ $# -ne 1 ]; then
echo "利用方法: $0 path" 1>&2
echo "実行するには引数としてpathが必要です。" 1>&2
exit 1
fi
#WebP - width 640px
find ${1}/ -type f -name "*.webp" -not -name '*-640.webp' -not -name '*-320.webp' -print0 | xargs -0 -I {} sh -c 'convert -resize "640x>" `echo "$(dirname "{}")/$(basename "{}") $(dirname "{}")/$(basename "{}" .webp)-640.webp"`'
#WebP - width 320px
find ${1}/ -type f -name "*.avif" -not -name '*-640.avif' -not -name '*-320.avif' -print0 | xargs -0 -I {} sh -c 'convert -resize "320x>" `echo "$(dirname "{}")/$(basename "{}" .avif).webp $(dirname "{}")/$(basename "{}" .avif)-320.avif"`'
|
$ img_small /path
これで、/pathディレクトリの中の下層にある(○○-320.webpと○○-640.webpを除く)「全て」のWebP画像が変換される。
画像があるディレクトリで実行するなら img_small ./ ね。
file.webpからfile-320.webpとfile-640.webpが出力される。もちろん元のfile.webpは残る。
また、元画像の横幅が320pxまたは640px以下の場合はサイズは変換されない。(ようにしたつもり)。
なお、ちょっと手抜きなのでディレクトリ名やファイル名に"_"(アンダーバー)が含まれるとファイル名の出力が失敗して{}-320.webpや{}-640.webpというファイル名になってしまうことがある。(スミマセン)
上の例だとWebP画像しか変換しないがもちろん拡張子を変えることでJpegやPNGにも対応する。
ImageMagickのバージョンによってはAVIF画像の扱いに対応していないかもしれないのでその場合はavifは失敗する。
なお、「がとらぼ」ではブログ用記事ではWordPressのメディアライブラリは使っていなくて/imagesディレクトリを作ってそこに独自のルールで画像ファイルを置いている。この記事はこの構成に対応している。
WordPressのメディアライブラリを使っている場合はこの記事の方法では対応が難しいかも。
まぁ、WordPressを素の状態で普通に使うならこの記事は全然参考にならないということで。
関連記事:- Content Security Policy Lv3 (CSP3)でhashによりスクリプトを許可する
- WordPress標準のXMLサイトマップ出力機能で特定カテゴリに含まれる全ての記事を除外する
- AdSense以外の有望ウェブ広告サービスThe Moneytizerを使ってみる
- WordPressの標準XMLサイトマップ機能にnoindexとPing送信の追加
- WordPress標準のXMLサイトマップ出力機能をカンタン設定 XML Sitemaps Manager
- WordPressで特定カテゴリだけの検索機能をテーマに追加
- WordPressの特定カテゴリだけを別サイトに移転
- WordPressで合理的なコメントスパム対策
- Google XML SitemapsプラグインのPing送信のバグ? のおまけ Ping送信って何?
- Google XML SitemapsプラグインのPing送信のバグ?