I wouldn't imagine having two or more images would make much of a difference until you start reaching the max # of TCP connections per host, since these images would download in parallel. Would still be interesting to see results for.
Article author here -- I agree, it would be interesting to see results. One reason for using more than a single image: no navigation timing API in iOS.
iOS may now lag behind Android in handsets shipped -- but it's still a dominant player in web visits on mobile!
Unfortunately that means that for RUM tests I needed to have results that were insensitive to differences of a few ms.
Here's a petition asking Apple to include the navigation timing API in a future iOS release:
As someone who is grateful for your research and analysis, thank you, but filing a bug report is going to be WAY more effective, at least for iOS. https://bugreport.apple.com/ will get the ball rolling, even if it's been filed already. The more reports they get, the more likely they'll look at fixing the issue, especially if good use cases are provided.
I was recently looking into some prebuilt libs for emoji support on web. One of them had a sprite, the other used data URI's in all of the background-image:url() parts of their core CSS. The sprite was crunched down to about 500k after some optimization tweaks (pngout, etc.) the data uri version could not be optimized, it's CSS file weight in at over 5MB.
The decision was pretty easy to make after that discovery.
