北京
一份45页、88MB的高分辨率设计作品集丢进浏览器，标签页直接冻结了12秒。这就是TinyPDF第一版遇到的真实场景——一个立志“只跑浏览器、不上传任何文件、零服务器成本”的PDF压缩工具，在真家伙面前几乎无法使用。
它的规则很硬：没有后端，一切计算都在本地浏览器完成。用户拖拽文件、压缩、下载，全程离线。但第一次实测时，光是解析这份88MB的PDF就让界面完全卡死，更别提压缩到2MB以内了。从12秒到2秒，中间隔着三个关键改动，而每一个都直接打在浏览器的性能软肋上。
第一步：把PDF解析扔给Web Worker，把主线程还给UI
最初的错误做法是把PDF.js的解析直接挂在主线程上：const pdf = await pdfjsLib.getDocument(arrayBuffer).promise;这行代码会在主线程里同步等待整个文件的解析完成，期间用户没法点击、没法滚动，浏览器像死机一样。
解决方法是将所有繁重计算移交给Web Worker。主线程只负责接收进度更新和发送指令，Worker线程专门处理文档解析和图片压缩。新的通信模型变成：Worker接收原始字节流，开始逐页处理，每完成一页就向主线程汇报进度，全部完成后回传压缩好的Blob。这样一来，即便面对100MB的大文件，主线程都能保持响应，用户随时可以看到进度条在跑。
迁移到Worker后，标签冻结现象消失，UI流畅度有质的提升——100MB的PDF在后台安静解析，主界面再也不会卡住。
第二步：流式处理图片，不让45页同时“住”进内存
第二个性能杀手是内存。旧版本会把所有页面一次性加载到内存中：先获取全部页面对象，再把每一页渲染成高分辨率画布，最后才开始压缩。对于一个45页的文档，内存里同时躺着45张全尺寸位图，再加上PDF源码的解析数据，内存曲线直接飙升。
新策略改为“处理完一页，释放一页”。代码逻辑变成：循环页码，每一轮只加载当前页，获取视口，创建画布并渲染；渲染完成后立即调用page.cleanup()释放该页的解析资源，同时把画布宽高置零，强制浏览器回收显存。压缩后的图片直接追加到输出Blob，而不在内存中积压。进度条也同步更新。
这个流式管道让内存占用在整个处理过程中保持平坦。不管是20页还是100页的文档，内存峰值都限制在单页渲染所需的量级，再也不会因为一次性加载全部页面而把浏览器逼到OOM的边缘。
第三步：二分搜索目标质量，让“压到指定MB”不再需要反复试错
TinyPDF的核心卖点是“压缩到精确的目标文件大小（MB）”。最初的实现非常粗暴：从100%图片质量开始，每次降低10%，压缩完整个文档再检查大小，不达标就再降10%。运气不好的时候，可能要重复处理5到10次，整个压缩流程耗时成倍增长。
改进方案是用二分搜索锁定最优质量。在0.1到1.0的区间内，每次取中值作为候选质量，复用流式管线快速估算出该质量下的最终文件大小，然后根据与目标大小的对比，收缩搜索区间。由于整个过程只做估算而不真正生成完整Blob，每一轮的成本极低。通常不到5次迭代就能找到刚好满足目标大小上限的最高质量值，然后带着这个精确的参数完成最后一次真正压缩。
这就把一个可能多次扫描全文档的O(N)过程，压缩成了O(log N)的轻量搜索。对于想精确控制输出大小的用户，整个流程始终保持在一个可控的2秒左右，而且质量损失被控制在最小范围。
三招齐下，浏览器里的PDF工具也可以快得不像话
把Web Worker、流式处理、二分搜索这三项优化叠加后，TinyPDF处理88MB、45页高清PDF的总耗时从12秒降到2秒，内存占用稳住，压缩质量可预期。而且这些改进完全在浏览器沙箱内完成，不需要任何后端支撑，意味着零上传、零隐私风险、零服务器开销。
这个案例也提供了一个清晰的浏览器性能优化路线：第一，永远不要把长计算挡在主线程上；第二，流式处理是避免内存爆炸的通用解；第三，算法上的智能消减往往比盲目加硬件更有效。当这三个原则同时生效时，一款纯前端的PDF工具也能给出接近原生桌面软件的响应体验。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
