I'm really confused with this one as it seems impossible to do.
When running my site through GTMetrix I pass great but with Google page speed insights it's insisting my images can be optimized more for instance:
Compressing and resizing mysite.com/…ets/img/homepage/my_image.jpg could save 78.5KiB (94% reduction).
The image in question is 65KiB so how Google thinks I can shave another 78.5 off it I don't know.
I'm using jquery unveil and using the retina function on it too could that be the problem?
Also I've tried downloading the images Google provides as their compressed version but these images have had their dimensions changed so would look terrible if I put them at their intended size.
Really confused, any help would be appreciated.
Thanks
There are few things you need to distinguish before proceeding with optimizing images for Google Page Speed.
Images are optimized for different platforms (Desktop and Mobile)
Images are optimized for physical size.
Reports for images can be "Compressing and resizing" and "Compressing" only. Compressing means u need to do a compression part, on other hand compressing and resizing means you need to use appropriately sized image for appropriate platform.
Depending on the report you are looking at (desktop or mobile), your item "Compressing and resizing mysite.com/…ets/img/homepage/my_image.jpg could save 78.5KiB (94% reduction)." needs to be less in dimensions and compressed or just less in dimensions. Margin for resizing an image with CSS is around 20% so if you got 100x100px image you can resize it to around 120x120px with CSS without getting report on that item (that is if you also optimized it physically also). To check this in Chrome, inspect image and check "Natural" size in element selector.
You can deal with this on few ways:
Media Query (note that you have to use background image in this case)
Srssets
JS
Depending on the image compression package that you use, you might get different compression results. I've noticed that sometimes Google's Page Speed is able to optimise an image further than I have been able to (and other times not!)
Do you have a live URL for your web page? Or even the image? It helps to be able to see it live and compare!
Related
Although it sounds a simple question I have been thinking about this.
How exactly do browsers render images? For an example of what I mean, lets say I have a 1MB image that is 3000px x 1500px. I then decide to put this image into a container that is the set to width:100%; meaning that it will scale down reponsively. Will the browser load the entire 1MB and then proceed to scale the image down to fit the container or will it scale it down and then proceed to load it?
I'm asking because this is pretty much my situation and if it does the former (load the 1mb first) then I guess I would have to serve a seperate image on mobile devices?
Thanks
Edit: Since people are saying that it'll load the 1mb image first, how would you suggest I serve a large image to the user? Scale it down for mobile and have a mobile/desktop version?
The CSS is applied after the image is fully loaded. So in short it would to load the 1MB image first and then apply the dimensions. Also images are stored at Server side. I found a very useful image which describes this:-
On a side note:
Browsers often render the same page multiple times in a very short period of time, specially after reading image metadata.
The browser (obviously) cannot scale (or do anything) with an image before loading it.
The image is retrieved first via a HTTP request e.g.
GET /images/myimage.png
and then scalings/transformations are applied. So if you want different images for different platforms then you should request as such.
Let me start off by stating that I realize the arguments against doing CSS Sprites for large images. I even asked a question about why that could be considered a bad idea (and added an answer of my own). Now that we've had that talk...
I'm going to be making a large CSS Sprite-map. For the process of making this sprite-map, it behooves me to know what (if any) limit exists for the height and/or width of a sprite image in order for browsers to properly process it.
The ultimate reason behind this question is a debate over whether to lay out the sprite images in a grid or in a single row/column. For example: is it necessary or beneficial to do 4000 x 3000 instead of 400 x 30000?
Edit: The sticking point here isn't about what size images can be, but rather what size browsers can process for sprites. Given the lack of detail thus far, I'm moving forward with generating the single-large-column sprite. I'll post details of my experiences as an answer once that is complete.
Sometimes it's more of a matter of download time. Since browsers can use multiple connections to download files, a huge image can take longer to download than a few smaller ones.
If your image is so big that it's slowing down page load maybe it's time to consider several smaller sprite images.
Direct-X 9 has a size limit if 4096 pixels, so any Internet Explorer filters applied to these elements will crop them at 4096 pixels.
See: IE display transparency bug on height > 4096px?
In practice, this seems to work with no problems in Firefox 5+, Chrome, and IE7+ for a sprite image of 400x16560.
The potential issues of IE's directx rendering engine failing on images over 4096px do not create problems in IE7 or beyond; we have no method or need to test IE6 for our current project.
The one place that we experienced problems with really large spritemaps is on mobile platforms. Android devices handle them reasonably well, but iOS devices break down pretty badly, and in a strange way: They shrink the image down to fit within the dimensions they accept. So our CSS works perfectly for a small spritemap, but with no changes except increasing the physical dimensions of the spritemap image, the sprited images begin to show four times as much of the spritemap in the same html entity, with exactly the same CSS.
There is a limit in version 1.0 that is upgraded in v1.1 But still there is a limit for dimensions:
In accord with version 1.1, the scope of the 31-bit limit on chunk
lengths and image dimensions has been extended to apply to all
four-byte unsigned integers. The value -231 is not allowed in signed
integers.
Source
A funny limit is IE6.0 fails to display PNG images of 4097 or 4098 bytes in size!
But these limits are very huge in compare to what we're using in web pages.
The typical rule of thumb when it comes to using CSS sprites for images is that you should only do it for smaller images (like icons) and that actual image content should always be represented through <img> elements. My question is: why? Aren't the advantages of spriting worthwhile for content images as well?
One reason I have read is to enable the use of alt text, to be more syntactically correct and accessible to screen-readers. However, when that is a concern, couldn't you just as easily use a single tiny transparent image with all the syntactical sugar atop a sprite that presents the real visual content?
You could, but:
Content images don’t tend to be re-used as much as UI-type images like icons. Imagine a newspaper site: if every content image they used in every story was part of a sprite, that sprite would very quickly get huge, and would be downloaded even by users who only looked at one story.
Website content is generally expected to be maintained by people who don’t know CSS. It’s a bit unreasonable to expect content editors to edit a master sprite image file, re-save out to a JPG, and pop in some CSS just to put an image on a page.
If you sprite a lot of large image files, the sprite file will get really large. It might take an unacceptably long time to download when the user first visits the page, or it might use up too much bandwidth on users who only end up seeing one of the images within the sprite.
Obviously, those are generalisations — in a specific situation, it might make perfect sense to sprite larger/more content-y images.
On using an <img> tag with a tiny transparent image file for sprites, you can do that for any sprite images — it’s often useful for clipping and positioning the sprite image beyond what background-position allows.
One additional reason I can think of, is search-engines; if you have an image with a descriptive alt-tag or a figure element with a figcaption, search engines will be able to find, classify and show it.
Sprites are usually usefull for static contents (images that are common on many pages).
Content pictures often appears in only one page, so you can't add it to your sprite file.
If you want to have real-time sprite generation, making custom sprite file with all your pictures, I think the generation cost is far more expensive than the duplicated HTTP calls it saves.
Sprites are here to save HTTP requests, but you should not waste server-side computation time to make it, nor put expensive and unusefull pictures in your sprite file.
Sprites should be used for common icons across the whole website and not for page specific content. When you use sprites for big images you get a lot of white space that is wasted.
According to http://blog.vlad1.com/2009/06/22/to-sprite-or-not-to-sprite/ this is also a problem:
Another (but much less important) downside is that if a sprite-using
page is zoomed using the full-page zoom feature that’s present in many
browsers, the browser may need to do extra work to get the correct
behaviour at the edges of these images — basically, to avoid adjacent
images in the sprite from “leaking in.” This isn’t a problem for
small images, but can be a performance hit for bigger ones.
From the research I've continued to do on this, another potential issue is memory consumption. Despite the fact that sprites may be compressed enough to download quickly, the footprint they fill in the client machine's memory is after the browser has rendered them, meaning it can be quite large, even for sprites with fairly small file sizes.
I haven't seen a definitive answer on whether or not this memory footprint is any larger than what one would see when loading the same number of images without sprites. I will be testing that in the coming weeks for the project that prompted this question, so I will return and update this answer once I have a conclusion.
Sprites are used to reduce the amount of requests to a server. The impact of lots of small requests is slowing the server more than one bigger request. But if the image of sprites, I like to call it sprite-map, is too large, it will also slow down the performance. The other thing of importance is like you sad the possibility for each single picture to give some name, to manage and to index by search engine.
I have a colourful background image that is 2000px x 1500px and because of the details I am saving it as a jpeg that renders at 1.1 MB. I am using the CSS background property to render the image. So being relatively new to web dev and working with a client/designer that's not open to a change of design at this point in the process, what should I do to help this image load blazingly fast. I don't know if it makes a difference but the site is using Joomla 1.5.9. This is something I've always wanted to understand but have had trouble uncovering solutions for... I hope someone can help!!
Thanks everyone!
There's no way to make images magically load faster. Sometimes, though, splitting an image in smaller images allows for surprising size gains; so if it's not out of question for your CSS layout (it typically is, though), you could try this.
Another possibility for you would be to use progressive JPEG images. They are encoded in such a way that enables browsers to display a progressively more precise image as it loads. This means that at first, the image appears blurry (or incomplete) but with full-dimensions, then it progressively gets sharper and better. It's well-suited for images meant to load slowly (or at least, images acknowledged to load slowly).
The best thing that you can do is try to shrink the file size to as small as possible. Let this be using some type of optimizer, smush.it for example. If you created the background image try saving it as progressive first, it loads a lower res version first then finishes loading. But the best thing is to try to shrink the size of the image width and height by finding a repeating pattern and cropping just that portion out and using it. Most about.me images are no larger than 100kb in size that are above 1200px wide.
you could immediatley call the image in the head by using
<script>
(new Image()).src = "IMAGE PATH";
</script>
and make sure you compress the image as much as you can with different programs, or if you have photoshop cs5 you can save it for a web device to strip out all of the extra junk, you can try yahoo's smush.it
http://www.smushit.com/ysmush.it/
or you could delay the loading of the site entirely for a few seconds, until you can be sure that the image is loading, you could try something like hiding all of the elements and fading them in upon a setTimeout something like
*CSS
body{
opacity:0;
}
*jQuery
setTimeout(function(){$('body').animate({opacity:'1'},300)},5000);
although that may not be all that practical.
Would loading the background image after the rest of the page has loaded work for you? At least this way visitors will be able to use the rest of your site until the 1.1MB has loaded.
Something along the lines of setting the style attribute of the <body> to be background: url(image.jpg) within an onload function?
Delivering the image over a CDN will likely speed things up; the better ones are usually optimized to deliver the proper TCP packet size/MTU to the wide variety of clients out there and have generally done a lot of work in the details of delivering things quickly. Slow connections like cellphones will still hate you for it, but getting things like packet size right can make the most of the bandwidth that is available.
I want to put images of the 1024x768 as backgrounds and load quickly using css. I could use
background(url....)
in the CSS, but will that solve the issue, of downloading images quickl?
Thanks
Jean
If you have to use this technique, then remember to compress and cache the image, this will speed it up somewhat, but try and be creative with alternative solutions.
For example can the background repeat on the x-axis? If it can you'll be able to create a 1px wide version that you can repeat across the page.
Try searching for this. It helps cutting off a few KB of data. PNG Gauntlet is also a free software for PNG compression that also cuts Gama correction that causes problems with IE6 and IE7.
Body background images are usually saved with lower quality, thus reducing size.
If your backgrounds are changeable, preload them. It is done by putting divs of zero height at the beginning of the page, and assigning background-image style to each. The images are loaded at the beginning, so when the background of the body gets changed the user doesn't notice the lag.
Google started to count the load time already, so classic preloading causes problems with SEO. Loading with JS, after the page fully loads is an option, or even assigning styles with JS after certain actions are made is also a solution.
remember you can't change the user dsl speed. so css background would be good. Maybe start with take a higher JPEG compression to minimize the file
(btw. i hate (full size) background images at websites with my dsl light)