Browsers decode the image separately, yes, but they don't load the images separately. While images are being downloaded they're blocking the UI thread and preventing anything else from being rendered until the image is done downloading. The upside of this approach is that if you have some massive 10k image to load, the rest of your UI can be rendered while the web worker handles the heavy lift of downloading the image.
It's the same reason that you move <script> tags to the bottom of the <body> or mark as async. The download of those scripts will block your UI rendering, so you want to delay them as long as possible, or mark them for async download.
Well, this is essentially lazy loading. The difference between this and traditional lazy loading techniques is that it takes work off of the UI thread and loads the images in parallel, whereas traditionally you would wait until the UI has loaded, then set the src attribute on the img tags so they use the typical browser loading methods. It's the difference between loading your UI and images at the same time, versus loading your UI first, then your images after.
Your claims are false.
They demonstrate two things: a) you haven't looked at the source code; b) you haven't actually tested your claims.
Image loading does not block rendering. It's as simple as that. If they do block anything, they block other images from loading.
In short: when the browser has to load more resources than its current limit of concurrent requests (which is 4-6 for most of the common browsers), it does its best at prioritizing based on resource type and its position in page (it will always try to render the elements currently on screen first (and it's not always the "above the fold": if you're scrolled down and refresh, it will actually prioritize the elements visible at exactly your current scroll). The main point is that images are almost in all cases the last in the list of priorities. So, if image loading does block something, it blocks other images from loading).
But they don't block rendering or JavaScript execution. Ever.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
What's the point of this? Doesn't the browsers already decode the images in a separate thread?
Browsers decode the image separately, yes, but they don't load the images separately. While images are being downloaded they're blocking the UI thread and preventing anything else from being rendered until the image is done downloading. The upside of this approach is that if you have some massive 10k image to load, the rest of your UI can be rendered while the web worker handles the heavy lift of downloading the image.
It's the same reason that you move
<script>tags to the bottom of the<body>or mark asasync. The download of those scripts will block your UI rendering, so you want to delay them as long as possible, or mark them for async download.So why not just use some lazy loading technique?
Well, this is essentially lazy loading. The difference between this and traditional lazy loading techniques is that it takes work off of the UI thread and loads the images in parallel, whereas traditionally you would wait until the UI has loaded, then set the
srcattribute on theimgtags so they use the typical browser loading methods. It's the difference between loading your UI and images at the same time, versus loading your UI first, then your images after.Your claims are false.
They demonstrate two things: a) you haven't looked at the source code; b) you haven't actually tested your claims.
Image loading does not block rendering. It's as simple as that. If they do block anything, they block other images from loading.
In short: when the browser has to load more resources than its current limit of concurrent requests (which is 4-6 for most of the common browsers), it does its best at prioritizing based on resource type and its position in page (it will always try to render the elements currently on screen first (and it's not always the "above the fold": if you're scrolled down and refresh, it will actually prioritize the elements visible at exactly your current scroll). The main point is that images are almost in all cases the last in the list of priorities. So, if image loading does block something, it blocks other images from loading).
But they don't block rendering or JavaScript execution. Ever.