We hear about images a lot. Our internal audiences consistently request more images on their web pages. However, images need to be used strategically and don’t always have a net positive effect. This post will likely evolve into a number of posts/discussions, and may raise a number of questions from readers.


Whenever we are approached about a new project, whether it is a request for a new website design, a campaign landing page, or an update to existing page, the subject of images comes up. Generally speaking, clients default to the subject of images anytime they want to enhance the general feeling of a web page or site. This is completely understandable, images are very powerful at evoking emotional responses. The correct image can greatly influence people’s behavior, but there are a number of things to consider before images are adopted.


In a previous post, we noted that images were a primary reason why pages with carousels had reduced overall performance. The same can be said for any page that contains images. The reason isn’t the image itself, but rather the file size and the number of images on a page.

Would you wait 10.5 seconds for an image to appear?

We try to keep our images sizes as small as possible, but a large hero graphic can be up to 1.5MB in size. This can be a massive barrier for users on slower connections. For example, a 1.5MB hero graphic could take ~10.5 seconds to load for someone on a DSL connection (1.5mbps). This figure assumes optimal performance on a 1.5mbps network. However, these networks almost never perform at their advertised speeds; network congestion, and latency also reduce performance. In other words, a suboptimal 5mbps connection could operate slower than an optimal 1.5mbps connection. This number may also be used to simulate mobile users in rural areas where LTE connections aren’t available or when a mobile user is on a congested network.

Number of images

Using a large number of images (small or large) can also degrade performance. Have you ever visited a web site like, Instagram, or Flickr? If so, you may have noticed that sites like these may only load 20 small images or so on a page. Then, as the users scroll more images may load, either automatically or after a user takes an action to load more images. This method of implementation is used because of the performance degradation associated with many images on a web page. Generally speaking, this performance degradation happens for two reasons: memory usage as well as browser request/response and calculation.

Memory usage

Think about your computer’s memory like a bucket. Every time you launch your browser (Google Chrome, Firefox, Edge, etc) your computer allocates memory for that application to use; the bucket slowly begins to fill. The amount of space the bucket has remaining is dependent upon the user’s browsing habits and the size of the web pages the user has open. Each time you open a new tab, load a new web page, etc., your browser will request more memory from your system and that bucket will fill.

Web pages with images consume your systems memory at a greater rate than pages without images, all else being equal. There are many devices used to access the web and each device has a different sized bucket. Some computers have big buckets with lots of memory. Other devices with limited capabilities have very small buckets that fill up very quickly. Once the bucket of memory is full, this go awry. Web pages may become slow to load, unresponsive, or crash if the system has reached its limits.

Since every system is different, there isn’t a good formula for us to determine a computer’s available resources. We depend on the user’s computer to effectively manage the system resources. As a web developer, the best thing we can do is making sure our applications are efficient and consume as little memory as possible. However, this isn’t the only concern.

Browser request/response and calculation

Modern computers are very fast and are getting faster all of the time. However, no matter how fast a computer is, it may be limited by the network it is connected to. Many non-technical users are not aware that an image is not embedded at the byte level onto a web page. Instead, images are hosted on a server and requested every time a web page is loaded. If you have 10 images on a web page, generally speaking, a minimum of 10 requests are made to the server to retrieve the image for display. Each one of these requests costs time and bandwidth.

On faster networks, these requests may only be a few milliseconds. However, on slower networks it could take a second or longer depending on the size of the image. Once the image is received by the browser it must figure out what to do with it. The browser determines the dimensions of the available area and resizes the image according to the display. Most browsers will do this recalculation for each image that is loaded.

Guidelines and usability

Nielsen Norman wrote a great article titled “Image-Focused Design: Is Bigger Better?” discussing the current trend of using large images as leading content for many websites. It outlines a number of usability issues so well that I won’t cover everything here. Instead, I’ll focus on basic principals for choosing imagery for the web.


Images should be chosen carefully and reflect the goal of the page. The image should enhance, not detract the written material. Generally speaking, images of people perform better than other image types as long as the image is relevant to the content.


Photographic images and illustrations should be high quality and look professional. They should have proper lighting and be free from distraction. There should be a clear primary subject that visually communicates the content’s goal.

Avoid placing text in the image

Often, we receive images where a client has used Photoshop to add text to it. This should be avoided for a number of reasons.

  1. Accessibility: Users with screen readers will not be able to read text that has become part of the image.
  2. Device displays: The image may have looked great on the display of the person who created it, but it will not look great when displaying it on the Web. There are many devices with many different screen sizes accessing our websites. As a result images are often scaled to fit the devices display. This will often distort the image causing text to become fuzzy or unreadable.

Avoid using images to fill space

Avoid using images if you find yourself wanting to generally enhance the look, or if you are making up for a lack of content. Doing so indicates there are problems elsewhere.

Avoid images that look like ads

Users often only pay attention to images when they are relevant to the topic being presented. We’ve all seen photos of “smiling headset girl” and glossed over them because they look like they are trying to sell us something. Images that look like ads are also one of the reasons why display ad click-through conversions are generally low compared to other forms of digital advertisement.

In one of our recent usability studies, users commented that badges for awards like our “Forbes America’s best large employers” badge looks like an advertisement. Users didn’t even notice the images until we asked them.

Avoid stock imagery

High-quality imagery from our own institution is substantially better than stock imagery. Users notice stock images and will ignore them. Plus, it would be very embarrassing if we use the same stock image that our competitors use.

All images must have “alt” text

In order to meet our accessibility requirements all images presented on the web must contain “alt” text. This is text that a screenreader can read to a user that is hard of sight. This alternative text must brief, accurate, and relevant to the images current context.

Optimize images for the web

We recommend optimizing image file sizes using tools like These tools have very efficient compression algorithms that make the file sizes as small as possible. Additionally, images are formatted for progressive display, which can help the user feel like the page is loading faster than it really is.

Additional resources

Published by

Domsic, Robert T

Senior Application Developer

Leave a Reply

Your email address will not be published. Required fields are marked *