Chorome70でLazyloadがブラウザ実装されるようです

Blink lazyloadはhtml属性です

<img src="URL" lazyload="on">

こんな感じでできるらしいですね。一方第三サービスだと概ね以下のような内容です。

<img src="代替画像 or src属性なし" data-src="URL" class="lazyload">

Chromeの独自実装を利用すれば文字数をかなり減らせます。代替画像を入れる場合にはsrc属性に極小透明pngあるいはgifのアドレスかdataURIのアドレスを入れることになりますので、さらに文字数が増加します。ただしこの 独自実装 である点が重要なので後述します。

スクロールの位置ズレ問題の解消も考えられている

単純にlazyloadingを導入するとスムーススクロールなのによる頭出しの位置が大幅にずれてしまいますが、Blink lazyloadではその点も配慮されており、たぶんですがHTTP range requestsを利用して最小限の読み込みで画像のサイズだけを取得、そして プレースホルダー(領域を確保するためのもの) が自動生成されるもよう。これは素晴らしいですよね。JSによるlazyloadingを利用している場合にはCSSでの領域指定などで対処する必要がありますので冗長なhtmlを書く羽目に。

という感じでかなり利点の多い内容だとは思うのですが、しかしBUT

他ブラウザの足並み

Blink lazyloadは html属性 を追加することで機能します。そうなると無視できないのが W3C validation (W3C ばりでーしょん, htmlの正当性検査)です。htmlが「validではない」ことにどんな問題があるか、という点ですが、後世への記録だとかそういうのはここでは置いておき、本件だけに的を絞った場合の問題点。

Googleはwebの動向を牽引もしているので当然そこも押さえてくるだろうとは思いますが、現在htmlが5.2が正式勧告を済ませており、時期バージョン5.3ドラフト(草案)の中には今の所見当たりません。各ベンダーの独自実装に対して他ブラウザは追随する義務を持ちません。ところが仮にこれがhtmlのドラフトを通過し、htmlの新属性として正式に認められた場合には一転して各ブラウザに実装義務が生じます。つまり各ブラウザの足並みが揃うかどうかはこのあたりにかかっている のではないかと。

一歩間違えればIEと同じ道

何かと叩かれることの多い Internet Explorer ですが、実はもう既にこのlazyload属性を独自機能として持っています。そのIEが叩かれる原因の一つが 独自実装 ですよね。

ただし当時(ブラウザ戦争時代)のMicrosoftと違うのは、独自実装を「ウリ」として扱うわけではない点かもしれません。「IEを使うとこんなことができますよ、これができるのはIEだけですよ」というのではなく、Googleの場合は「俺についてこい」という意味ですよね。たぶん (´・ω・｀)
俺がスタンダードだし常に素晴らしい提案をしているんだからお前らが俺に合わせろよ、と。今回のlazyloadingについては確かに素晴らしい機能なので他ブラウザも是非追随して頂きたいところではありますが、Googleのこの傾向は危険信号な気もするなぁ (´・ｪ・｀)

他ブラウザが実装するにあたり例えば「属性名が違う」とかそういうことにはならないはずです。そんなことしたらまた歴史が繰り返されるわけで。愚者は経験に学び賢者は歴史に学ぶ、とかなんとかそういうの。

既にlazyloadingを導入している場合にどうするか

これまでのhtml内容(プラス JS内容)を維持するか、これを機に切り替えるかという選択についてです。ここは個人の判断なので指図できませんが、個人的には以下の条件が揃ったら切り替えても良いのかな、と思います。

• Quantum(Firefox)とWebkit(Safari)が実装したら
• html5でvalidと認められたら

最近のブラウザの多くは Chromium(くろみあむ) をベースにしているものが多いですよね。IronとかSleipnirとかVivaldiとかBraveとか。それらは全てBlinkエンジンなので当然実装してくるとして。根強いファンの多いMozilla社 Firefox のQuantum(くおんたむ)エンジン、そしてもう一人の王様 Apple社 Safari のWebkit(うぇぶきっと)ですよ。問題は。

iPhoneのブラウザは例え「Google Chrome」の冠を持っていてもレンダリングエンジンはWebkitです(Appleが他エンジンを許可しないから)
既にJSによるlazyloadingを利用している場合は全ブラウザで機能しているはずですから、わざわざChromeだけに絞る必要が無いですよね。iPhoneのSafariを無視できるというweb管理者もいるはずないでしょうし。

切り替え時期が遅くなればなっただけ 修正項目数が増える ことになりますが、それでも各ベンダーの状況を確認してから切り替えるが吉、かなぁ (´・ω・｀)
現在layloadingを使っていない、という方は積極的にlazyload属性を追加していくと良いかもしれませんね。
記事を書く際にちょこっと追加するだけですし。
もともとlazyでなかったものがChromeだけでもlazyになるなら歓迎できるのではないでしょうか。

というわけで、慌ててすぐ切り替えない方がいーよ！という個人的見解でございます。