All website have images (well all the good ones). In fact most websites have many images. If you build a website where the public can upload images then you start getting hundreds and thousands and millions of images. At this point the use of the images and how they are managed becomes an area where significant thought and planning must be incorporate into the image management.

Generally there are 2 main options for images, both of which are going to be explained here. Dynamic and static images. This article assumes knowledge of HTML and server side scripting.

Dynamic Imaging
Is when you do magic with images. Images can be adapted to situations and edit/manipulated on the fly as they are requested by the clients browser. This type of image structure is extremely powerful, can save on programming time and hard drive space.

Static Images
Are still/static images on a server that remain the same. Using static images is not a powerful/diverse technique but is extremely quick and can save on much processing power.

So which one do you use and why?

The simple answer is both. It is a question of power and function vs speed and processing. Again it depends on the website and the situation. You may have a website that will be fine using only the one. But serious/large websites should be using both. However there is no hard and fast rule. It comes down the type of website, its traffic, skill level of developers, and the website’s objectives.

Let’s explain each type in some detail.

Dynamic Images

These are the images that are edit/manipulated on the fly. The image is delivered via a URL call, which will use some server side scripting. This then manipulates an image and outputs it to the browser. EG

This will then request image ’354â’ as a thumb nail. You can even go a step further and call

As you can see this is passing parameters to guide the processing of the image.

This page will then return an image to the browser in its newly reformed state. Images are called via

The most common form of this technique is to resize the images for multiple uses on the site. Other methods such as watermarking can be deployed.

The image.php page/file in the examples, has a series of processes and functions that can load an image into memory from the server, manipulate it and output it to the clients browser. These functions can also be used when saving images. For example an uploaded image can be resized and saved to the server as required. Most scripting languages have image manipulation functions. These are not discussed here. It is assumed that image.php has all the necessary script within.

What this allows for is images from the server to be used in many different ways.

Pros

• Only one version of the image needs to be stored on the server. This generally would be the largest desired size.
• The manipulations on the image are accurate as the mathematical calculations can be made on the exact image details. IE the process can get the required details for the manipulation directly from the image.
• The manipulation of images can be done via code rather than reworking all images. For example if there are 1000 images being displayed at 20px x 20px and they need to be changed to fit an area of 15px x 25px the code can be adjusted to suit. Each image does not have to be resized. Notice this is from an area that is square to an area that is rectangle. The script can crop the image to suit.
• The website will only download the adjusted version of the image. So if an image is shrunk from 1600px x 1600px to 10px x 10px then the client’s browser will only need to download the image at size 10px x 10px. If resized via HTML the image at 1600px x 1600px is downloaded and then resized. The can increase the response time of a website by reducing the download requirement of images.
• It is easier and quicker to use code to be able to manipulate an image whenever the need arises.
• Security can be placed on these images and other processes can be initiated. IE if only certain uses can see certain images, then during the manipulation of the image before it pipe to the server by the script the server-side script can check to see if the current logged in used is valid to view the image. If not then nothing is returned. This is also a valid strategy for other files types.

Cons

• The image must be processed. This takes processing time and power from the server. If hundreds of images need to be deployed then it can take a considerable amount of time and severely hurt the performance of the website.
• The image SRC reference for each image is to a webpage. IE
  <img src=”www.yoursite.com/image.php?id=354&max_height=200&type=crop” alt=”image” />

  This can give incorrect results in website statistics if not managed correctly as well as slowing down the site. If a page is calling 100 images, then essentially that is a call to 101 web pages (the 100 images plus the main page calling the images). Input/output calls of a website are generally the slowest part. So calling many pages from 1 page will slow loading time. Add this to other calls to RSS feed, social dialogs, etc. It can take up much time. This issue also puts increased load on the server.

• Bit more confusing to code. The script required for the manipulation is not the easiest to write.
• The image tag URLs do not looks very nice. These can be improved with htaccess rewriting If need be. However this is not too important unless you are looking to have web crawlers index your images.
• Image ID or other data may be displayed in the URL calling the image. These may need to be encrypted if you do not want to display IDs in code to the public.

Static images

These are images stored on a webserver and are provided to the client as is. They are not manipulated by the server side scripting and nothing really special happens with them. These images are called in the standard fashion ‘<img src=”http://www.yoursite.com/images/koala-bear.jpg” alt=”koala” />‘.

Pros

• Easy to understand and code. Just link the img tag to the image
• Can still manipulated image for resizing via HTML
• Does not require image processing or extra calls to webpages. Keep the website simpler and quicker

Cons

• HTML accurate resizing requires prior knowledge of the size of the image to include correct dimension in the image style. If image sizes are not the same some images will be stretch if they are all resized to the same size (for a group of images). Hence image file dimensions would need to be predefined when saving the images to the server.
• HTML rezsing is not capable of any other image manipulation. If the image needs to be cropped to fit a space, HTML cannot handle this (unless the image is used a background in a container (div), but this is a trick).
• Multiple versions of the same image in different dimensions need to be saved for the various ways the images may be used.
• Changing an image size or multiple images sizes, may not be a simple/quick task.
• No extra function or advanced control can happen with these images.

What to use when?

For consistent images, static images should be used. There is no reason not to. For example such as the style/design of the site. However some image in the design may need adjusting for various screen sizes and devices.

Generally speaking I would prefer to always use dynamic images on images that may be displayed in more than one size and if the image can easily be indexed (ie has an id and can be referenced). This is generally reserved for images that are uploaded and added to the site via admin or public. These are dynamic in nature as they have been dynamically added to the site and hence treated as dynamic images. They are indexed in a database and therefore can be referenced for manipulation.

Other images that are not indexed or only ever one size, will generally be static. If multiple sizes are required I will create these sizes to suit. If over time a certain static image is always being changed then I may start using a dynamic version of it.

The trick here is to use both. You will run into issues when you need to display hundreds of dynamic images on one page. This is where the problem arises. The process has the potential to break the site. Hundreds of people, view hundreds of pages and request hundreds of images. These images need to be processed which each are a page request in themselves. Kaboom. Your site has a heart attack.

This is the event that needs to be predefined/foreseen. If this kind of situation is the case then the dynamic images will need to have a static version of the image that is causing the issue. So if 200 dynamic images at 30px x 30px need to be displayed, a static version of the images at 30px x 30px should be created. Hence the website should request the static version and not need to process 200 images per page.

So some images you may have to save a static version of them to prevent from killing the site. I’ve seen servers come to a halt due to the massive amount of page requests and processing that is occurring. All because of these dynamic images. Hence using both types is the best option. Static to save server load and processing power. Dynamic for the flexibility. Of course if you want to protect your images or run other processes on them you will need to use dynamic images.

The real magic is when you get the dynamic images to dynamically create, and use, a static version of themselves as required. That little trick I will write a post about someday soon.