关于如何获得闪电般快速的媒体+防止热链接和<img src="data:image-kj134332k4" />的理论正在浮现。scraper不需要我们的src，真正的客户端需要即时加载(尤其是蜂窝网络)。考虑到最近谷歌的https无处不在的举动，这也将大大减少握手。
-
制作诸如ecom之类的列表有什么缺点类别/小部件/幻灯片使用数据:图像?
-
在服务更大的总页面大小时，实际源代码的额外KB是否有任何影响?
-
你会喜欢任何PHP data:image gen脚本，而不是另一个解析图像作为数据在某些控制器级别的数据(在其他区域留下标准src图像)?
-
是否存在缓存/CDN问题?解析是否可以缓存?似乎不是，但我不是缓存专家。
任何指导或案例的想法是非常感谢。谢谢你！
总的来说，这个想法是值得考虑的，但在大多数情况下，问题大于好处。
这是真的，这些图像将不再被缓存在客户端。特别是基于Expires的缓存可以节省大量带宽。
作为一个经验法则，我想说:如果这些是经常变化的小图像，嵌入是一个好主意。如果图片比较大，并且客户端在后续的请求中多次加载相同的图片，那么无论如何都要分别发送图片，并在缓存上投入一些精力。
至于其他几点:
-
大多数浏览器支持;然而，一些旧的ie不能……所以考虑一个后备解决方案或准备好收到bug报告(可能是可以忽略的，取决于你的用户群)
-
如果您使用的是标准的HTTP keep-alive，那么SSL握手的次数可以忽略不计。后续请求确实需要重新握手，但如果您正确缓存(参见下一点)，并且可能将静态文件放在CDN上，这是没有问题的。
-
阅读缓存，特别是
Expires/Cache-Control头和他们的朋友。 -
如果你决定嵌入，你真的不需要一个生成器脚本，嵌入的图像是base64编码的图像文件;这不会超过3行代码。
-
但是，如果您在PHP中处理/转换图像，则有另一个缺点:而不是静态地提供它们(甚至可能来自不同的机器或CDN)，图像必须在同一台机器上并通过PHP引擎，从而增加了每个进程使用这些图像的页面的内存。