For a build I am currently working on, I was faced with a decision that I make about 20 times per page for every project: What is the best way to handle an image that is two different sizes on mobile and desktop? If the image is a content managed inline image then I would use either picture and srcset or a jquery responsive images polyfill such as picturefill. This all depends on the browser support required for the site we are building and the content management system (CMS).
But if the image is not content managed and a background image these are the options I find I am choosing between:
Serve up the image sized for mobile and then swap that out and serve up a different size for tablet and desktop
The cost with this option is that I am creating 2x HTTP requests on desktop and downloading two files, but on mobile I have only 1x HTTP request and a smaller file. Checking the design I am working on today, the file size at mobile is 21.1KB and at desktop is 43.1KB. That is a combined download at desktop of 64.2KB. This is where network latency should also be considered. To estimate the download time we consider a 5 Mb/s connection with a ping time to your server of 80ms:
Mobile - 1x 21KB file: 80ms latency + 32ms transfer time = 112ms
Desktop - 1x 43KB file and 1 x 21KB file: 160ms latency + 65ms +32ms = 257ms
Compare this with another solution:
Serve up a sprite with the two images at the size they are needed and use the background-position: property in CSS to show the correct image
With this option the downfall is the file size which is 86.3KB, which is larger than the two combined. This option does, however, reduce the HTTP requests to 1 but the image could be harder to edit in future and css changes would probably have to be made. Based on our estimated connection speed and ping time:
Mobile & Desktop - 1 x 86KB file: 80ms latency + 131ms transfer time = 211ms
This demonstrates that one larger file with one HTTP request at a 5 Mb/s connection with a ping time of 80ms is a better option than loading the two smaller files for desktop. However, if the mobile user is your focus, Option 1 is a better choice.
We also have one other approach to consider:
Serve up the larger image only for mobile and desktop in an absolutely positioned div and resize using CSS.
The downfall with this option is the obvious inclusion of a non semantic div but we can control image size and swap out the image easily, if necessary. This option also provides us with only 1 HTTP request, loading the larger file for mobile and an added a non-semantic div.
Mobile & Desktop - 1 x 43KB file: 80ms latency + 65ms transfer time = 145ms
This third option is the option that I will go with on this example as the transfer time is much faster for Desktop and not too much slower for mobile. I can also live with the non semantic div in this case.
In the case of filesize vs HTTP requests, there are many options to consider, but all should be considered to find out what is the best option to make the site you are working on perform quickly and efficiently for your target audience.