The type of image should influence your choice of file format. If its a photo or similar type of image, you are maybe better sticking with jpg (if you don’t need alpha). PNG is very efficient (and loss-less ) for images with lots of flat colour, like icons logos and graphics. They are not so efficient with photo-like images, with lots of detail or where neighbouring pixels rarely match. SVG’s are another alternative to png.
The point Paul was making was that if you change your browser window size, you end up loading multiple versions of an image, which is inefficient. I imagine the same would happen if you used media queries to dish out different images. Perhaps if you used device-width in the query (which @RyanReese always advises against) it may only load one image per device, but not using device-width for general queries for the reasons Ryan gives, but just ones for images. I have not tried this, just an idea. What do others think?
Above is a a very old article well worth reading, although it is not specifically about image optimization it does stress about measuring to highlight performance bottlenecks.
Once the web-page is available there are numerous free tools available with detailed explanations on how to increase performance.
Yes, I know yo don’t like it (read your article), I was just throwing up an idea and wondered if it would work. To use device width only for selecting an image size to send the user.
So you have a big monitor, you get a big image, you mess with the browser width and the same big image stays, no more smaller ones get downloaded.
Or you have a small mobile, you get small images and no big ones.
You should just be able to swap out background images via media queries regularly and browsers should only download the one that will actually be served up to the user.
It was in response to Pauls comments about the picture element:
I assumed that media queries would have the same effect, loading 3 different versions of an image if you change the browser size. Maybe its not even a problem, but it got me thinking.
Ah. Yeah device-width might have a use there, but we have to consider the fact that 99% of users probably won’t resize their browser. If they do, they are probably split screening it or something, and in which case, they are probably on a desktop where bandwidth isn’t an issue (and if they do resize it like split screening, they probably don’t want the page to break by not serving up a different image because you did device width).
All in all, seems like something I’d avoid. I’d disagree with Paul here and say they aren’t adding to the problem.The loading problem Paul mentioned probably won’t have any effect on the average user.
Yes if you swap the background images you will get the browser loading three images if the user resizes their browser.
This is where I have issues with all these picturefill and image swapping techniques as it assumes the device will open at one size. Although, as I mentioned before this is OK for mobile because they can’t resize (unless landscape triggers another image of course) but desktops will now have 3 times the weight as I believe that very few people do not adjust their browser during a session (although I have no concrete info to back this up).
I have done background images like that. But one thing I was not sure about was if mobiles would load the big image too. The css being desktop first, I apply the big background to the default css, not conditioned by any query. Then the small image in the max-width query.
body {background-image: url(../images/bigpic.jpg);}
@media screen and (max-width: 600px) {
body {background-image: url(../images/smallpic.jpg);}
}
But I suppose the browser reads the whole css file before loading only what it needs to, is that right?
) for images with lots of flat colour, like icons logos and graphics. They are not so efficient with photo-like images, with lots of detail or where neighbouring pixels rarely match. SVG’s are another alternative to png.
.
.