I’m not an expert at all when it comes to proxies and caching, what I would hope is that we could get it so that browsers would cache the image, but proxies wouldn’t. However at that point I’m not sure if there’s much use for a CDN, since the “CDN” would be the browser cache.
For PHP speed, I haven’t done much measurement of PHP throughput when just grabbing an existing file and sending its contents. I would expect some sort of performance hit compared to simply downloading a static image file because of the extra overhead of PHP in the request, but I don’t know how bad it would be. Some testing would have to be done. I also hadn’t thought of the increased latency on mobile networks, that probably makes it so we don’t want to redirect, if at all possible.
Another thought I just had is that it might be possible to make the .htaccess file/apache check for a cached image file and avoid firing up PHP altogether if a cached file exists. That would take some good .htaccess-fu, but it may be possible.
As for the philosophical question there are two ways of looking at it. One is that the content is the same, (a photo of me, or whatever), so so long as the URL of /photos/john.jpg always returns the same photo of me it doesn’t matter what happens behind the scenes. The flipside to that argument is that if the images are different sizes then they’re not the same image, so should have different URLs. The developer in me thinks the images are different, but the pragmatic approach says they’re the same. Really, I don’t think that a website visitor will care either way so long as he can see what he wants to quickly, without incurring a huge bandwidth bill.
John B
I’m not an expert at all when it comes to proxies and caching, what I would hope is that we could get it so that browsers would cache the image, but proxies wouldn’t. However at that point I’m not sure if there’s much use for a CDN, since the “CDN” would be the browser cache.
For PHP speed, I haven’t done much measurement of PHP throughput when just grabbing an existing file and sending its contents. I would expect some sort of performance hit compared to simply downloading a static image file because of the extra overhead of PHP in the request, but I don’t know how bad it would be. Some testing would have to be done. I also hadn’t thought of the increased latency on mobile networks, that probably makes it so we don’t want to redirect, if at all possible.
Another thought I just had is that it might be possible to make the .htaccess file/apache check for a cached image file and avoid firing up PHP altogether if a cached file exists. That would take some good .htaccess-fu, but it may be possible.
As for the philosophical question there are two ways of looking at it. One is that the content is the same, (a photo of me, or whatever), so so long as the URL of /photos/john.jpg always returns the same photo of me it doesn’t matter what happens behind the scenes. The flipside to that argument is that if the images are different sizes then they’re not the same image, so should have different URLs. The developer in me thinks the images are different, but the pragmatic approach says they’re the same. Really, I don’t think that a website visitor will care either way so long as he can see what he wants to quickly, without incurring a huge bandwidth bill.