This isn’t an architecture I would recommend for any website.
1. Using PHP to serve images is much slower than letting Apache do it for you. Its also far less reliable.
2. It completely breaks the CDN. I’d rather the user downloads a bigger image from the CDN, than a smaller, non-cacheable image from the origin.
3. It breaks REST principles. You want the URI to uniquely identify the image. With this approach, the cookie + uri determines the image.
I am afraid this is striving for Fluid design at the cost of performance and system architecture.
A better solution is perhaps to redirect the user to a domain such as m.example.com for mobiles or t.example.com for tablets. Then use PHP to check the domain (instead of the cookie) and serve resized images.
The advantages are several – CDN and cache friendliness, REST urls, and an easy path to serve different markup in the future if required.
Sripathi Krishnan
This isn’t an architecture I would recommend for any website.
1. Using PHP to serve images is much slower than letting Apache do it for you. Its also far less reliable.
2. It completely breaks the CDN. I’d rather the user downloads a bigger image from the CDN, than a smaller, non-cacheable image from the origin.
3. It breaks REST principles. You want the URI to uniquely identify the image. With this approach, the cookie + uri determines the image.
I am afraid this is striving for Fluid design at the cost of performance and system architecture.
A better solution is perhaps to redirect the user to a domain such as m.example.com for mobiles or t.example.com for tablets. Then use PHP to check the domain (instead of the cookie) and serve resized images.
The advantages are several – CDN and cache friendliness, REST urls, and an easy path to serve different markup in the future if required.