为什么浏览器一年比一年吃内存

进程隔离把一切翻倍

自Spectre时代的加固之后，Chromium让每个站点运行在独立进程里，Firefox也跟进了按站点拆分的方案。十五个标签页加几个扩展，轻松凑出二十五个以上的进程——浏览器主进程、GPU进程、网络服务，外加每个站点一个渲染进程。站点隔离确实是出色的安全设计：被攻陷的渲染进程读不到其他站点的数据。但每个进程都要为渲染技术栈支付全价，2014年共享一个进程的那十五个标签页，如今要交十五次入场费。

扩展同样是进程。Manifest V3之后，它们以事件驱动的service worker形式存在，规则需要时才唤醒，同时向你打开的每个页面注入内容脚本。一打“小巧”的扩展，内存重量相当于好几个额外标签页，而一个行为不端的扩展能吃得比所有其他加起来还多。Chrome内置的任务管理器（Shift+Esc）能按标签页和扩展逐个列出开销、附上名字——在那儿花五分钟，胜过一切泛泛的建议。

平台只会越做越大

浏览器给所有人发的都是同一个二进制文件，里面装着现代Web能做的一切：WebGPU、WebAssembly、WebRTC、WebCodecs、service worker、可安装应用。砍掉功能几乎不可能——总有哪家银行或内网还依赖着2013年的API——所以引擎只进不出。每个版本还会在后台更新自己的组件：编解码器、网络栈、安全浏览列表；你昨天没重启的浏览器，已经悄悄给自己打了三次补丁。

网页本身也以同样的速度增重。如今的普通页面在内容可见之前就要加载好几兆的JavaScript，广告和分析脚本一路搭车，一个“轻量”新闻站点轻松加载上百个脚本。浏览器并不掩饰它扛的是谁的重量——打开内置任务管理器，把一个文档页面和一个购物网站放在一起比比。引擎确实变重了，但载荷膨胀得更快。

带JIT的完整JavaScript引擎——编译器的成本由每个进程承担，而不只是脚本密集的站点
GPU合成与编解码——每个渲染进程都背着图形管线的一份
service worker——站点在没有可见标签页的情况下让逻辑在后台运行
可安装的PWA——Web应用获得专属运行时，与一个小型浏览器无异
扩展——每个一个进程，外加注入你打开的每个页面的内容脚本

真正能降低开销的做法

诚实的第一步是标签页休眠，而且是内置的：Edge的睡眠标签页按你控制的计时器冻结后台标签，Chrome的内存节省程序卸载非活动标签、点击即恢复。两者都能回收真实内存，也都允许为需要常驻的网站固定例外。第二步是扩展审计：删掉认不出来的，禁用每周才用一次的，然后盯着任务管理器的数字看前后变化。

不管用的：追逐“轻量”浏览器。同样引擎上的任何浏览器，都背着同样的多进程架构和同样的平台重量——你是在用兼容性或安全更新，换一个可以忽略不计的零头。躺在废弃引擎上的老fork比臃肿更糟：它们是不再打补丁的攻击面。加内存才是真正贴合趋势线的朴素解法——浏览器就是Web的操作系统，没人用最低配置去跑操作系统。