> Nobody is "shipping" anything on the web. I've never understood the use of the word, even for apps. Something that is shipped cannot be touched or modified after release. This isn't the case on the internet.
At minimum, expect one week of review time before you can release an app on the App Store.
As far as web apps, every line of code that makes it to production has consequences. If you make a catastrophic mistake, like leaking user data, how long does it take to 1) discover the mistake, and 2) deploy an update? If you're dealing with thousands of servers and multiple data centers, it can take an eternity.
> Making the image slightly more hi-res, say 1.5x, and then compressing it more aggressively has the benefit of satisfactory sharpness and quality on high density displays, while compressing to a size similar to the low res. I've confirmed this and use this technique, as others have.
Did you perform user research? Are you a designer? Or does "confirm" mean, "my opinion"?
> For the normal operation of a website, needing to make only one image per product item is obviously more economical for whoever is making the content,
Whoever is making the content should have this automated. If they can't, your job as an engineer is to automate it.
> not to mention the technical hassle faced depending on your CMS and how it handles image assets.
1. Are you writing this from 1992? What modern software can't handle images at 1600 resolution?
2. Your CMS shouldn't have any load. Your assets should be delivered by CDN.
> iPhone 6 has 3x res? So what?
Users feel something is off, whether or not they'll articulate it. All these little things, together, make your website look amateur.
Do they? Because an image is 1.5x and not 2x on their phone? Mate, that's nonsense.
Just do a comparison yourself and you'll see. I did, checked and confirmed with the client (jewellery designer where the image quality was important) and they were happy. On my iPad3 the 1.5 product images (at 1200 pixels wide presented half width of screen) were MORE than adequate and very sharp on the iPad. No "blurriness" at all. There is no way in the world you'd be able to tell the images were not 2x when the screen is viewed at normal distance.
> "Are you writing this from 1992?"
I'm writing this from the real world. In your utopia it seems everyone has unlimited bandwidth on their mobiles to download 1600px images for every product listed, and can see the difference with their bionic vision. I prefer to keep site weight down and enjoy the increased performance as a result.
Disagreeing is fine, but your argument amounts to "the site will look amateur hmmkay", and I'm telling you now that the "amateur look" comes from poor UX or clunky design and performance, not whether an image is 1.5x vs 2x.
Using a CDN for assets is good, but not always an option/need for a small business website with minimal traffic (such as a jewellery designer's e-store) and keeps the dev costs and complexity down if everything can be handled on the one platform. But I don't disagree with you about using a CDN, it's just that a CDN doesn't suddenly make the frontend more responsive or snappy. Those images still need loading in the browser no matter where they come from.
I convince my clients to spend a little bit more on their web host account, to get a bit more CPU performance and memory so that uploading images and so on runs smoothly. Works for me, works for them. Whether it works for anyone else is not my problem! I'm just sharing my approach. Ignore or disagree, it's all good.
Good luck. Remember to do things because they work in practice, not because Apple or Google or some random person on HN said to do it that way.
At minimum, expect one week of review time before you can release an app on the App Store.
As far as web apps, every line of code that makes it to production has consequences. If you make a catastrophic mistake, like leaking user data, how long does it take to 1) discover the mistake, and 2) deploy an update? If you're dealing with thousands of servers and multiple data centers, it can take an eternity.
> Making the image slightly more hi-res, say 1.5x, and then compressing it more aggressively has the benefit of satisfactory sharpness and quality on high density displays, while compressing to a size similar to the low res. I've confirmed this and use this technique, as others have.
Did you perform user research? Are you a designer? Or does "confirm" mean, "my opinion"?
> For the normal operation of a website, needing to make only one image per product item is obviously more economical for whoever is making the content,
Whoever is making the content should have this automated. If they can't, your job as an engineer is to automate it.
> not to mention the technical hassle faced depending on your CMS and how it handles image assets.
1. Are you writing this from 1992? What modern software can't handle images at 1600 resolution? 2. Your CMS shouldn't have any load. Your assets should be delivered by CDN.
> iPhone 6 has 3x res? So what?
Users feel something is off, whether or not they'll articulate it. All these little things, together, make your website look amateur.