Webフロントエンド ハイパフォーマンス チューニング

2017年9月11日 著

ちょこちょこ読み進めていた『Webフロントエンド ハイパフォーマンス チューニング』、少し前にようやくという感じで読了。結構な情報量だし、JavaScript周りは圧倒的に理解が足らないので、おそらく読み直しが必要。しばらくは会社で手元に置いておこうと思いますが、本書で一番気になったのは、p.247にあるimg要素のサイズを固定するというお話。曰く、

画像を表示するimg要素には、height属性やwidth属性で大きさを設定することができます。無駄なLayoutを減らすには、このimg要素に対してheight属性とwidth属性を設定してください。

画像が読み込まれていない段階では画像の大きさがわからないため仮の大きさで一度Layoutが行われます。画像が読み込まれ次第画像の大きさが変わることになるのでLayoutやそれに続くレンダリング処理が再度行われます。

とあって、なんとなくwidth/height属性は指定した方が良さそう、って気にならなくもない。けれど、レスポンシブWebデザインを採用する（ img{max-width:100%;} な感じで、画像の大きさは可変を前提とする）ことの多い昨今、あらかじめ素の幅と高さをマークアップで指定しておいたところで、その値通りに収まるケースは相対的に減っている訳で、あまり意味がない気もする（むしろ書かない方が若干だけどHTMLファイルの軽量化になるし、滅多にないけど大きさの異なる同じファイル名の画像に差し替える時にラク）。で、以前Twitterにそのあたりのモヤモヤを軽く吐き出したところ識者の方から

超短時間内もしくはOSの次のイベントループに入る前に発生した複数回の変更は一度にまとめられるので安全です。例えばJSで同期的に複数のレイアウト変更させてあっても一回と計算できます。

とか

付けない場合は、reflow一回は余分に発生するけど(imageのヘッダを読み込んだ後)、タイミング次第でそのreflow (reframe) は別に発生することはないから、労力ほど変わりはしない気がする

といったコメントをいただき、書籍に書かれてあるほど単純なお話ではなさそう、ということまでは理解したものの、それ以上の深追い（何）はしていません。本件に関しては、さすがに古すぎて現在は参考にし難いけども、かつて神崎先生が強調,引用,グループ化,画像などの要素 -- ごく簡単なHTMLの説明で

Web Designing誌2004年8月号の特集記事「なぜ表示は遅くなるのか」で、100枚の異なる画像を表示させる際に、widht/height属性を与えた場合と与えなかった場合でページの表示速度がどう違うかの検証が紹介されています。それによると、ほとんどのブラウザで属性を"指定しない"方が1〜2割速いという結果になっていました。まぁ、1秒未満の差であり、計測の誤差も考慮する必要はあるものの、「widht/height属性を指定する方が表示が速くなる」は、すでに神話と言っていいかも知れません。

と記していたのが思い出されます。2004年当時からすれば、表示パフォーマンスの計測は比較的容易になりましたし、それゆえ1秒未満の時間であってもそれを安易に誤差と片付けずストイックに改善することが求められる風潮を微妙に感じなくもない現代において、width/height属性の指定が表示パフォーマンス上、果たして本当に有効なのかどうか......ブラウザーに依らず一義的な正解を出すことがそもそも可能かを含め、ファイナルアンサーが待たれます（他力本願）。なんか全然、書籍の感想になってないけど気にしない。