If this is a question that shouldn't be on SO, please let me know.
Has anyone tried the website:
http://csssprites.org/
To autogenerate and use CSS Sprites? What are your thoughts? I'm thinking about implementing (constantly looking for new ways to improve performance)
Yes, sprites speed up a site because
less HTTP requests
avoid small overhead every image has
They make sense for icons etc
Downsides are
More difficult to change one icon
Can't cache control individual icons
I used CSS Sprites to create my first sprite, but I tend to chop them together myself now as I personally find it easier to create strips-of-sprites (i.e. long and thin) rather than big square sprites as its easier to update them if you understand the convention used to create them.
If you are using .net, 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.
Related
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'm wondering if it's better to make one or several files for CSS files ?
I always see websites with a plenty of css files, but it seems better to use only one large file.
What's your advice ?
Performance wise, you are better off with a single file, as it results in one connection and request to the server (these tend to be expensive operations, time wise).
This is why minifying frameworks exist, that merge together all the CSS (and JavaScript) files for each page and serve them in one request.
My strategy on this is simple.
I separate production from development, both in CSS files and in JS files.
in development, I can have up to 20 JS files and 10 CSS files, organization is super slick and easy, I always know where everything is.
In production, all files are minified into 1js and 1css file, changes are always made in development and then "staged" to production so I gain the maintainability of the application and the performance in production.
I use Yahoo minifier to minify my files but you can use whatever is convenient for you.
Having one CSS file doesn't just help with HTTP requests, it will also give you better compression (compressing one big file should give you better results than compressing multiple smaller files).
Different HTTP requests are hardly the bottleneck here, file size ultimately is. The reason it's best to split things up as much as possible is because if you want to change a certain thing of your site's feel, let's say, the font of all headers, you want to change one file / setting only for that, and want that file to be as small as possible.
For large and encompasing CSS, I would make different CSS documents for all different things like the layout, the treatment of classes, and so on, another advantage is that if you've multiple pages that need a slightly different look from the main page, they only have to link to one other CSS file, not to a completely different one, the majority they an share.
If performance does matters to you
Then
If your site is small but gets huge traffic then go for one css file
if site is small personal or business sites then but with less traffic then go to multiple css
If CSS files maintainability does matters to you
Then
If your site is small with less different pages then go for one css file.
if site is big then go for multiple css http://www.killersites.com/blog/2008/how-to-organize-css/
HTTP request of CSS files will not make big difference in performance of small site.
Use not too much different css files or at least try to put them on other domains to speed up downloading them by the browser. I also suggest you use a minification tool.
Well, the same as Yahoo!'s: Use one to reduce the number of HTTP requests.
For the quickest download and rendering of a page, the Yahoo performance rules are correct. You want as few http requests as possible.
However, on many sites, it's simply not convenient to have a single large CSS files. Your best bet is to organize your CSS into as many files as you'd like, and then use a server side script to concatenate the files. GZIP'ing that file goes a long way, too.
you should use more than one css file rather using one big file. It helps you while maintaining your site also use different definitions (classe or id names) in different css otherwise it will take the one which declared later.
But for performance reasone you can use one large file because,
One large CSS file leads to fewer HTTP requests, which can improve performance.
Several smaller files leads to easier organization which will make development and maintenance cheaper and easier.
Multiple files are good for organization, but one request to the server is definitely best. If you watch the performance videos from Google they suggest the least amount of HTTP requests possible. Each HTTP request has overhead in the handshake that you do not want to incur if you wish your site to be fast.
Check out this great script which will take your multiple CSS/JS files and turn them into one file:
http://code.google.com/p/minify/
Weigh it up.
The advantages of one CSS file
Reduced latency. Each downloadable component comes with a small amount of latency. Less files => less latency
Single point of compression
Advantages of multiple
Change one file won't require all css to be re-downloaded. The other css can be served from the cache
Structure
Only download what you need. If you don't have any forms on your page for example you don't need to download forms.css
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.
I've recently begun working on a very large, high traffic website. We would very much like to reduce the size and number of our style sheets, minification is one route we will pursue but is anyone aware of any tools for checking ID and class use? Literally scanning the website to see what's active and what isn't?
Alternatively any software for redacting the css to reduce repition and size?
Thanks in advance
Literally scanning the website to see
what's active and what isn't?
Dust-Me Selectors is a Firefox plugin that you can use to show what css rules aren't being used.
http://www.sitepoint.com/dustmeselectors/
I can certainly recommend Page Speed (http://code.google.com/speed/page-speed/) by Google to check the performance (and possible improvements) of your webpages.
Page Speed also checks CSS and usage of classes on your webpages.
It is used in combination with Firebug.
Gzip compression in the webserver.
Expiry dates that lie far in the future to avoid redownloading the CSS files.
Alternatively any software for
redacting the css to reduce repition
and size?
Yet another level of indirection ... You (and your team) should write long CSS files with as many comments as needed and then write a tool that will publish merged files as needed (different templates need different files), stripped comments and minified as http://www.cleancss.com could do (CSSTidy). Readability comes first if you wan't to be able to modify a file in 1 month or keep track of modifications (or worse if sb else must do that!).
Other options are to reduce the number of templates used throughout the site. No need of two templates with 2px differences (grid layouts are a good way to stick to this) or inconsistent ways of displaying error messages. Define a common look and feel to your site and give instructions to webdesigners, if it isn't already done.
A couple of years ago, we had a graphic designer revamp our website. His results looked great, but he unfortunately introduced a new unsupported font by the web browser.
At first I was like, "What!?!"... since most of our content is dynamic and there was no real way to pre-make all of the images. There was also the issue of multiple languages (since we knew Spanish was on the horizon).
Anyway, I decided to create some classes to auto-generate images via GDI+ and programatically cache them as needed. This solved most of our initial problems. However, now that our load has increased dramatically, there has been a drain on our UI server.
Now to the question... I am looking to replace most of the dynamic GDI+ images with a standard web browser font. I am thinking of keeping some of the rendered GDI+ images and putting them in a resx file, but plan to replace most of them with Tahoma or Arial fonts via asp:Labels.
Which have you found to be a better localized image solution?
Embedding images into the resx
Only adding the image url into the resx
Some other solution
My main concern is to limit the processing on the UI server. If that is the case, would adding the image url to the resx be a better solution compared to actually embedding the image into the resx?
You should only need to generate each image once, and then save it on the hard disk. The load on your site shouldn't increase the amount of processing you have to do. That being said, it almost sounds like you are using images for things you shouldn't be. If there are so many different images that you can't keep up with generating them, it's time to abandon your fancy images for things that shouldn't be images, and go back to straight text. If the user doesn't have the specified font installed, it should just fall back to a similar looking font. CSS has good support for this.
see my response here
This can be done manually or using some sort of automated (CMS) system.
The basic method is to cache your images in a language specific directory structure and then write an HTTP handler that effectively removes the additional directory layer. eg:
/images/
/en/
header1.gif
/es/
header1.gif
In your markup or CSS you would just reference /images/header1.gif. The http hander then uses session (if language is user specific), or config (if site specific) to choose which directory to serve the image from.
This provides a clean line bewteen code and content, and allows for client side caching. Resx is great for small strings but I much prefer a system like this for images and larger content. especially on the web where it is typically easy to switch images around.
I had the same problem a few years back and our interface team pointed us to SIFr. http://wiki.novemberborn.net/sifr/
You embed your font into a Flash movie and then use the SIFr JavaScript to dynamically convert your text into your font. Because it's client-side, there is no server-side impact.
If the user doesn't have Flash or JavaScript installed, they get the closest web-friendly font.
As an added bonus: because your content is still Text -- Google can search and index the content -- a huge SEO optimization.
Because of caching, I'd rather add only the image url into the resx. Caching is much better for static content (i-e plain files ) than for generated content.
I'd be very cautious about putting text in images at all, CSS with appropriate font-family fallback is probably the correct response on accessibility and good MVC grounds.
Where generation really is required I think Kiblee and JayArr outline good solutions