我正在构建一个图片库，在首页呈现一些图像。图片比首页显示的实际尺寸大，这让我产生了以下问题:
如果没有缓存选项，那该怎么做:
-
使用php收缩图像并将其发送到客户端
-
发送原始的全尺寸图像，并让客户端缩小它(简单的
width和height属性)
我倾向于认为第二种是更好的解决方案，但我想听听更多的意见。
谢谢!
编辑:当人们上传图片时，我会创建缩略图，以便在浏览网站时显示。
"cache is not a option"的原因:
所讨论的图像是首页中的5个"特色"图像，这些图像最多不会保持相同超过一个小时。因此，为每个上传的图像创建另一个图像副本不是很浪费吗?
基本上，这取决于
- 原始与期望的宽度/高度比是多少?提供500x500的图像并将其显示为250x250并不是什么大问题，但是在1920x1080的图像上浪费带宽就很严重了。此外，如果你提供太多的大图片，移动设备可能没有足够的资源来实际显示网页。
- 你有更多的什么:带宽还是CPU能力?你能确保没有人使用你的动态调整器作为DOS目标吗?
一般来说，使用缓存的解决方案，即使是非常临时的，也要好得多。
(广告编辑)所讨论的图像是首页的5个"特色"图像最多一小时内不会保持不变。所以这不是一种浪费吗为每个上传的图像创建另一个图像副本?
。但你可以简单地为这些缩略图创建一个单独的文件夹，并设置一个cron作业来擦除超过一小时的文件。下面是我在我的网站上使用的一个例子(设置为30分钟):
*/15 * * * * find /var/www/directory/ -mmin +30 -exec rm -f {} '; >/dev/null 2>&1
考虑到'足够'的CPU资源，我宁愿在发送图像之前缩小图像，以方便连接不良和移动设备的人。
另一个选项和我喜欢的策略是保留较小的图像版本，然后使用它们。如果图片是在某个时刻上传的，那么在上传时创建一个较小的图片版本。
这取决于你的流程，但我会即时调整它们的大小并节省拇指。所以，如果拇指存在，就上菜，如果没有，就调整大小，然后上菜(同时保存拇指)。
3。不要在为客户端提供图片的过程中调整图片的大小——让一个后台进程来调整图片的大小，如果调整了就发送缩略图，如果还没有发送完整的图片。这样做的好处是，您可以独立于用户请求限制调整大小的过程。