Challenges for High Resolution Images
Clone this wiki locally
Providing high-quality images to specific devices is no easy task, and for multiple reasons. Below are a few of the hurdles to overcome to meet this goal.
- Do not request for the same image multiple times. When the browser first sees an img element in the DOM it immediately makes a request for the image to the server (even before the DOM content is ready). The img src must be altered prior to the browser even seeing the img element in the DOM, otherwise its too late and the original image request has already kicked off. Additionally, if multiple requests were being made for one image, it not only slows down the client’s browser, but it also adds additional stress on the servers.
- Do not use the cookie trick. Most CDNs are on another domain or subdomain, which causes cross-domain cookie issues (not to mention one of the benefits of a CDN is to not send cookies in the request). The average user also does not have server-side scripting control over their CDN provider, which would be required to create server-side image resizing. Additionally, setting an image size using the cookie can cause caching issues because the image's request URL would be the same, yet the server would be sending back different image files.
- Do not use the base element trick. The base element trick could work if all the images were hosted relative to the webpage. However, this is not always the case, such as using a CDN or your own separate server. Additionally, using the base element adds extra headaches because not only does it alter the base URL for all the webpage’s images, but it also changes the URL to all the links, external style sheets, external scripts, etc., in the webpage.
- Minimal DOM manipulation. It takes time and slows the browser down to update the DOM. There should be as few DOM updates as possible to ensure all devices, especially low CPU devices, can handle the DOM manipulation.
- Minimal HTML structure modifications. Web designers should be able to still design the webpage with context images located in their appropriate locations within the webpage. If context images are not within the context of the webpage, then they’re not serving their purpose.
- Search engine crawlable images. Search engines should still be able to find and index images in the webpage’s context.
- No client-side user agent sniffing. While it is possible to scan through the navigator’s user-agent looking for retina display devices (such as newer iPhones and iPads), other devices will have high-resolution capabilities and its not worth the effort to keep up on that, nor is it a good plan to re-code whenever a new device is released.
- No server-side user agent sniffing. Same as point bullet 8, but on the server-side. While on each image request, server code "could" read the user-agent and respond with the right image request, again this is the same problem as bullet 8. You shouldn't be maintaining a database of devices. Additionally, there could be caching issues as requests with the same URL would be responding with different images.
- Do not provide high-quality images to everyone. The majority of users do not have high-resolution displays (such as most desktops and laptops). To have servers respond with larger images to all users adds an extra strain on the servers, clients, bandwidth, etc. Only serve high-resolution images to those who can see their true beauty.
- Do not use CSS backgrounds and media queries in place of context images. Media queries are a modern and excellent option for requesting high-quality images, but they can only assist background images when it comes to images, not context images which the img tag provides. CSS Background images will not print and search engines will have troubles associating background images to specific content in the webpage (or even finding the images at all). Absolutely use media queries where appropriate, but they are not the end-all answer for high-resolution displays.
- Customizable Image Request Formats. If we all used the same image server this wouldn't be an issue, but instead there are various ways to dynamically request images from servers, whether the images are static or dynamically resized. Some use 'w' and 'h' querystrings, some have the dimensions directly in the path, while others will have the image's scale factor directly in the filename. How each image server request is formatted varies, which leads to the conclusion that any image request format should be possible, no matter if they are dynamically resized or static.