I wonder what the best trade-off for combining images for CSS sprites is.
Say I have 50 images, but each page only needs 5. The total size of a sprite image is 100kb.
There obviously are a dozen of parameters, how many pages are visited in each visit, the connection speeds of the users, the lag. I'm not looking for a mathematical formula to compute the best trade-off, since I cannot estimate these parameters precisely enough.
So, do you have any experience values on when to combine images to a sprite and when not. (Actually, the "not" is more interesting IMHO).
Do you put all images on a sprite that "could" be needed for a single page, but anything that will only be needed by a second page on a separate sprite?
In my opinion, only group images together in a sprite if they are relevant.
If you have a menu based off of images, I'd make one image with all of the different elements in the menu. If you have a list with icons that appear on hover, make a spritesheet with all of those icons. It does you no good performance-wise to create one huge image when that same image can be combined into three or four smaller images.
It also helps to have only related images together - it keeps your CSS references to the files easier to follow and you have less complex x/y coordinate references.
here is my two cents... I usually try to sprite images for a given path that i am expecting to be hit harder then others. For example; if my sites so i call the critical path is: user logs on, goes to the home page, checks out today's deals, purchase one and logs out, i would like most of the common images sprited (logically grouped if needed) on this path. Having the sprites here will eliminate a lot of extra requests.
If you go google.com you will see a sprite (nav_logo99.png) that has most of the common images you will need on the very likely next page(s).
Also to answer your "when not to sprite", background repeat and CSS sprites does not blend well so i will stay away from those.
The thing I take into account is how many pages my user will visit. You have to remember that you sprite will normally be cached so only ever loaded once.
If your site user runs around a few pages then its fine having a larger file but you are correct if most off your users only visit your home page then your not going to want to load all your sites images in one sprite.
Its best to just go on your own feel off what is best to optimize into sprites
Related
I have a single page using CSS columns that reflows on load.
Even when I remove all IMGs and iFrames, so it is fetching no
external resources, it reflows.
I can't figure out what is causing the reflow/repaint. Any CSS exports
out there able to figure this one out?
https://github.com/treenotation/dumbdown/issues/8
There's too much content in document.
The browser will gradually display the content, that is, the content involved in rendering will gradually increase, which affects the layout calculation.
You can add the "loading state" style. When window.onload Event trigger, change the style to "load complete".
Or 'Masonry Layout'.
Reason for the reflow is: a huge amount of content but NO strategy to handle with. Indeed there are many things you can avoid/do/change ...
REASON WHY - just to base the answer ...
The reflow is caused by the mechanic: at first the text (html code) has been downloaded and rendered. But there are still a lot of elements (most over images but youtube videos and iframes as well) which are still on download. As the browser don't know the size of that elements he does not keep the place for that elements.
Now: after the download and rendering of every element has finished the browser injects the element to the content and all off the following content is pushed down and in your case to next column ... reflow.
STRATEGY: MULTIPLE ACTIONS
To your question: there is not only one reason which causes multiple and long downloads. So far there is no simple single answer and even NOT A SINGLE SOLUTION. Your needed strategy will be to optimize the page by a multiple bundle of actions. But I believe doing that you can reduce it to an acceptable amount ... and maybe there is a chance.
THINGS YOU CAN DO
1. Change layout
If you change the layout to an actual web technique. That means don't use columns (flowing left to right) to a style which prepares the pageflow from up to down. Than you can asynchron load the needed elements when the user scrolls down. The technique is named Infinite scrolling: How to do an infinite scroll in plain Javascript
But I assume as the special layout has charm this won't be an option for you!?
2. Images which are not shown - remove not needed elements from download
On your page I found images which are downloaded but which are not shown on the page. (Example: 3.png with INCREDIBILE USELESS 659KB). Remove such elements from your content.
3. Reduce not needed size of elements
Additional a lot of shown images on your page have an incredibly large file size which is not needed.
Example: devices.png
image-size: 692x285px - real size
layout-size: 287x118px - needed size
file-size-download: 110kb
file-size-needed: 4kb - if (lossless) optimized
And think about: many little file downloads add up to a big amount ... and you have a lot of downloads! If you calculate: 10 images your way: 1.1 MB can be done with 40KBs
Additional:
if you you need higher solutions use srcset attributes ...
sometimes that is a practical problem with the knowledge of the editors: than teach them how to lossless reduce images and advise them the sizes to use for the images in the layout
4. Use faster server for images
It seems the download rate from your server is not the fastest one. That's normal by most providers. As you have a lot of images ... think about to load images from a faster server - if possible. Example: the pure download service from AWS (Amazon Web Service) is incredibly fast. As you just need a bucket for downloading that is not as expensive ... try it out.
5. Use placeholders for elements
As you have a lot of elements I think you maybe cannot avoid the later injection which causes the reflow. But you can use placeholders for your element so the needed place is reserved and the reflow still does not happen for this element.
Just define the html structure and possible sizes in your layout. That additional helps the editors as they know what image size they can use. Then size the placeholders with CSS and initiate an ajax image download by JS.
In case of later download now the users maybe see a placeholder at the beginning but no reflow. You can do that with few lines of code. I attach an example at the end of the posting.
NOTE: You can do this with (youtube-)videos or iframes in a similar way ;-)
6. Use vanilla instead of jQuery
As I saw has the download of jQuery an incredible impact to your download time. Really. (That's the reason why I assume your server is a slower one.) Have a look to the download time of your elements. It is one of the elements which needs the most times and blocks your elements from rendering.
jQuery is an old dog. Modern web techniques use vanilla JS ... and as I see there are no complicated things on your page you cannot realize in vanilla. So the recommendation is to remove it from you page (if possible) and you will earn a huge speed advantage.
7. Use CDNs for download when possible
Downloading frameworks and fonts from own server makes pages slow and blocks time for the page download of other elements. Use a CDN instead.
As I have seen your fonts are loaded from a CDN? But jQuery still comes from your server. If you don't want to change to vanilla chose to load it from CDN.
8. Check if Youtube can be loaded more simple
Youtube is loaded by several actions to your page. In this case I AM NOT SURE as I still did not work with youtube for a longer time. But I believe (not sure if I am right) that there is a more direct way to include youtube videos to a page. Maybe you would like to check it.
But nevertheless: work with placeholders for the video players as well. That are almost just few additional lines off css.
9. Optimizing user experience: thinking about a preloader
Reflow is not new phenomenon to webpages. Up to now a lot of pages uses preloaders to generate a better user experience. Today's technique is ajax load...
I don't know if the described techniques will avoid the reflow completely. As there are many elements the download time cannot be set to zero. But optimizing the page will reduce it dramatically. If there still remains a little bit ... maybe you like to think about the older technique. Using a nice and maybe well designed preloader symbol indeed can upgrade the user experience. Maybe on mobile views with medium data speed there is no other chance...?
But that is just to think about an additional possibility ...
[update]
10. Combine placeholder with infinite scroll
If you are using placeholders you can/should combine it with technique infinite scroll.
Means: all media (particularly images but maybe videos and iframes as well) are prepositioned by sized placeholders. That works immediately so there should be no more reflow as needed. Then load media assynchron by AJAX based on their position on their screen. Images which are in view are loaded immediately.
As you don't have so many media elements on starting viewport (most are still below the screen view) that should work as if it is a page with a 'normal number' of pictures/medias.
All others are loading afterwards when scrolling the page the media comes in view like on a 'infinite scroll page'. (Note: that works if the file size off the images is not to large, - so optimizing the images has still to be done.)
That has the additional advantage that thake makes sure that the images are loaded in the sequence they are needed ... which safes a lot of time.
Could be done in javascript:
Place images/media by placeholder technique
On window.onload check which images/media are in the viewport. Don't forget images which are only partly seen.
On window.onscroll check if image(s) comes to viewport and load image
Note: I am not quite sure if there are anchor links on your page to the single articles. I believe not. But if you still use them the starting viewport can be anywhere on the page when the user call an article. In that case window.onscroll has not only to work scrolling down but scrolling up to.
I am not quite sure if there is a ready script avaiable. But I would wonder if not. Otherwise it would not be to tricky to do that on your own. That would have the charm that such scripts mostly have less and cleaner code than preworked scripts ...
[end update]
... ... ...
I am not quite sure if the described issues are complete. Mostly there are found more possibilities to optimize a page when you start with the process. But as I had a nearer look to your page that are the most important chances.
EXAMPLE LAZY IMAGE LOAD WITH PLACEHOLDER EFFECT
Just EASY AND SIMPLIFIED example for lazy image load. Please adapt to your need.
// new html for image
<img class="placeholder-size" src="path/placeholder.jpg" data-lazy-url="https://url-to-your/imag.png" alt="Image Description">
// css
.placeholder-size {
width: 200px;
height: 100px;
}
// js for lazy load
// older code but works, please actualize if needed
window.onload = function(){
var lazyImages = document.querySelectorAll('[data-lazy-url]');
for (var i in lazyImages) if (lazyImages.hasOwnProperty(i)) {
var imgUrl = lazyImages[i].getAttribute('data-lazy-url');
lazyImages[i].src=imgUrl;
};
};
For queries that Google interprets as pertaining to shopping, it populates a horizontal banner w/ (5 or so) sponsored product images # the top of the search results page (before listing any actual hits).
I use Dark Reader a lot & try to contribute by fixing any especially ugly automated inversions (as the creator merges user modifications daily) as I notice them.
Yesterday, I noticed that some of the aforementioned images were barely visible, I figured that they were mistakenly inverted so I inverted them once more to discover that I was wrong. After disabling Dark Reader, & following a few of the image links, I found that they were purposely made transparent (as in the actual pictures, NOT just the backgrounds). I saved & added a layer behind 1 of them, to illustrate my point...
If they only cut out the backgrounds & left the rest of the images alone, wouldn't the file sizes (& therefore the storage costs) be minimized?
Do they save money in some other way? Or are there any other reasons for why Google would serve images this way?
I want to have a website page load images faster or where the images don't stop the user from seeing the text on the pages before the images finish loading.
1. if I have text on a website page. Does the text render first so the user can see text while the images are still loading?
2. If i have 3 mb of images and have my server that is hosting the website render 1.5 and then move the other 1.5mb to something like flickr and have the image source point to flickr, will that be better and load faster. Or say I just have all the images pull from flickr?
Please help me.
Its a WordPress site, and Clouldflare free cdn does something weird to my theme. So not an option. I also don't want to lazy load for other reason.
EDIT : o yea, if I host all the images on Flickr does that give away link juice (Domain Authority Rank)?
Images do increase overall load time, but they aren't render blocking. The whole page will render (barring render-blocking CSS or Scripts) and images will pop in when they are done. If you want to avoid that flash, you can lazy-load them, or otherwise put the final image's sizes on a container element, so the text is already "moved".
You can't really "Speed Up" image loads. The best thing to do is cut down on the number of images, if applicable, and lazy-load any that don't need to be requested initially. The next best thing (and arguably more important overall, I suppose) is to optimize your images. There are a handful of WordPress plugins that will do this for you, or you can do it in PhotoShop - and even some image CDN's will do it. This basically means, don't load a 1MB image if you don't have to, for "web display" purposes, you can serve a 200kb image that looks almost as good.
A side point, you can "speed them up" a little by having them served from a faster server, but that goes for anything web related. Throw it on better hardware to get better performance (for the most part).
If they are large images, you should first and foremost, optimize them. Make sure they are the smallest file size possible. Also, don't bother splitting "1.5mb" of them over to another host. Either upload them directly all through a CDN (some even tie into your WP Library, like Cloudinary), or keep them local to your site. You'll save yourself some headaches later.
If you have a photo heavy website (photography or other types of galleries), 3mb isn't really an awful lot - but again it's best to serve a more compressed image, you can even link the image or a button to the "full resolution" one.
I want a header image in my HTML to be random. I have accomplished this by using this php file, however I would like to do something different. I want to have the random images be a part of one sprite. That way the images can all load at the same time and they user won't have to see the images load when navigating to different pages. I would also like to choose the random factor, i.e. show this picture 50% the others 10% of the time (if there are 6 pictures). Is this even possible and where would an amateur start? Is this the best way to implement my scenario so that the user sees as little image load as possible?
You could have the sprited header style declared in CSS as you normally would, and then simply adjust the xpos/ypos of the sprite in-html. You would be able to recycle some of the logic you already have and manipulate individual header probability.
I'd stick with individual assets though, especially if they are the size of a google doodle. Easier to extend that way and, assuming the rest of your static content has already been cached, any overhead of downloading a new image would be negligible.
I need to create a site that is very graphics-heavy (torn paper backgrounds with transparent shadows over textured graphics, etc.) One way that I was thinking of saving on file size was to drop all my background elements into one PNG. The issue is that this file is now 180k. If I break it up into various GIFs and a couple PNGs then it would be closer to 70k.
Does it really matter? What is "too large" these days for file size? Will anyone notice if the file is 180 or 70k?
If your users have fast access to your site (like, in an intranet), 180k is hardly a problem. If, on the other hand, the site is used by The Generic Older Person With A Humorously Slow Connection, it's probably going to be a problem. If your users use GPRS, but have endless patience, it's probably not going to be a problem. If the site gives out a million dollar to whoever has the patience to wait out the load time, transfer speeds are not an issue. And so on.
What I'm saying, it really depends on your requirements and constrains. This requires you to know (and subsequently tell us, for us to be more helpful) many things before you can get it close to right.
To avoid those pesky downvotes for very-valid-answers-but-simply-doesn't-please-someone, here's my answer:
180k divided by a standard ADSL modem transfer rate = 180kB / 100kB/s = 1.8s = endurable.
Is there a reason not to use the smaller images? It sounds like you've already broken it up, so why not go with the smaller, faster method?
From a pure relativistic point of view, 70k will take only 38% of the download time that 180k would (approximately). If you're expecting high traffic or want fast load times, every bit helps.
You have to compare the time it takes to request all the separate images and the time it takes to download the one large one. The issue is with HTTP requests.
I suggest you run some tests with Google's Firefox extension, Pagespeed to see if there is a huge difference between the large png or the separate ones.
One benefit I can think of, besides fewer HTTP requests is that your site will load all at once instead of gradually as all the graphics are downloaded. The bottom line however, as Henrik said is that it depends on your requirements.
I'm sure you're aware that splitting into multiple images means additional connections to the server to retrieve them, with associated lag on each, and the additional size of the request and response headers.
Since browsers restrict the number of active connections to each server (browser version dependent) this may end up taking longer than retrieving a single image. The usual workaround to lift the limit is to use a separate "images" server, or a DNS alias that maps to the same host.
And unless you require animation, I'd always recommend PNG over GIF.
Make sure that the site looks fine with images disabled first (so alt tags, width and heights set, correct colours used) and then split the images based up into groups. Group all of your buttons into one image if possible (using css sprite sheets), and all of the borders into another. Keep large images in separate files (so site background, headers).
The more images you have, the more the browser can parallelize the requests. However, if you split them up too much then different images will load at different times, making parts of the site pop in. It's a bit of a trade off, but that's the joy of programming :)
The better your site looks before the images are visible, the less the user will mind the speed of downloading the images.