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.
Related
I am building little shop application and now thinking about the faster way, how to upload images - I need images in 4 sizes. The first idea - from upload create 4 thumbnails and that's all - probably the easiest way, but what I am worried - creating 4 sizes through upload can take lot of time... that's what I don't like and I would like to avoid it.
The second idea is upload image - for example in the size 300x300 and in a moment, when I would need in the shop display thumb of this image, so in HTML and CSS I just set the value :style => 'width: 165px;'.
What you think about that? What would be the best variant?
I don't think this question relates to rails, but is a more general one.
Typically, you do want to create the images in all sizes they would be utilized. Creating four sizes at the time of upload doesn't usually take that much time (I am referring to uploading the image once and then creating the needed images on the server side based on that) - at least if you compare it to combined time of users all downloading the biggest size image and then resizing it on the fly when all they need is a small thumbnail. Normally, uploading the images does not happen that often. Generating the other images could also possibly be deferred to a scheduled job that would run nightly, so it wouldn't impact the user experience on the admin side.
That said, if your users have to anyways every time download the biggest image, it would be in the cache anyway and no extra overhead would incur if you then resize it using css wherever you need it in a smaller size. In that case I would think it would be ok just to use the biggest size. Usually you can avoid using the biggest size images on most use cases.
Use the carrierwave gem to manage your uploads. Configure the gem with multiple "versions".
As eis suggests, processing the images is not the performance bottleneck, but if you really want to get fancy use the delayed_job gem to handle the processing asynchronously.
When configuring carrierwave, you will also need to setup the actual processor. I use the full-blown rmagick, but you can use minimagick which is simpler to setup. It's all detailed in the carrierwave readme. For rmagick/imagemagick, here's a thread that touches on that.
Also, as eis suggests, images are generally cached reliably by the browser, and these days browsers do a decent job of resizing images on the fly, though generally, the better the processor, the better the results, and that's why I use rmagick.
One last note, unless you can dictate what users are selecting for upload, you will most likely need to process the image at least one. E.g., someone might upload a huge 8000 X 6000 pixel image with little compression. You would not want to serve up that image since you have less control. And once you've gone to the trouble of setting up the image processing, it's a trivial thing to add a few more output sizes to fit the various display contexts.
I don't know much about speeds and all of that, so I'm not sure if a huge stylesheet would show significant changes in the loading of the page or not. To keep it simple, I want to use a stylesheet that covers all areas of the website using IDs, like #forum div.menu or #game div.menu. Knowing that this would make the stylesheet large, I'm uneasy about it being too much. Could someone provide insight on the significance of the size of a stylesheet and perhaps some specs?
If your users are going to be using all those styles anyway, it is usually better to serve it in one stylesheet because it reduces the HTTP requests and allows the browser to cache it all. However, if you have a lot of CSS for only one page that is not commonly visited for your users (and it is enough that including it in the global stylesheet adds a bunch of weight and would add a substantial amount to the file), it may be better to put it in a separate file.
Bigger stylesheets are better than smaller, multiple stylesheets when trying for speed. HTTP requests are one of the main reasons of slowing your webpage down. Its the same with images. One big image is far better than a lot of littler ones. Here is a good link for reducing your http requests: http://www.dailyblogtips.com/speed-up-your-site-reduce-the-http-requests/.
You may find this Yahoo Developer Network article very useful.
It has a number of sections regarding optimization of CSS
for your site.
"Best Practices for Speeding Up Your Web Site"
http://developer.yahoo.com/performance/rules.html
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).
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.
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.