Image Sizing using CSS


#1

Hello,

I have a question regarding image sizing using CSS commands to shrink and enlarge images on the page. I'm curious about what is good practice in terms of efficiency.

Say you have a large image and the file size is 10mb (a little exaggerated), and you want to use it a couple times on your page, but you desire to have it in different sizes. I'm pretty sure that the page is going to attempt to load two 10MB images, but also work more at rendering them in their adjusted sizes. Would this be the case? I'm looking for confirmation on this, so that I'm understanding my assumption.

I understand that we want to make sure our images are optimized to be as small in file size as possible with the best quality we can get. I came up with this question thinking about how I could optimize my workflow between images I'm using on my page to save time from making different sizes for all my images. If I could just work with one large version of the image and shrink it down as I need it, I feel it would help with flow, but that would possibly make for a very sluggish site.

Appreciate any feedback regarding this.

Cheerio!


#2

a simply google search yielded great result:

I would say at least compress the image, but after reading this article quickly, there is a lot more to it.

using an image multiply times is actually not bad, let me explain why:

when you visit a website, a request to a server is made, and all the required files are send back, if the same image is used multiply times, the image is only send once (html can re-use the image)

the bottleneck is in the request and response from the server. given this goes over the network (wifi, 3g, 4g), in particular with 3g and 4g, you don't want that the website uses to much data


#3

Nice, thanks for the article link. I'll see about digging up some more like articles.

You make a good point about the html file and the request between client and server. Depending on how you optimize, I can see it working out pretty well depending on a lot of variables. The conclusion to the article was humbling in that this is a tricky area to navigate given the web is no longer strictly a home and office experience.

I started to notice this shift in the web in utilizing a more minimalist approach to cater to the growing force of mobile browsing.

This also amuses me a little bit as it makes me wonder if this shift to simplify graphics on the web spawned more pixel artists.

Thanks again ^_^.

Cheerio!


#4

When considering both data size and image dimensions, the optimal approach is to have images of the exact dimensions specified in the page or CSS. This might mean having several sizes of the same image on your server, but apart from the extra work of creating them, there is no downside.

Consider a responsive design. Rather than resize a large image for a smaller display, have your media query scope out the display size and select the correct size of image to send down. Ultimately your site will use very little data on mobile displays because it is only sending a small image to those devices.

You can also set image quality higher for smaller images, rather than using only one quality for all sizes. Larger images might be in the range of 70 to 80% while smaller sizes could be 90 to 100%. Load time and bandwidth are generally related but bandwidth is a kicker with mobile plans as the very good article on compression posted by @stetim94 discusses.

Another concern is the number of files going down to the client. A repeat visitor who retains their browser cache will likely only need a few files, those that have changed since their last visit. A new visitor will need the lot. If there are a lot of images, their first experience might not be what one would expect.

Browsers usually have a limit on how many connections they can have on a single domain, usually two. That means only two files can be downloaded at any one time. By using a CDN to host libraries, and an image host for images (that are public) or a subdomain for your proprietary images, you can establish several connections at once. The HTML and CSS can come down together, essentially, and the JS can be last in the load sequence. Loading will be lightning fast with all these asynchronous connections.

The number of requests sent to the server is also a factor as each request will have latency which adds to the time. Skin images and small graphics can all be saved to a single Sprite. This would be one file, one request. Your CSS would help to target each graphic as the page is being rendered. They would not need img tags, only containers with CSS backgrounds. Say for instance you have a few dozen thumbnails. They could all be saved to a single file much like a photographers contact sheet.


#5

HTML5.1 is the new Standard. It includes,

The picture and srcset attributes allow responsive image selection. That means the user agent may select images between different resolutions.


#6

I'm still learning how things talk to each other. So what I'm gathering from you post mtf is that when optimizing for mobile, we have the ability to coordinate our site to send a specific image to that client. I'm not to familiar with how a responsive website behaves in relation to desktop counter part.

As I'm understanding you have one main site that has been set-up to recognize where its being accessed and basically uses the coding that transforms the site to be more viewer friendly on whatever device its being viewed upon. Is my train of thought going in the right direction?

That's exciting to see that a standard has been implemented for what seems exactly what I'm talking about and this only just happened a couple weeks ago lol.

I agree that regular's will definitely be a consideration as they will have some of the files temporarily stored in their memory, but my thinking is to always aim for the first time user and aiming to make the first visit as fast as possible. While I do think its sad that our attention spans seem to have shrunk, there is simply no excuse for a site that loads poorly. By poorly I mean getting absolutely bogged down with ads, commercials and alerts. Some sites I come across that just suddenly bombard me like a hoard of street urchins begging for coin, I find myself running in the opposite direction, never to return. But that's going in a bit of a different direction. Apologies, got lost in thought >X3.

Thanks again mtf for your input ^_^. Really appreciate it.

Cheerio


#7

Yes. That is what responsive design is all about. Device friendliness. Twitter Bootstrap is a perfect example of CSS and JavaScript libraries whose purpose is to pave the way to responsive web pages and apps. But we can do it from scratch with media queries of our own, though it is a tonne more work until we succeed at a decent model.

... but took two years to reach. HTML is at its core, one standard. It is progressing up the ladder with technology advances by adding newer recommendations, this release being the latest. One cannot stress enough the importance of treating HTML as a whole, not an iteration. The new does not replace the old, only add to it.

It will take a year or more to read the whole W3C site, but if you glom on to the main parts, HTML in general and work up through HTML 4 and beyond you will get the full picture, especially the why's and what-for's. Same with CSS. Equality important read, and W3C.org is where to start.

Definitely the first concern of every web publisher. I tell people to stay away from JavaScript until they have a fully functioning web page (site) using only HTML and CSS. With CSS3 and beyond the sky is the limit for many typical interaction concerns. Script is hardly needed in any well formed interface. What it adds to the behavior or experience should do just that, add to it. An unscripted site should still be a likeable experience for the user, and the site should be fully functionsl with no content hidden. Namely, it must present the same way, for the most part.

Ads and plugins are another thing altogether, since they are largely out of our control. For a new site I would stay away from both for the first year and focus on content creation. The site will do fine if kept up, and the numbers will be there when it comes to selling advertising. The more links that point to a site before it has advertising the better.

Back to quick load times. How do we do it? Well, we discussed media queries. That's a shoe-in, for sure. With them we can not only select the correct resolution of images to send down, but also the number. The technology is there to only send down what reaches or is just below the fold. You'll see lots of sites doing this now. Content only comes down if the user has scrolled to that point in the page. This means longer pages are no longer an issue. However, in absence of that support on your site, it means using smaller pages to start the initial download of the site. A short and simple index page with all the navigation and applicable hot spots and textual content is the optimum way to start the ball rolling.

No more than 600 words, a limited number of images apart from skins and fully crawlable navigation to every other landing page on the site that may apply. These pages will lead to the deeper, richer content if the user sniffs them out. Then the speed and size rules change, a little. Someone who is engaged will wait. They landed and engaged, so they are marginally committed at that point. I think you get what I mean.

There are practical approaches right from the get go, without bringing on a whole plethora of other supports. HTML and CSS by themselves are a dynamic duo. Don't spare them any expense in your learning path and as you progress to other areas of the stack, keep them front and center, always. You'll thank yourself three years from now.

You're welcome. Happy coding!


#8

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.