So far in this book, we’ve spent a lot of time discussing the performance impact of images in terms of requests and file size—characteristics that primarily impact the network side of things. However, there’s much more work being done under the hood by the browser to get an image to be displayed on a screen. These additional steps in the image loading process can have a significant impact on the processing time and memory footprint of your site.
As we saw in Chapters 2 and 3, when your graphic editor of choice creates the image file, it goes through a series of steps collectively called the encoding process. Consider the general steps included in the JPEG encoding process that we learned about in Chapter 4:
The graphic editor must covert RGB data to the YCbCr format.
The graphic editor applies some level of chroma subsampling to reduce file size.
The input is transformed from the color space to the frequency space by a Discrete Cosine Transformation (DCT) and further optimized using a quantization matrix.
Finally, the data goes through one last lossless compression step called Huffman encoding.
By the end of this process, the original color data has been transformed into a highly compressed bitmap. While this outputted format is exactly what we need to save the file efficiently, it’s not what the browser needs. The browser needs that color data—it needs to know what to actually paint for each pixel on the screen. Specifically, ...