The iPhone 6 and the iPhone 6+ hit the device market like a freight train. The dynamic duo shipped 10 million units in the first weekend alone, breaking all device release records. Some analysts expect 60-70 million iPhone 6 and 6+ unit to ship in the first year after its release. Lots of people have written about how these two new phones are forcing web publishers to up their game in preparation for these richer displays. What they may not have realized is that the iPhone 6 and iPhone 6+ also presents a challenging problem for content delivery networks.
Over the past few months, multiple content owners have told me how the iPhone 6 and 6+ have made it harder for some CDNs to deliver their content to these devices, with good quality. Apple’s new phones challenge CDNs with a perfect storm of significantly larger images and a non-negotiable requirement to deliver images generated on the fly even over wireless phone networks. This is a territory where CDNs have historically struggled even with the lighter requirements of earlier generation smart phones with smaller displays.
The new iPhones are the final nail in the coffin for old-style m.dot websites and a forcing factor for the shift to Responsive Web Design (1, 2) sites. With the arrival of these two devices, websites must support nearly a dozen Apple device screen sizes. Add this to the assortment of popular Android display sizes and image management becomes a massive headache. On m.dot sites, this creates significant pain because that means each of the image sizes must be cached on the edge of the network for a CDN to deliver it properly.
There are software solutions to automatically generate and manage multiple image sizes as soon as a user hits a website, but those solutions mean that the customers IT organization is incurring significant technical overhead and creating a single point of failure for delivery. This may not have been as big a deal a few years ago when sites did not change their larger images often, but today, most travel, ecommerce and media sites update images as often as several times per day.
Application delivery provider Instart Logic gave me an example of such a customer, Commune Hotels, a hip hotel chain that owns brands like Joie De Vivre and Thomson, who is actually baking high definition user photos from Instagram in, updating them constantly. This type of behavior means flushing a cache in a CDN in a timely fashion can become a logistical nightmare all by itself. As a result, almost every web performance engineer and senior executive overseeing website performance that I am speaking with is in some stage of transition to a Responsive Web Design site. This, too, presents big problems, namely for the CDNs. Responsive Web Design sites rely on scalar image resizing on the edge of the network. That means images in a site code are expressed as ratios rather than sizes.
With Responsive Web Design, images must be generated on-the-fly to fit the specific device type and display size as called for by any user. Responsive Web Design also forces a site owner to generate multiple images in anticipation of user behaviors, like resizing browser windows, zooming in on multi-touch, etc. Some CDNs are wholly reliant on cached images and start to show significant performance degradation when they are forced to rely on images generated on the fly.
A critical compounding factor is the higher pixel ratio required in the iPhone 6 and iPhone 6+. These devices go further than any previous Apple mobile product with a pixel ratio of 3. This means that website publishers will need to push images to devices that are actually three-times as large as the display size. This is in anticipation of user behavior on multi-touch devices, zoom, pinch, moving in and out. The behavior is common on smartphones and is a critical part of the user experience for digital experience delivery on image-rich sites in ecommerce, travel and media. (See Akamai’s video on the subject)
This means that not only will CDNs need to handle on-the-fly image resizing but they will also have to quickly push out to their caches images that are considerably larger than ever before. And then the CDNs are at the mercy of the “last mile” of the cell phone networks where network performance is highly variable depending on location, time-of-day, micro-geography, user density, and network connection type (LTE, etc). What’s more, web publishers pushing out these larger images via CDNs can experience signficantly higher bandwidth costs. Over 60% of website payloads are already images, the additional bump could add mightily to what large sites or image-heavy sites are paying each month to use CDNs.
By extension, methods to maintain image quality or serve larger images with less bandwidth could have a tremendous impact. Instart Logic, for example, has some new and intriguing ways to categorize the content of images and then optimize the first paint of an image to maintain quality but slash data required to display. The algorithm can, for example, figure out whether a photo is of a face or a of a beach. If it’s of a beach, then far less data is required to paint an image without noticeable quality loss. This can save 30% to 70% on initial paints. These types of software-defined solutions that rely on smarter ways to pass data over the last mile will trump the old brute force methods of CDNs, PoPs and fiber to the near-edge (because the edge now, is always the cell tower).
Another untapped area that will become important is tapping the power of browser caches on the devices. Newer devices and new HTML5 browsers have multiple caches. Some are higher performance than others, by design. So savvy web performance solution providers will need to tap into those browser caches and route the content that is likely to be persistent on a site – header images, for example – and push it into the browser for fast recall. This will allow pages to appear to load much faster even if the site is waiting for other components to load.
Ultimately, CDNs will either need to figure out a way to deal with delivering much bigger images efficiently over the last mile or they will struggle with serious performance issues on the iPhone 6 and iPhone 6+ and other new devices coming to market. Their alternative will be deploying more capacity on the edge of the network, which is by and large not a cost-effective strategy.
I’d love to hear from other content owners in the comments section below on how they are handing the delivery of content to the iPhone 6 and 6+.
Image credit: myclever