kyzaUntil it waterfalls and the initial image data comes in it'll still be a 0x0 element. It won't jump less, just faster.
2022-11-02 01:02:53
2022-11-02 01:02:54
So fast, that the user is not likely to notice it.
Also, if you have a page filled with lazy-loaded images; Without the height & width set, it will cause the page height to increase as you scroll, causing the scroll bar to jump around. and pushing content below it down. But with the height/width (and proper css), the space will be filled with an empty box until the image loads, leaving the content where it should be.
https://www.smashingmagazine.com/2020/03/setting-height-width-images-important-again/
kyza
2022-11-02 01:08:30
I think I poorly worded a bit. I did mean without width and height properties set. Since those properties will likely load well before the CSS they are even more super important.
Jim
2022-11-02 01:10:23
Ah, I kinda thought so. Wasn't sure. Most CSS is blocking though, unless you use a fetch on it. So the CSS should be applying as it goes.
kyza
2022-11-02 01:15:18
I know that the DOM is rendered incrementally as the data streams. If the stylesheet is linked it would need to waterfall just like an image. If it's inlined but in the head there (probably?) won't be jumping, but the tradeoff would be blocking the rest of the DOM content from streaming.
I don't know the exact loading behavior of the stylesheets themselves though. Like if browsers also support streaming CSS or not. I'll have to give that a search and see.
Jim
2022-11-02 01:20:47
If you embed stylesheets the way they were meant to be added, yes, it will block rendering the DOM until they are downloaded & parsed. If you use the JS print hack, it will load asynchronously, but you risk having a flash of unstyled content - depending on how fast the css downloads & parses. It's up to the developer how they want to handle it.