1. Some CDNs, I understand, can cache resources based not only on URL but also on HTTP headers (afraid I don’t yet have a citation for this). So you could presumably specify that the CDN should cache different versions of the file depending on the “device-width” cookie.
2. If you have a URL like http://example.com/adaptiveImageRedirect/myImageName.jpg which then redirects to http://example.com/images/400/800/myImageName.jpg then you preserve the integrity of the URL for the image resources. The CDN can then cache the different redirect response headers as described above.
I was also very interested in @PETER LEJECK’s idea of serving the mobile images to start with and replacing it with JavaScript after the page has loaded based on screen size. Yes you end up loading the image twice, but the first time it’s only the mobile version which is quite small and at least the user will see a low-quality image immediately, so the extra time taken to download the larger image won’t break the user experience that badly, and it allows you to request image sizes much more specifically than adaptive images does – since adaptive images works based on the width of the view-port, not the width of the actual placement the image is to be displayed within. Plus this would be a completely client-side solution, which is simpler to implement.
I also really like @SRIPATHI KRISHNAN’s idea of using wurfl.sourceforge.net or a similar web service to tell you about devices by user-string. This would then be a completely server-side solution, to contrast nicely with @PETER’s.
Robin Winslow
Two issues mentioned above I was particularly interested in (originally raised by @SRIPATHI KRISHNAN):
1) Adaptive Images breaks CDNs
2) Adaptive Images breaks REST
Both of these can be solved, I believe:
1. Some CDNs, I understand, can cache resources based not only on URL but also on HTTP headers (afraid I don’t yet have a citation for this). So you could presumably specify that the CDN should cache different versions of the file depending on the “device-width” cookie.
2. If you have a URL like http://example.com/adaptiveImageRedirect/myImageName.jpg which then redirects to http://example.com/images/400/800/myImageName.jpg then you preserve the integrity of the URL for the image resources. The CDN can then cache the different redirect response headers as described above.
I was also very interested in @PETER LEJECK’s idea of serving the mobile images to start with and replacing it with JavaScript after the page has loaded based on screen size. Yes you end up loading the image twice, but the first time it’s only the mobile version which is quite small and at least the user will see a low-quality image immediately, so the extra time taken to download the larger image won’t break the user experience that badly, and it allows you to request image sizes much more specifically than adaptive images does – since adaptive images works based on the width of the view-port, not the width of the actual placement the image is to be displayed within. Plus this would be a completely client-side solution, which is simpler to implement.
I also really like @SRIPATHI KRISHNAN’s idea of using wurfl.sourceforge.net or a similar web service to tell you about devices by user-string. This would then be a completely server-side solution, to contrast nicely with @PETER’s.