レ点腫瘍学ノート

2021-06-21

lazysizesに伴うCLS解消のその後の顛末

Top > 日記 > 2021年 > 6月21日 > lazysizesに伴うCLS解消のその後の顛末

以前はうまくいっていたlazysizes.jsでCLSが生じる問題の対策

以前に「Lazysizes.jsを使うとCLSが発生する問題」の記事を書いていました。画像の遅延読み込みを可能にするJavaScriptであるlazysizes.jsを使うと、CLSが生じてpagespeed insightの評価スコアが下がってしまうという問題です。

より具体的には、1x1ピクセルのサイズのスペースホルダ画像を使ってwebpなどのフォールバックをすると、画像のwidthおよびheightを指定しているのにもかかわらず画像が遅延読み込みされるまでの間に一瞬だけ正方形のサイズで画像が読み込まれてしまい、それに伴ってlayout shiftが生じてしまうという問題があるのでした。

これを解消するためにlazysizes.jsのプラグインとしてls.aspectratio.min.jsを使う事で遅延読み込み中にもファイルに正しいアスペクト比を反映させるという方法を取る解決法を見つけ出して、これでpagespeed insightでもCLSによる減点を0点に抑えるということに成功していました。詳しくはこちらをご覧ください。

lazyload(画像の遅延読み込み)するためにlazysizes.jsを使うとスペースホルダーによりCLS (Cumulative Layout Shift)が発生する問題に関して記載するページです。このサイトも遅延読み込みのためにlazysizes.jsを使ってスペースホルダーを使うとCLSが発生する問題について長らく悩まされてき

pagespeed insightの判定方法変更の影響かCLSが生じるように

しかし、WEBの高速化判定の基準は常に移り変わっていくもの。2021年5〜6月になった頃にpagespeed insightがバージョンアップされたのか、判定方法が過去28日間のフィールドデータに基づいて行われるようになりました。そして、この頃からだと思いますがls.aspectratio.min.jsを用いて画像にアスペクト比を指定するようにしてもCLSの原点が生じるようになってしまったのです。

PageSpeed Insightsが部分的でもフィールドデータをレポートするように改良 | 海外SEO情報ブログ
PageSpeed Insights のコア ウェブ バイタルに関するフィールドデータが、不十分なデータの指標があった場合でも十分なデータの指標だけはレポートするようになった。
https://www.suzukikenichi.com/blog/pagespeed-insights-field-data-is-partially-provided-for-pages-that-dont-have-sufficient-data-for-a-metric/

苦し紛れの解決策(その1)

webp fallbackに対応させるとこの画像サイズがうまくゆかなくなる問題はいつ解決されるのかよくわかりませんが、ひとまずCLSの減点を減らすための方策を取ることにしました。といってもその場凌ぎの姑息的な方法で、<img>にloading="lazy" decoding="async"をつけるだけです。まあ、lazysizes.jsに伴うCLSと言いながらlazysizes.js自体を使うことをやめてしまっているので解決になっていませんが…

画像のdecoding-async:非同期処理による高速化について
HTMLのdecoding属性のasyncの使い方について取り上げた。画像のimg要素に付けると非同期処理が可能になるので、ブラウザ毎に差はあるにせよ、およそ初回画面に出る画像のもた付きを減らしてもっと滑らかに表示させられる。
https://www.nagahitoyuki.com/2021/03/about-speeding-up-by-decoding-async-of-images.html

Safariは仕方ない。。。

loading="lazy"はChrome、Edge、Firefoxなどのモダンブラウザでlazyloadにネイティブ対応したというタグで、画像の<img>にこの一言をつけるだけであっという間に遅延読み込みが完成します。現状ではSafariが未対応で、先日ようやく対応したwebpもそうですが、Safariは新しいWEB技術をなかなかとりこんでくれるのがなかなか遅いですねぇ。昔のIEのようになってきました。Safari以外は対応済みですし、そのSafariもいずれ対応することを明らかにしているようなので、それまではSafariはフル規格で対応できませんが仕方がありません。

一方でdecoding="async"の方はSafariも対応しています。もっとも、こちらは遅延読み込みではなく読み込みはページと同時に行い、画像表示のためのレンダリングを非同期に遅らせるだけです。またloading="lazy"とdecoding="async"の両方を同時につけておくとこれは両立はせず、loading="lazy"が優先されるようです。

decoding=
画像の読込の高速化でHTMLの標準仕様となったdecodingと、Googleがいち早くChromeに取り入れたloadingは、何が違うのでしょうか?その動作を検証しました。
https://spelldata.co.jp/blog/blog-2019-12-19.html

苦し紛れの解決策(その2)

pictureタグの中ではjpg/pngもwebpもどちらも遅延読み込みするのが理想ですが、実は<picture>タグの中でjpg/pngのみに対してlazysizes.jsで遅延読み込みを有効にしてwebpは遅延読み込みしないという割り切り方をする方法もあります(これも厳密には解決になってませんが)。どうやら現行のバージョンのLighthouseではwebpについては遅延読み込みをかけていなくてもCore Web Vitalのスコアに影響しないようです。

pukiwikiのrefプラグイン(ref.inc.php)はページに画像を貼り付ける時に重宝します。このプラグインに少し手を入れることでwebp wallbackを実現したりしていました。しかし、画像のサイズを取得する設定にしているとこのプラグインは若干重いので、ローカルサーバーの画像を表示するときは相対パスに変換することで若干速

そもそもpictureを使ってwebp fallbackをするとこのような問題が生じてしまうのでいっそのことwebpを使わないようにすればこの問題は解消されるのですが、そうなるとpagespeed insightに次世代画像フォーマットを使えと怒られますしね…