Say, I have a simple website for my company with images:
---3 in in header (website logo, facebook/google+ logos);
---5 additional images for characterization.
The total size of images less than 1MB. So, should I use image cache in my website? What are the minimum requirements when website needs image cache?
Cache can be implemented on different levels.
The main idea is to store some results (generated content, calculations, etc) for some time, in order to serve these values more quickly, assuming they haven't changed in the meantime (or your scenario doesn't care about the data being slightly out of date).
From your description I deduce we are talking about a static webpage, and in this case, there is no real need for cache.
What you might want to do though, is a CDN, which can keep copies of elements (like images, or entire webpages) in a distributed network, and then use various mechanisms to minimize the time of delivery to the end user.
It's well described here, on the website of Cloudflare, one of the CDN providers. You can even setup a simple "cache" layer for free.
And to answer you question about the minimum requirements, there isn't such thing. It all depends on what's most important for you in your use case. Sometimes a very simple webpage needs to be heavily optimized, because it's visited very often, and sometimes, even a complicated one doesn't really need caching.
General rule of thumb, I think, would be to see whether the value of the resources saved will cover for the cost of implementing it.
Related
First of all, I'm not asking about the process of the upload itself using a server side language.
I just want to know which safety considerations I should take when using an uploaded image as a css background on my site.
The feature is exactly the same as Twitter does, allowing user use its own background image.
For example, is it safe to just place the image on the server and start using it? Can they inject some kind of code on the pages using that background?
I usually resize the image to a lower size, is this enough to remove unwanted "meta" data included on it?
There have been plenty of browser security flaws over the years that have been buffer overflows triggered by specially crafted malicious image files.
I don't know that there's any known flaws of this nature in current browser releases, but plenty of people will have old versions without any security patches, and of course new flaws do come to light every now and then.
This is tricky to resolve (and virtually impossible to be 100% secure against), but you can do some basic checks that the file is actually an image of the type claimed when it's uploaded. And resizing an image will almost certainly mangle any malicious code embedded in it.
There's also the more obvious risk that an image may show unsuitable material that you wouldn't want associated with your site. This can only be resolved by vetting images manually before allowing them to be used.
So yes, there are risks. But the risks are much lower if the images are to be viewed by the person who uploaded them (ie as a personalisation feature, in the way you describe on Twitter), rather than to be viewed by anyone. Obviously a person is less likely to want to hack their own computer, so the malicious image issue would be reduced, and if someone wants to put a nasty image on your site, but only they get to see it.... well, they obviously know what it is, or they wouldn't be uploading it.
I have an ASHX handler that I am using to display images that are stored in a database. I display the images as thumbnails and then full size if the user mouses over them.
How can I combine the images at runtime to produce CSS sprites for use in this situation?
If it can be done does anyone have suggestions on where to start?
UPATE
It seems like most people are saying this is not a good situation to use sprites in. I'm new to the sprite concept so please bear with me.
If I am going to be loading 30 thumbnails on a page from my database everytime why would it not make sense to pass them from the server to the client as one large image instead of passing 30 individual images? Wouldn't this be faster? Isn't this the purpose of CSS Sprites?
As far as the browser is concerned, an HTTP resource is an HTTP resource and it is irrelevant if the server produced it by reading a file from a hard disk, taking data out of a database, or spewing the content of a random number generator through an algorithm that would output valid PNG data.
You just need to generate your images from the data as normal.
That said, since the images are content, CSS would be an inappropriate tool to include them in the document. You should use an <img> element.
You have a couple options.
Your handler can combine the images on the fly that it gets from the database and send the whole thing down to the browser.
OR (and I like this one better)
You create the merged image at the time the images are uploaded to your site.
The second is better as the conversion only has to happen once and therefore means that you only have to spend those resources once. It does mean you are essentially storing 2 copies of the image, but that's fine.
UPDATE
I believe I misinterpreted what you were trying to do. I thought you were trying to combine the thumbnail with the full blown image. Instead, you appear to be really asking how to combine all of the thumbnail images.
In that case, it's even more of a bad idea. As David Dorward stated CSS is used to control layout. You're talking about content. However, the semantic issue aside, in the event you want to make tweaks to the layout your going to have to modify your code which creates the sprites to begin with. What if you decide to do 35 images? Or, change that to do 18?
By going the sprite route your pretty well screwed by being forced to modify code for any layout change which is NOT good style.
To cover that last question: wouldn't it be faster? Probably not. Under this scenario you would have to create the sprite on the fly, which introduces server overhead, which slows everything down. At most it might be a wash in the delivery time. At worst, you incur a large server and development performance negative impact.
Check out http://www.RequestReduce.com. It not only creates the sprite file automatically, but it does it on the fly through an HttpModule along with merging and minifying all CSS. It lso optimizes the sprite image using quantization and lossless compression and it handles the serving of the generated files using ETags and Expires headers to ensure optimal browser caching. The setup is trivial involving just a simple web.config change. See my blog post about its adoption by the Microsoft Visual Studio and MSDN Samples gallery.
I completely agree with David. Just a quick note regarding David's last point: That's only if the images are content. However, if they were part of the layout, then CSS would be appropriate.
That said, with this use case, sprites aren't a good choice. One of the purposes of thumbnails is to cut down loading time, which a sprite would make worse for a gallery. A better pattern might be using a lightbox or something similar with two images rather than one, with the larger being requested on demand.
Sprites are not a good solution here.
To answer your update, sprites are ideal for many small images, where the overhead of a new HTTP request outweighs the few bytes being sent for a small png or gif (e.g. 16x16 icons, etc). For larger images the time of the HTTP request becomes less important overall as the download time increases.
Packing images into a sprite also means that they will execute one longer request and other requests will have to queue behind it. If the important thing is to get the thumbnails showing quickly, then make sure those get loaded first before starting to load any larger views of the same images.
Any larger files that don't display at the initial page load should be late-loaded (window.onload) or lazy-loaded (as needed by click or hover actions).
I have a site where all the pages have the same header and footer, but vary in between on content. I'd estimate that 30% of the CSS is common to all the pages, with 70% varying.
What are the relative advantages and disadvantage of using one CSS file vs multiple for different pages?
Advantages of one CSS file
Only one HTTP request is needed to fetch it, which improves the first page load time for most users and will speed up subsequent page loads, especially if users are expected to visit more than one different page type during their visit. This can also decrease server load.
Advantages of multiple CSS files
Reduces bandwidth, particularly if any given user is not likely to view many of the different page types on your site during their visit (which may be the case if your site is divided into almost completely unrelated sub-sites). Note that multiple CSS files will increase HTTP requests, which despite bandwidth savings may actually decrease load speed on modern connections.
I'm generally in favour of having a single CSS file for a site in most cases.
Multiple CSS files requires multiple requests to retrieve the files from your servers -- this can introduce extra latency before the client can render the pages. A single CSS file would involve less latency and may allow your site to render that much faster.
The benefits of a single CSS file grow as client latency speeds increase -- so high-latency modems and cell phones would probably benefit more than broadband-connected computers.
I agree with the other answers that one file is generally better, and I'll add that in my experience, after minification and gzip (you are doing both, right?) no CSS I've ever served has been more than a handful of kilobytes. CSS files can get physically long in terms of # of lines of source, but when you crunch them down they are quite compact (and there's just not as much text there are you may think).
It's one of those things where optimizing CSS by breaking it out across pages can be done, but there are so many bigger things that you can spend your time optimizing that it's really hard to justify the effort there.
Adding to the accepted answer:
Advantages of multiple CSS files
Better code organization - easier to navigate them and know that changes don't affect pages other than the one you're working on.
As far as I know, these days there are two main techniques used for including CSS in a website.
A) Provide all the CSS used by the website in one (compressed) file
B) Provide the CSS for required by the elements on the page that is currently being viewed only
Positives for A: The entire CSS used on the site is cached on first visit via 1 http request
Negatives for A: if it's a big file, it will take a long time to load initially
Positives for B: Faster initial load time
Negatives for B: More HTTP requests, more files to cache
Is there anything (fundamental) that I am missing here?
Profile it. It depends on the way your users use your site.
If it's a web application and your users are likely to interact with it a lot and see most of the layout you designed, you probably want to use a single CSS which is loaded once and then stored in the browser cache. The first time overhead is negligible in this case.
If most of your users come with a cold cache and just look at two or three pages, separate CSS files will probably improve their experience.
You can't tell without having a look at what the users actually do.
Even a largish CSS file, gzipped, is tiny compared to a lot of other things (like images, movies, etc.) that get downloaded. The only real reason to break up CSS into separate files is to swap in special rules to make certain browsers behave (I'm looking at you, IE).
There is no A or B, it's always a trade-off between the two. For example: you'd want the front-page to load as quickly as possible, so you only request what's necessary. For the following pages you request the remaining CSS. A total of 2 requests.
In essence, you're creating packages/groups of related CSS. By dynamically combining and compressing these packages, you can create a maintainable structure of files. This also enables you experiment with the best combination of speed, performance, requests and bandwidth...
This whole story also applies to JavaScript files, since the same trade-offs can be made.
What's better?
Writing one css file
Writing more css files
What's better?
Tracking, keeping 1 css file updated
Tracking, keeping more css files updated
What's esier?
Making decisions what to insert into one css file
Deciding what to put in every of your css files
What's the cost of generating each individual css file compared to generating one global css file.
I'm in the process of optimizing a high traffic site. The site I am working on has many widgets - say 20 or so and only 7 are loaded by default. I was thinking of separating my css and image sprites for faster load times for the default widgets.
For the rest of the non-default widgets, I was thinking of having a separate css file and image sprite for each and every one. This way, when a user selects a non-default widget, I could dynamically inject the CSS file for that particular widget.
My question is - do you think this is OK to do or potentially worse for optimization since I would have more HTTP requests now since the non-default widgets would have their own css and image sprite files? Obviously though, the file sizes now would be cut down too.
Thoughts? Or anyone else who tackled the same issue?
do you think this is OK to do or potentially worse for optimization since I would have more HTTP requests now since the non-default widgets would have their own css and image sprite files?
Well, in the end that's down to mathematics and something only you can answer :) It will depend on what the actual numbers look like.
Keeping the default widgets' sprites in one file sounds obvious from what you describe.
As for the non-default widgets, If you have the technical means to do so, you could try analyzing your usage statistics. Which of the non-default widgets are being used the most? Are there some that stand out strongly from the others in terms of requests? Then build one image with all the necessary sprites for those, and keep separate images for the rest.
Also take into consideration whether the cost-benefit ratio is really good. Working out and using CSS sprites can increase maintenance costs in the long term, as updating graphics becomes a more difficult task that it was before. Now reducing the number of requests is a very important optimization technique, but there are other factors as well. Maybe the time and money saved by not using sprites could be better used somewhere else, like in improving the site's usability or buying new RAM for the server.