- JPGs aren't good at rendering text (referencing #1). It doesn't handle sharp changes in contrast. That's simply how the format was designed. Likely better usage would be a PNG-8, but even then, you're looking @ a lossless format.
- Since you're dealing w/ images, the clients in the market will quite often demand some retina resolution for capable devices. As such, you're looking at more images and greater data.
- The more the images, the more you make CPU, decoding and memory demands on the device. These stresses contribute to crashes.
- since you're not able to lazy load in email, and all assets load, you might be incurring data cost to user (and provider as well), and there are stats (on the web side) that show 50% of users don't go to bottom of page. Could be the same for email but i'm uncertain. Either way, they're potentially loading assets they're never going to look at.
- the network. Most ppl aren't on 4G.
6MB GIFs should not be outlawed, but this is way to huge even on Dectop i would think twice about it to put it in. If you happen to be using GIFs try to keep under 2MB. While we talking about GIFs, is there a better algorithm then the one from adobe? Cuz I would like zo have a better one like changing some pixels of my own
No one ever knows how big the GIFs are - but they're a lossless format. That's the issue. If you want to use an anim GIF, keep the sequence as short as possible, as well as small dimensions. I don't believe you're getting more engagement from a longer one. The GIF encoder is old and no real work is done to improve it really - as there's no immediate need to do so.
Image download size. I simply don’t understand how people can complain about bandwidth on mobile devices in email when images on websites are out of control in size. The responsive web is antithetical to nicely optimized images. Everything has to be 2-3 times the size it should be to look nice on mobile devices because of the higher screen resolution. So, do people just not browse the web on their phones because they are still afraid of bandwidth overages? Of course not.
They are both problems. We just happened to be talking about email here. And, tbh - if ppl knew what they were downloading, i'm more than certain they would think twice. I was just on a site looking for hours of operation, and this happened: https://twitter.com/HenriHelvetica/status/941331513588645889 This is not an uncommon case. The talk I gave @ Litmus Live BOSTON was ported from the one I usually give @ conferences on websites - where we can talk about lazy loading as a solution.
The point is the following: making the correct decisions. How you deal with the images is the key. A 6MB GIF should be outlawed. But they happen. Picking the correct format if key. A 100% image based email has it's benefits and drawbacks. Engagement is awesome on one side, but phone hardware is another. And BTW, it's not about bandwidth - it's latency mostly. Something you feel much more w/ image assets.
This is interesting. Everything online is moving towards https. and when it's not, you'll get warnings that the page is insecure. Another issue is sometimes mixed content (when you have both https and http requests on same page), but I'm not sure how that works w/ email clients. But there is legit concern about anything that's not https. I'm going to dig around.
Surprised this got bumped and showed up in a summary email, so I'll contribute.
Some great points were made in the thread - and I thought of #a11y 1st since that's an area that is often neglected, despite law. But I'll submit the idea of making sure you're as disciplined as possible when creating an email entirely via images. My argument will sit around a technical one (beyond rendering).
I spoke about some of this @ Litmus Live Boston 2017 and the idea of being careful around images and making the best choices possible around compressing and format. Even thought we're talking about 100% image emails in the thread, the avg email is apparently around 80% image base, which is not that far. So there really isn't that much wrong with having tons of images, it's knowing what you're up against - like clients, the network, data caps, and being a bit more disciplined.
I find that people with poor data on their phones and really old versions of Email clients aren't the ones you want clicking on your emails anyway. At least in tech.
to be frank, there are many in North America who have poor data plans let alone live in areas that do not support 4G broadly. Some were co workers of mine. Added, some have made a habit of using browsers like Opera (compresses images that much more) or turning off images because they quite often come in too big, and that's the dev's fault, not the user's.
Hey Jeffrey, wanted to kindly point out a few items:
for JPEGs , I would likely go from PS right to imageOptim. 1st PS for the sizing and whatever ever photo editing needs you might have. I would then save it w/ the edit and resolution you needed and at hi q. I would send it right to IO afterwards and pick the quality you need there (as you can set that). For one, IO uses better and more up to date encoders, I'm next to certain that IO employs both Guetzli and MozJPEG (BTW, unless you're encoding using Guetzli at a q90ish or greater, you're fine w/ MozJPEG + it's Guetzli is slow, something that even Google has acknowledged), and as you mentioned IO will take care of other things that PS will not - like sub sampling.
re: PNGs, by going from 24bit to 8bit, you are discarding a lot of colour information. As long as you know that you're going from 16M colours to 256. Since you did mention transparency, you're also going from 8bit transparency to 1bit - meaning you're going from gradient capable transparency (a true alpha channel) to what will be an alpha channel that's on or off - what you get from GIFs (89a).
And unless you're absolutely in need of an animated GIF, I would replace it w/ a PNG - you will almost always get better results from it. DO remember the PNG came about as a GIF replacement in the 1st place. In rare occasions will the GIF be smaller than a PNG.
Hope this might have offered some insight.
This is a technique that was discussed some time back, but you run into several challenges.
On a non technical level, the sad surprise will be when your user goes to save the image - which we know they do, and it will be saved at the very poor quality you provided, in it's large original size, something that might just send marketing and their branding dept in turmoil. On a more tech level, an issue that plagues mobile devices is the abundance of poorly sized images, and how they contribute to crashing devices (esp on android). Memory used will be w x h x 4 (rgba). So no matter what the container size, you're faced w/ massive memory usage. In your case: 2000px x 2000px x 4 = 16,000,000 bytes. Let's also add the fact that images need to be decoded, and the larger the image, the greater the decoding tax (time) - which is a strain on the processing.
Essentially, going with images that are excessively too big is a lose lose. In light, I would avoided this.