Having related emails batched and then providing easy ways to pin, snooze or mark done is so useful. Clicking the "sweep" button (Mark All As Read) after prioritizing the email you care about is such a satisfying feeling. I'm not quite at inbox zero yet, but definitely feel like it is now actually possible with a bit more work on my end.
Hi everyone, Chris, the founder of imgix here. We are just beginning to talk about what we are going to be rolling out over the next few months, so I wrote this piece about how and why we are moving in the directions we are moving, with a focus on explaining things from the developer perspective. There will be plenty more to follow so stay tuned. For the moment, I am happy to fill in any details that I can.
Keynote is actually a surprisingly good tool for building diagrams once you learn the interface and features. I use it for all of our architecture diagrams and for generating printable posters of such to hang in our office. I have tried nearly everything else, but unless you need semantics native to your diagram, Keynote is (oddly, I know) the best I have found.
You should check out the Whitebox Software Defined Radio Project. It is a hacker friendly software defined radio started by my friend Chris, a former lead engineer from Google/YouTube and the former VP of technology at Adly. http://radio.testa.co
We would be happy to help at imgix. We currently process tens of millions of images per day, including large images like yours. Feel free to contact me at chris (at) imgix (dot) com. Link: http://www.imgix.com
We used the existing image requests as a baseline. So the numbers we are reporting are specifically for the images that are being served in established formats (e.g. PNG and JPEG) measured against their equivalent requested WebP and JPEG XR variants. We then measured the percentiles of savings for these images. 98% of images in our test customer base saw a 18-74% improvement in compression per image, with an average of 41% savings per image. The data itself is a deduplicated set of hundreds of millions of image requests across several test customers. The one piece of data we should also report is the aggregate total savings per customer across all of their image requests. I will look into calculating that data point.
We deliver images out of a CDN where we already have handled the proper request normalization. There is no support cost to implementing content negotiation in this case unless you want to put us behind a proxy. At that point, we can work with you to vary correctly without incurring the complexity you are focusing on.
Founder of imgix here. The comparison image is just meant to be moderately informative. We will be following up with a detailed performance outline as more data comes in. You can compare the progressive JPEG image against the WebP or JPEG XR to get a sample of what the ratios might be for a standard JPEG. Besides, a surprising number of websites still serve wildly uncompressed and unoptimized imagery. We help websites that are serving uncompressed JPEG and PNGs all of the time.
Furthermore, what should be understood (and I will clarify in the post) is that apart from the example image, which is designed to show the comparative compression ratios of the file formats, the data we report is based on the images that these companies are ALREADY serving. We analyzed our logs for what the image size is that they are currently serving as JPEGs and PNGS at the same size and simply enabled content negotiation for those same sized images.
With regards to the Vary header. You are right that the cache fragmentation of varying by Accept or User Agent would be extreme. This is why we do not do this. Instead, we perform normalization on the request and generate a specific "content ID" that takes into account any number of input signals that should be normalized and varied on. We can expose this as a separate header to folks who want to Vary on if folks want it. Finally, if you are serving directly out of us, none of this really matters. There is no web server involved. We handle all of the hard work on our end.
I disagree that content negotiation is the wrong approach though. The fragmentation we see across all of the input signals (e.g. format support, device pixel ratio, user agent, etc) is already so extreme that the best answer is to serve dynamic responses for images. If you want to stay within in the browser prefetch stage, which is critical for front-end performance, you have to make decisions about the content you want to serve at the server. This means potentially serving variant content under a single URL. We serve targeted responses for text content all the time across the web. It is not clear from your argument as to why this same treatment should not apply to imagery.
Having OS X in our stack allows us to tackle a lot of use cases that come out of the prototypical design process. Format support, color profiles, color space conversion, typography, etc. are all mastered in OS X, but lacking in other operating systems. Apple has had the best imaging scientists in the world working for the last 30 years on getting these features right. We want to be able to leverage that expertise, whenever it makes sense, to produce the highest quality image. In this case, the consequence of that decision means racking Macs.
Agreed. They should definitely lock it down for their internal use (and eventually provide a public API). I would imagine that in a young company that is moving fast, there is a high potential to overreact or to appear to because of canned responses.
I highly doubt this has anything to do with stifling innovation. Given Snapchat's popularity, it would make a lot more sense that they are trying to restrict 3rd party access to cut down on spam. Nothing will be more destructive to their service than bots churning out huge amounts of spam, undermining the trust they have built with their users.
Snapchat was likely trying to value itself in comparative terms to Instagram. Instagram was a threat because it had both the meteorically rising product AND the engineering team capable of scaling ahead of that growth. I think Facebook created Poke not to compete directly, but as a response to the comparison to Instagram. Facebook "coded Snapchat in a weekend", literally.
We cache aggressively, at multiple levels, and manage the dependencies between caches. In the overwhelming amount of cases, we are serving straight out of SSD caches. The on-the-fly work only happens if the image does not already exist.
You are not wrong. And we were very well aware of this. However, we found the reality of the problem being solved is much more about network latency, routing, and caching than actual graphics processing throughput. Our pain points have been very different than what you are prescribing as a better course of action.
They do a fair enough job for what we needed. Really, it was more about what we could get quickly, with a certain expectation of consistency, just to get us moving forward.
Actually, to be fair, I did not mean to imply that anyone was "bragging". People may have been celebratory, and justifiably so, but I never felt anyone in particular was bragging.
I really like only using AJAX for content that is conditional. For instance, a comment form that opens up only when a user clicks on it. If they never go to add a comment, the AJAX request is never made. Anything that is actually going to be displayed immediately on the page should be loaded as soon as possible as there are major performance gains in letting the preprocessors do their work properly.
I'll rework the wording. Also, it wasn't that the videos were necessarily taking 20 minutes to load. That was simply projections based on the numbers we were seeing at the time. There was not enough data of people actually waiting for 20 minutes to watch something, at least in the small subset of data we pulled at the time.