Is it okay to set the width and height of the img tag performance wise knowing that the original image is much smaller?
The articles I've read usually say that setting width and height solves the performance issues, but its not clear, if I set the width and height and they are different from the native image size, is it "ok"?
Or Do I have to always set the same width and height as the image itself?
Unless you're anticipating your site used on slow/limited devices like smartphones you shouldn't bother about performance in this specific case.
However, if you specify size that is larger than the actual image size then the image will look bad.
From my experience specifying an image size is useful to avoid page layout change when an image is not loaded immediately; in this case the browser initially doesn't know what the size will be and won't reserve the needed space for it. Later when the image is loaded the page contents may "jump" because the size of the image will change for the browser.
I don't have benchmarks at hand, but I think it won't be a problem at all if you set a width/height different than the original one. The browser renders the image, and that's it. The rendering action is usually not expensive in terms of performance AFAIK. By the way you are not supposed to be afraid of things like this, unless you are doing something very fancy (i.e. an image 99999x99999 or rendering 2,000 images in a single page).
Anyway, if you can avoid that, it's probably better.
Related
According to
http://www.w3schools.com/html/html_images.asp
Always specify the width and height of an image. If width and height are not specified, the page will flicker while the image loads.
Personally I have tried testing it and never noticed it happening. Anyone seen it before and know why it happens?
w3schools is not known for their accurate information, and historically was so bad that http://w3fools.com was created to explain just how bad the information was.
The "flicker" that w3schools is referring to is probably the content shifting that happens when an image changes sizes after it loads. Browsers have generally optimized this shifting to mostly go away, but it can still occur depending on how images are loaded and styles are handled.
The main point being to use [width] and [height] attributes to inform the browser of what size the content is expected to be to make correct rendering as fast as possible.
I was told that specifying inline width and height for all images will be good for SEO and also helps the site loads faster, like so:
<img src="http://www.example.com/images/free-size.jpg" width="200" height="400" alt="random image" />
Although I can still overwrite the inline setting using height:auto;.
So that images re-size properly when in different display platforms.
But just before I go ahead and doing this just want to reassure if these statements are true. Personally I feel dubious about fixing the inline dimension and overwriting using external CSS, just sound a bit hacky to me.....
I was told that specifying inline width and height for all images will
be good for SEO and also helps the site load faster.
Yes. This has traditionally been true (at least the "site loads faster" part).
By specifying the height and width attributes of an <img> the browser reserves a space matching those dimensions for the image while it continues parsing the rest of the HTML document. Then when the browser loads the image, the reserved space is waiting and there is no need to reflow the document.
Providing this sizing data results in a faster rendering process.
In contrast, if the width and height attributes are omitted, the browser will not know the size of the image until the download is complete, which forces the browser to reflow the document, slowing down the rendering process.
Now imagine a page with 50 images with no defined width and height attributes. The performance hit could be very noticeable.
The practice above represents the traditional view of image loading.
In contrast, some people are now saying that for responsive design the width and height attributes should be avoided.
Responsive Design does not normally use any width or height attributes
The majority of responsive websites do not use width or
height because they want the images to adapt to the screen size and by
using fixed width and height using <img> which would dampen user
experience and Google has declared this one of the most important
factors.
source: https://webmasters.stackexchange.com/a/68494
So there are arguments on both sides and the decision most likely depends on your individual case. As you make your decision here are some more details:
Specifying image dimensions to improve browser performance
Image width/height as an attribute or in CSS?
I was told that specifying inline width and height for all images will
be good for SEO and also helps the site loads faster.
No, it does help loading the site faster. It helps avoid flickering when rendering the page. If you want to load your images faster, make sure they have the same size as specified in the page and use a service like kraken.io to reduce the corresponding file size.
About SEO, it's improper image size and width for the screen size that can hurt your SEO. Google may consider you site as not user-friendly and/or not smartphone friendly.
If you do not tell the browser the size of your images then it must "build" the page not once, but twice (or more times depending on how many images you have on the page). It will build it once to display all the text, and then it will wait until an image is downloaded. When one image is downloaded the browser can now determine the size of the image and will rebuild the page to wrap the text around that image. This process will happen for every image on your page.
If you just specify the image dimensions, it will already know the size of the images and can use that information to shape the page. It won't have to rebuild the page a million times.
The best approach I think is to use the aspect ratio in css.
.img-container {
max-width: 500px;
aspect ratio: 2/1;
overflow:hidden;
}
The above css will reserve a container space for the image to load and prevent reflow.
See this:
http://real-sense.com/index.php?option=com_content&view=article&id=106
The set of vertical images on the right are being resized using CSS
.thumbnail-product-resize
{
width:144px;
height : auto;
}
Does anyone know how to do this in a cleaner way so I don't lose quality on the image?
I mean that if I had resized the image using photoshop, the text won't appear as blurry as it does here.
Tested in FF
Thanks
The quality of your images will depend on the original size of the image you use. If have a large image with good quality, say of size 400x500, and it is then resized in the HTML to 80x100, it will still be a 400x500 image. However you can only fit a certain number of pixels on a smaller image of 80x100, so this bigger image has to be sampled. This means that an average is taken of pixels and then made to represent a 80x100 size image.
If you want a more definite result you can change to original size of the image to 80x100. This will probably give you better results.
Once upon a time browser image resizing gave truly heinous results due to the unsophisticated nearest neighbor technique they used to scale images. Now they usually perform filtering when scaling and there isn't that much difference between in-browser resizing and resizing in Photoshop.
The real advantage to scaling an image before serving it to the client is that you aren't forcing the download of large images when they aren't necessary. Depending on the size of your images, this can significantly reduce your page load times.
One final thing to consider is that more and more people have devices with "retina" displays. For those users scaling the image before serving it will result in much less crisp images.
Here's an in-depth comparison of the image scaling methods used by various browsers: http://entropymine.com/resamplescope/notes/browsers/
Even if you had done this in photoshop those images you have would still appear pretty much the way do just now.
FYI you don't need to include height:auto in your CSS above.
Best bet would be to create a seperate set of thumbnails (using photoshop) which maybe just show a portion of the image.
Loading the thumbnails and resizing them with css the way you are doing is bad practice as you are still having the user download the large images first.
It is impossible to shrink an image without loosing quality unless it is an vector-image. That would mean that you'd have to use SVG. And considering the images displayed I don't think you wan't to do that.
Also you mentioned the cleaner way to do it, use photoshop or something similar.
I came to know that, if we dont give width and height attr. in image tag there will be a performance isssue.
I have a div element for which i'm setting width and height in percentages. Also the same div is having a background image of fixed size say 140px * 140px.
Here, will there be a perfromance issuse?.
markup example:
<div style="width:50%;background:url('imgofsize140*140') no-repeat"> </div>
Thanks
This isn't a one-size-fit-all case - Therefore we have to look at it case by case.
There are a lot of variables that we must keep in mind - User's internet connection speed, image size, computer capabilities, etc.
I found a few questions on SO that are somewhat relevant to this question. I will include them as I see it beneficial. I am NOT claiming to be absolutely correct.
BGIMG vs IMG
Performance Argument
AFAIK, browsers cache images the same whether they're in a DIV or an
IMG. In any case, I think this one of those cases where specific
performance is defined as an implementation detail internal to each
rendering engine (and possibly the browsers built around them). As
such, it's both out of our control as designers/developers and subject
to change from browser to browser and version to version. In other
words, I wouldn't spend too much time worrying about it.
Context
Technical differences yes, most notably you can set the width/height
of an IMG tag and it will stretch the image, which can be useful in
some situations.
The main thing you've got to keep in mind though is the context of the
image within the HTML document. If the image is content, say an image
in a gallery, I'd use a IMG tag. If it is just part of the interface I
might use a div instead.
- By Paul
And the response to that is just as important.
That said, you bring up an excellent point about the semantic
difference: an IMG is usually the better choice when the image is a
material part of the page's content, while a CSS technique is usually
preferred when the image is just decorative or for formatting.
This is not performance related directly - More about semantics and accessibility. By - Mr. W.
Then one more for Performance OFF of SO which I feel is directly related to your question.
Page Load Test
The version with background images actually gave me a “Document
Complete” after .0225 seconds – while the fully loaded page load time
was roughly the same as the inline image version. Could using all
background images speed up firing of $.document(ready)? It turns out
background-images are only downloaded after the element (containing
div, span etc) is available. This prevents blocking from all the round
trips required to get images.
results: inline image test page
results: background image test page
I wouldn't think there would be a performance issue in the same way as not specifying height and width on a img tag, since that forces the browser to repaint the whole page and that's where the performance issue is.
http://code.google.com/speed/page-speed/docs/rendering.html#SpecifyImageDimensions
tl;dr
You will not get a performance penalty (which is really small in the other case as well).
Some more details:
You shouldn't care (unless you work for Google) about the performance "penalty" you'd get from not specifing a width & height, but more about the layout flickering you might get.
Not specifing a width and height will make the browser display an initial box, as it doesn't know beforehand how much space the image will take, and after the image is loaded it will do a reflow - which means it will have to recalculate the layout of some elements which will be affected by the size change. But, this is actually going to happen very fast (and you're probably triggering reflows in lots of other places).
There is no reflow necessary for the background image.
I don't think this will effect perfomance.
If you combine your background images into one image and position it as and when you need to that will help speed up performance as you're only loading the one image rather than multiple images.
The background image will be displayed as 140x140 unless the div width has smaller size than 140px.
You might also want to check the result in older browsers such as InternetExplorer 6-7-8 just to ensure if there is any other performance issue.
Depends on the browser. I learned today that Chrome currently redraws the canvas as you scroll with an absolute position bg image. Firefox handles it just fine. This should be fixed in a future Chrome release.
On the contrary, specifying the img height and will cause the performance issue.
Because by specifying them, you tell the browser to resize the img first, then render the image. For example, storing thumbnail image is much better than resize the image on the fly.
If your image is already the specified size you want their is no need to specify the Height and Width in the attributes. Also, there will be no performance issue in using the background image.
If I have a logo image, and I want to use it on another page where I require it to be a smaller size, it is my instinct to create a new image, resized with a graphics editor. However, I am hearing that it is better for the user if I instead refer to the original image and resize it with the browser by changing the height and width in the image tag.
So I ask the crowd, what is the best practice here?
Thank you for your time,
-- Henry
My default response would be "Resize it in a graphics application", but it depends on how you're using it.
When you leave image resizing to the browser, the original (full-size) image has to be downloaded before the browser can display it at a smaller scale. This means that you use more bandwidth and your webpage takes longer to load. However, if you mainly use the larger image throughout your site, then it will be faster to always use this image, since the browser can cache it.
If you're concerned about image quality, you would get better results and would have more control over the downsampling process using a dedicated graphics application to resize the image.
It's fine to resize images with CSS or the height and width tags. The only thing you want to be careful of is making really large images small because it obviously doesn't decrease the download size.
Doing this would work best when you're effectively caching your images so it doesn't get downloaded a second time. Then you will be getting a tangible benefit from doing so. I usually just append the last modified time of the image to the URL, eg:
<img src="/images/log.png?1233454568">
and then set the Expires header to a year from now. If the image changes, the mtime changes and it will force the browser to reload it.
That's suggested for images, Javascript and CSS files.
If the browser resizes the image for you by using height/width tag, you might end with a lesser quality image, really depends on the image type (like photo vs. simple graphics), so try it out in some common browsers. But resizing the image in a graphics editor is the only way to ensure a high-quality resize operation.
Create the smaller image in a graphics editor, for several reasons:
If users have not already cached the larger image, they will be downloading the larger file unnecessarily.
Resizing the image client-side results in some unpredictable scaling quality.
Doing it in HTML is ill-advised anyway, for presentational issues (such as element sizes) you should do it via CSS.