我的网站正在使用php函数来调整图像大小，因此浏览器不必这样做：
function resizeImg($img, $newW, $newH, $rotateTrue) {
//image resize code, then
return base64_encode($image_data);
}
其中函数的调用方式如下：
<img src="data:image/png;base64,<?= resizeImg('myImg', newWidth, newHeight, 1); ?>" alt="pic">
没问题。但是，返回的图像数据很大。当我检查 Chrome 中的元素时，每个调整大小的图像返回> 1kB 的编码数据。
这对于这里和那里的分散图像很好，但是如果你有一张大桌子怎么办？例如，我网站上的一个表> 1500 行，每行一个图像。每个图像目前都由浏览器调整大小，我知道这并不理想。但是，如果我使用服务器端调整大小函数调整这 1500 张图像中的每一个的大小，我将添加大致以下数量的编码数据：
1500 images x ~1.1 kB encoding data per image = 1650 kB
到此表。
对于高性能站点，我应该更重视带宽节省（即调整客户端大小）还是浏览器节省（即调整服务器端大小）？
tl;dr BOTH
您的方法的主要问题是，由于您正在动态生成新图像，因此您可以通过增加页面请求对服务器的计算影响来应对非常容易的DDoS攻击。不用说，由于这个问题，您发布的代码和术语高性能不能很好地结合在一起。
另一个问题是客户端无法缓存您发送给它们的图像（除非您缓存您交付的完整网页），因为它们是通过 base64 内联的。
解决方案很简单。将图像大小调整为一组预定义的大小，并将其存储在服务器上。将这些各种尺寸交付给客户，让客户完成其余的工作。当然，您必须正确配置服务器以缓存这些图像文件。
您可以在客户端使用新的 <picture> 元素（旧浏览器的图片填充）来支持具有不同分辨率的多个设备。当然会发生一些缩放，但您无法绝对为每个设备生成图像。
如果您的问题只是关于升级，那就根本不做。不在服务器上，也不在客户端。放大的图像看起来很丑陋。
我更喜欢保存调整大小的文件并仅使用它们的 URL。您当前的解决方案绝对没有缓存，然后 u 使用 HTML 中的 base64 编码使图像大小更大。
仅当您同时显示原始图像并且它们不大时，在客户端调整其大小才是现实的。