如何扭转局面 - 在浏览器中处理大图像

节省了时间 - 在浏览器中处理大图像" />

客户上传了 28 张图像，每张大约 5800 x 9500 像素 和 28 MB 大小。当尝试在浏览器中显示这些图像时，整个选项卡冻结了 - 甚至拒绝关闭 - 长达 10 分钟。这是在配备 Ryzen 9 CPU 和 RTX 4080 GPU 的高端机器上进行的，而不是小型笔记本电脑。

情况如下

在我们的 CMS (Grace Web) 中，当管理员上传文件（无论是图片还是视频）时，我们会在上传完成后立即显示它。这对于用户体验来说非常好 - 它确认上传成功，他们上传了他们想要的内容，并且它显示了 UI 的响应能力以获得更好的感觉。

但是这些巨大的图像，浏览器几乎无法显示它们并冻结了。

需要注意的是，问题不在于上传本身，而在于显示这些大图像。同时一张一张地渲染 28 张巨大的图像实在是太多了。即使在空白页上，也只是...不。

为什么会发生这种情况（深入探讨）？

任何时候您在 中显示图片时在图像加载和布局重新计算期间，浏览器会经历一个使用 CPU、RAM、GPU（有时甚至是驱动器）的整个过程，有时甚至会在显示图片之前多次循环执行此过程。它经历了计算像素、在硬件之间传输数据、插值算法等。对于浏览器来说，这是一个重要的过程。

集思广益的解决方案

我们考虑了几种选择：

1. 上传后立即调整大小并显示缩略图
   • 问题：调整大小可能需要太长时间，并且不能保证立即完成，特别是在调整大小队列不为空的情况下 - 导致系统不响应。
2. 检查文件大小并仅显示大文件的名称
   • 问题：这会降低用户体验，特别是对于那些需要对任何媒体材料进行更好控制和检查的用户（顺便说一句，这些材料通常是具有大文件的相同材料）。

这些解决方案都感觉不可用。我们不想限制管理员上传所需内容的能力，也不想在用户体验上做出妥协。

灯泡！使用

我记得 element 更有效地利用 GPU 来渲染内容。我最近看到有人使用 JavaScript 和 构建安静的复杂游戏，因此理论上它应该比 更有效地处理大图像。

测试理论

我们决定替换 带有 的元素用于显示上传的图像。这是我们使用的代码片段：

const canvas = document.createElement('canvas');
const ctx = canvas.getContext('2d');

const img = new Image();
// img.src = URL.createObjectURL(file); // Use this if you're working with uploaded files
img.src = filesroot + data.file_path; // Our existing file path
img.onload = function() {
  // Resize canvas to desired size (for preview)
  canvas.width = 80 * (img.width / img.height); // Adjust scaling as needed
  canvas.height = 80;
  // Draw the image onto the canvas, resizing it in the process
  ctx.drawImage(img, 0, 0, canvas.width, canvas.height);

  file_div.innerHTML = ''; // Prepared <div> in UI to display the thumbnail
  file_div.appendChild(canvas);
};

结果

改善是立竿见影的！浏览器不仅可以毫无问题地处理 28 张大图像，而且我们还通过加载120 MB 图像测量28,000 x 17,000 像素进一步推动它，并且它仍然可以正常工作是一个小图标。

差异在哪里？

使用元素，绘图完全掌握在 GPU 手中，而这些芯片实际上就是为此任务而制造的。

• ;仍尝试渲染 28,000 * 17,000 = 476,000,000 像素。
• 这个<画布>仅绘制 80 * 80 = 6,400 像素。

通过调整 中的图像大小到较小的预览尺寸，我们大大减少了浏览器需要处理的数据量 - 将数亿像素发送到 GPU 并返回数千个像素，这很大，对吧？

下一步

鉴于这一成功，我们现在正在考虑替换 与 在我们应用程序的其他部分，特别是在一次显示大约 250 张图像的管理屏幕中。虽然这些图像已经正确调整了大小，但我们很好奇是否使用 可以提供更好的性能。

我们将进行测试和基准测试来衡量任何性能提升。我一定会在以后的文章中分享我们的发现。

重要警告

使用时为我们的特定用例创造了奇迹，我必须注意，您不应该使用 ;用于在网站面向公众的部分显示图像。原因如下：

• 辅助功能：;屏幕阅读器可以读取元素，为视障用户提供帮助。
• SEO：搜索引擎索引来自 的图像标签，可以提高网站的可见性。 （同样，人工智能训练抓取工具也会对图像进行“索引”。好吧，你能做什么......）
• ;与;可用于自动检测像素密度并显示更大或更小的图片以实现完美契合 - 不能。我写了一篇关于如何构建您的 .

对于公共网站，最好在将图像提供给用户之前在服务器端正确调整图像大小。如果您对如何自动调整图像大小和优化感兴趣，我写了一篇关于该主题的文章，您可能会觉得有用。

结论

我喜欢优化！尽管我们每天都在向本地高性能硬件迈进，但通过优化 - 即使“它很好，但还可以更好” - 我们可以防止出现此类问题开始。

这种方法不是标准的。而且我不太关心标准。它们通常被视为硬性规则，但它们只是指导方针。这个解决方案很合适。我们没有客户拥有没有坚实的<画布>的古老设备。支持。所以，即使现在我们有更多的代码需要管理，有多种显示图片的方式，但它非常适合，这才是重要的！

你有类似的经历吗？你是怎么处理的？欢迎在下面的评论中分享您的经验或提出问题！

以上是 如何扭转局面 - 在浏览器中处理大图像的详细内容。更多信息请关注PHP中文网其他相关文章！