基准测试：浏览器内处理与上传式图片工具的对比

我们在同一批文件、同一台机器、同一条线路上，测量了 OptImg 与 iLoveIMG 的处理耗时。这里公开测量方法、数据，以及差距最小的那些情况。

测量日期: 2026-07-26

每个图片网站都说自己很快。但几乎没有谁会说明：测的是什么、用的什么文件、在什么线路下，以及自己的方案在哪里会吃亏。这个页面想做的正好相反。

我们把在浏览器内处理图片的 OptImg，与把文件上传到服务器处理再传回结果、使用广泛的 iLoveIMG 做了对比。两者由同一段脚本驱动，使用同一个浏览器、同一台机器和线路、同一批输入文件，在同一场测试中完成。

我们测量的是什么

我们报告的数值是任务耗时：从文件被交给页面的那一刻开始计时，到成品文件的最后一个字节写入磁盘时停止。它涵盖了人真正在等待的全部过程——对上传式服务来说包括上传、排队、处理和下载；对 OptImg 来说包括下载代码、解码、处理和本地保存。

从交付文件而不是从点击按钮开始计时，关系到公平。上传式服务在你选中文件的那一刻就开始传输，因此若从按钮开始计时，它们的上传时间就被悄悄从对比中抹掉了。

每个单元格取三次运行的中位数，且每次运行都使用缓存为空的全新浏览器。这是刻意把 OptImg 置于最不利的条件：它要在每一次被计时的运行中重新下载自己的处理代码，就和首次访问的人完全一样。

硬件	Apple M3 Pro, 18 GB RAM
操作系统	macOS 26.5.2
浏览器	Chromium 149.0.7827.55
线路	≈95 Mbps down / ≈129 Mbps up, 16 ms idle latency (home fibre, Seoul)
限速档位	9 Mbps down / 1.5 Mbps up / 60 ms round trip

任务耗时以秒计，越低越好。差异一列表示上传往返方式多花了多少倍时间。

任务	输入文件	OptImg	iLoveIMG	差异
压缩一张 5MB 照片	4.9 MB · 4000×3000	0.95 s	14.54 s	15.3×
把 2000 万像素 PNG 转成 WebP¹	47.8 MB · 5477×3651	2.58 s	29.12 s	11.3×
把 2000 万像素照片转成 AVIF²	2.8 MB · 5477×3651	6.02 s	不提供	—
把 2000 万像素照片缩到 50%	2.8 MB · 5477×3651	0.96 s	12.74 s	13.3×
导出 GIF 的 50 帧为图片	5.3 kB · 50 frames	1.47 s	8.80 s	6.0×

任务	输入文件	OptImg	iLoveIMG	差异
压缩一张 5MB 照片	4.9 MB · 4000×3000	0.93 s	38.55 s	41.5×
把 2000 万像素 PNG 转成 WebP¹	47.8 MB · 5477×3651	2.61 s	282.35 s	108.2×
把 2000 万像素照片转成 AVIF²	2.8 MB · 5477×3651	6.58 s	不提供	—
把 2000 万像素照片缩到 50%	2.8 MB · 5477×3651	1.01 s	25.95 s	25.7×
导出 GIF 的 50 帧为图片	5.3 kB · 50 frames	1.50 s	9.49 s	6.3×

WebP 这一行并非同类对比。iLoveIMG 完全不提供 WebP 输出，因此这一格用的是它最接近的功能：把同一个 PNG 交给它的 PNG 转 JPG 工具。引用此行时务必附上这一说明。
iLoveIMG 在任何地方都没有 AVIF 输出，因此该行按“不提供”记录，而不是记为一个领先倍数。

差距主要来自网络，而不是技巧。OptImg 之所以更快，是因为它从不把你的文件发往任何地方；线路快、文件小时这一优势就会缩小，而本次测试中差距最小的那一项正是这种情况。
OptImg 的耗时取决于你的电脑，因为计算发生在那里。下面的数字来自上面列出的机器。较旧的手机处理同一文件会更慢，更快的台式机则会更快。
iLoveIMG 的耗时取决于他们当时的服务器负载以及你与服务器的距离。在一个城市、一天之内测三次得到的是一张快照，而不是服务承诺。
两者的输出并不相同。双方都按各自的默认设置运行，因此文件大小和质量设置存在差异。这是一次关于时间的测量，各自生成了什么可以在原始数据的输出体积中查看。

测试图片不是人工挑选的，而是由固定公式生成，因此任何人都能重建逐字节一致的输入，而不必相信我们提供的文件。完整的测量方法、公平性规则和已知局限都与代码一并写入了文档。

下面的原始测量文件包含每一次单独运行：各阶段的时间标记、生成文件的大小，以及运行时所处的环境。