i have an old cms (classic asp) where for every image that the editor is upload i save 3 images (small,big and original).
the size of the images are pre defined in the db (for each modul difrent size).
now in the new CMS (asp.net) that i build i think to save just the original and create images on demand with the right size?
did it's ok? i will get better flexibility but maybe it will be slower?
Machines are super fast today, but that doesn't mean you shouldn't "help" them do their work :) Resizing images on deman is resource intensive. Think about situation where you have hundred concurent request that are resizing same image.
I think you should combine both solution. Use temporary cache for let's say, last hundred image requests. Optimization of this kind of solution depends primary on site traffic, so you should keep cache size as configuration option.
Related
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.
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 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 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.
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