![]() ![]() Recently I came across an API from a client that delivered images in part of the response as Base64 encoded strings. Here are the concerns we discussed which led the API to be changed to use URIs for images instead.Īt the end I consider a couple of cases where Base64 encoding could be a good option. ![]() API response payloads are large.īy including the data for every image in the API response, the response payloads started to get in the MB range. Over mobile networks, additional payload sizes matter. Larger payloads also mean more time for responses to be in flight and more time for (mobile) network drops. Base64 images are bloated.Īs well as a larger overall payload size, the size of the Base64 encoded image is approximately 30% larger than the original binary image. With gzip compression this bloat can be avoided if the alternative is raw binary images. However sizes will still be larger if the binary images are compressed. ) User Experience is negatively impacted. īy including all image data together in one API response, the app must receive all data before drawing anything on screen. This means users will see on-screen loading states for longer and the app will appear sluggish as users wait.Īlternatively, when an app loads images separately from the API payload, the app can show the data from the API and then progressively load the images. The effect is a more responsive app that feels faster to users. CDN caching is harder.Ĭontrary to image files, the Base64 strings inside an API response cannot be delivered via a CDN cache. The whole API response must be delivered by CDN.Īn API caching strategy can be straightforward if the API is not dynamic, e.g. During encoding, the Base64 algorithm replaces each three bytes with four bytes and, if necessary, adds padding characters, so the result will always be. However, with dynamic APIs there is quite a bit of architectural complexity compared to delivering static assets such as images via a CDN. Image caching on the device is no longer possible. Typically apps will cache images so they must not be repeatedly re-fetched. So in order to convey the same amount of information base64 requires 33.3 more bits compared to binary. However, if images are sent to the device as Base64 encoded strings every time within an API response, any caching capabilities on the device becomes irrelevant.Ĭaching on the device represents quite a major improvement for app performance, especially as app-level caching is very easy with mature libraries such as Picasso for Android ( ) or Kingfisher for iOS ( ). This means that every char(8 bits) contains only 6 bits of information. base64 is just a way to encode binary content with 'printable ASCII characters', and once decoded you just get the same binary content. Most content management tools handle images as binary files. To create Base64 encoded representations there will probably need to be some post-processing following image upload. This might require some custom logic that is hooked into your content management system. You will also need to watch for any adverse effects on database performance depending on your storage engine. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |