Do you actually have to provide the image? Couldn’t you provide a pointer to the image? Like those thumbnails that are just links on the backends but appear as images when loaded
If you’re going to display pixels on the user’s screen, you have to send those pixels to the user. Magic still doesn’t exist. HTML img tags are indeed a “pointer,” but once the user’s browser has the path to that image file it will download the entire thing.
That said, there’s no reason to send an image that’s any bigger than it needs to be. Sending a scaled down thumbnail if you know it will be displayed small is sensible. Sending the entire 1200px wide or whatever image it is and just squashing it into a 100px wide box in the user’s browser is not.
You may be thinking of “lazy loading,” where some scriptwork is used to delay downloading images until some time after the initial page load completes. This still requires all the data to be sent to the user — all of the data always has to be sent to the user eventually — but just not right away. This can have perceptible load time benefits, especially if whatever content you’re loading won’t be visible in the viewport initially anyway.
Tbh I’m just new to the computer science scene - I’ve taken one class so far on the fundamentals of programming and have only seen a real language in my free time as of yet.
It didn’t occur to me that the webpage which references another for an image would still be culpable for the space taken up by the image, because with on-disk memory management you can do tricks to reduce sizes with pointers and I just thought it would be analogous. It feels painfully obvious to me why that’s stupid now lol
It’s the same line of logic as when you see people post on a forum something like [img]c:\Users\Bob\Documents\My_Image.bmp[/img] and then wonder why it doesn’t work.
“But I can see it on my computer!”
Over the internet, the origin of all data is on someone else’s computer. All means all. And all of it needs to come down the wire to you at some point.
You’re on the right track in one regard, though, in a roundabout way with caching: Browsers will keep local copies of media or even the entire content of webpages on disk for some period of time, and refer to those files when the page is visited again without redownloading the data. This is especially useful for images that appear in multiple places on a website, like header and logo graphics, etc.
This can actually become a problem if an image is updated on the server’s side, but your browser is not smart enough to figure this out. It will blithely show the old image it has in its cache, which is now outdated. (If you force refresh a webpage by holding shift when you refresh or press F5 in all of the current modern browsers, you’ll get a reload while explicitly ignoring any files already in the cache and all the images and content will be fully redownloaded, and that’s how you get around this if it happens to you.)
Do you actually have to provide the image? Couldn’t you provide a pointer to the image? Like those thumbnails that are just links on the backends but appear as images when loaded
If you’re going to display pixels on the user’s screen, you have to send those pixels to the user. Magic still doesn’t exist. HTML img tags are indeed a “pointer,” but once the user’s browser has the path to that image file it will download the entire thing.
That said, there’s no reason to send an image that’s any bigger than it needs to be. Sending a scaled down thumbnail if you know it will be displayed small is sensible. Sending the entire 1200px wide or whatever image it is and just squashing it into a 100px wide box in the user’s browser is not.
And use SVG when you can; bitmaps which should be vectors are frequently big and ugly.
I dunno why that didn’t occur to me, that makes sense
That’s how it works.
You may be thinking of “lazy loading,” where some scriptwork is used to delay downloading images until some time after the initial page load completes. This still requires all the data to be sent to the user — all of the data always has to be sent to the user eventually — but just not right away. This can have perceptible load time benefits, especially if whatever content you’re loading won’t be visible in the viewport initially anyway.
Tbh I’m just new to the computer science scene - I’ve taken one class so far on the fundamentals of programming and have only seen a real language in my free time as of yet.
It didn’t occur to me that the webpage which references another for an image would still be culpable for the space taken up by the image, because with on-disk memory management you can do tricks to reduce sizes with pointers and I just thought it would be analogous. It feels painfully obvious to me why that’s stupid now lol
It’s the same line of logic as when you see people post on a forum something like [img]c:\Users\Bob\Documents\My_Image.bmp[/img] and then wonder why it doesn’t work.
“But I can see it on my computer!”
Over the internet, the origin of all data is on someone else’s computer. All means all. And all of it needs to come down the wire to you at some point.
You’re on the right track in one regard, though, in a roundabout way with caching: Browsers will keep local copies of media or even the entire content of webpages on disk for some period of time, and refer to those files when the page is visited again without redownloading the data. This is especially useful for images that appear in multiple places on a website, like header and logo graphics, etc.
This can actually become a problem if an image is updated on the server’s side, but your browser is not smart enough to figure this out. It will blithely show the old image it has in its cache, which is now outdated. (If you force refresh a webpage by holding shift when you refresh or press F5 in all of the current modern browsers, you’ll get a reload while explicitly ignoring any files already in the cache and all the images and content will be fully redownloaded, and that’s how you get around this if it happens to you.)