上个月帮朋友清理一台旧笔记本顺手把默认浏览器换成了Brave。朋友瞥了一眼丢下一句“这不就是换皮Chrome吗有什么好装的。”我没急着反驳只是让他先用一周。一周后他主动说确实感觉网页开得比之前快。我笑了一下没说的是为了弄清这个“确实快”到底有多少是真本事、有多少是前提条件我上周又把五款浏览器拉到同一台机器上专门跑了一轮横评。结论先放这儿Brave依然是我测过的浏览器里页面加载速度最快的那一个但这个结论有一个相当关键的前提。这篇文章会把整个测试过程、数据结果以及那个被我反复验证的“前提”完整拆开讲清楚。不想看过程只想抄作业的话可以直接跳到第4节里面有完整的性能调校清单。想搞明白为什么同一个内核、同一台电脑浏览器之间能拉出10%到20%的加载差异建议从头看起。1. 重新跑一轮横评我为什么又拿Brave来测速1.1 起因那个“换皮Chrome”的质疑确实值得认真回应Brave基于Chromium内核这一点不用回避也回避不了。很多人由此得出一个结论既然是同一个内核渲染能力一样那性能和Chrome就没什么区别所谓“更快”不过是广告拦截插件带来的心理作用。这个质疑不是完全没道理但它把“浏览器性能”理解得太窄了。浏览器从输入URL到页面可交互中间经过DNS解析、TCP连接、TLS握手、请求排队、资源下载、HTML解析、CSS计算、JavaScript执行、布局绘制等多个环节。Chromium内核相同意味着后面的渲染、布局、脚本引擎起点一致但前面的网络请求管理、资源拦截策略、缓存策略、进程调度完全可以做到天差地别。我这次重新跑横评就是想把这些环节拆开看Brave到底是在哪个环节领先的领先多少以及什么条件下这种领先会消失。1.2 被测环境把变量压到最低数据才不算白测先交代测试环境这部分很枯燥但没有它所有数据都失去意义。硬件台式机Intel i5-1240016GB DDR4内存NVMe固态硬盘系统Windows 11 23H2关闭了系统级游戏模式以外的后台优化网络同一局域网有线连接500M光纤宽带浏览器版本Brave 1.68稳定版、Chrome 126、Edge 126、Firefox 127全部更新到测试当天的最新稳定版被测站点选了五类尽量覆盖不同的页面结构和广告密度一个新闻门户首页广告和追踪脚本重灾区、一篇带评论区和技术脚本的技术博客文章页、一个大型电商首页、一个开发框架文档页、一个后台仪表盘模板页。测试方法上我要求自己做到所有浏览器都用全新用户配置目录启动不登录任何账号关闭扩展Chrome这边单独保留一个装了6个常用扩展的场景作对比这个后面会细说每次都全新打开无痕窗口清掉系统和浏览器缓存每个站点连续测5次去掉最高最低取中间3次的中位数每测完一个站点就换浏览器顺序防止某一段时间网络波动集中影响某个浏览器。1.3 记录指标的思路别只看“感觉”要看数据里藏着哪个环节记录的数据不是简单掐个秒表。我在每个页面用DevTools里的Performance面板和PerformanceNavigationTiming API取了几个关键指标DNS解析耗时、TCP连接耗时、TTFB首字节时间、DOMContentLoaded、Load事件总耗时另外用Brave Shields的统计面板记被拦截请求数量。这段JavaScript可以直接在浏览器控制台里跑const nav performance.getEntriesByType(navigation)[0]; const stage (name, start, end) { const duration nav[end] - nav[start]; console.log(${name}: ${duration.toFixed(1)}ms); }; stage(DNS查询, domainLookupStart, domainLookupEnd); stage(TCP连接, connectStart, connectEnd); stage(TLS握手, requestStart, secureConnectionStart); stage(TTFB, requestStart, responseStart); stage(HTML下载, responseStart, responseEnd); stage(DOMContentLoaded, startTime, domContentLoadedEventEnd); stage(Load完成, startTime, loadEventEnd);指标别贪多盯着TTFB、DOMContentLoaded、Load这三个就够了。TTFB反映网络请求的排队和服务器响应DOMContentLoaded反映渲染主进程空闲前的工作量Load反映整个页面包括异步资源完成的最终时间。这三个指标合在一起基本能定位浏览器之间的性能差异到底出在哪一层。2. 实测结果Brave快了多少快在哪个环节2.1 数据总表优化配置下的加载耗时对比先看最直观的一组数据。这里Brave一列是我按第4节的清单调校之后的配置Brave默认一列是安装完不动任何设置的默认状态Chrome、Edge、Firefox都是无扩展的干净状态。单位毫秒取中位数。测试站点指标Brave(调校后)Brave(默认)ChromeEdgeFirefox新闻门户首页DOMContentLoaded12801520186017802120新闻门户首页Load完成38604250498048305460技术博客文章页DOMContentLoaded640720820810940技术博客文章页Load完成14201650184017902060电商首页DOMContentLoaded21002440276026903080电商首页Load完成51205580621060506890文档站页面DOMContentLoaded430480520510560文档站页面Load完成9801040112010901210仪表盘模板页DOMContentLoaded7608308908801020仪表盘模板页Load完成19702090224021902470数据是本地环境的相对比较不同地区、不同网络环境下绝对数值会有浮动但趋势是稳定的Brave在内容型页面上比Chrome快15%到25%比Firefox快20%到30%而且这是和“干净版Chrome”比出来的结果。如果你日常用Chrome还挂了几个扩展差距只会更大。2.2 快在哪个环节请求拦截省下的不只是流量还有排队时间光看总耗时不够我还拆了每个阶段的耗时比例这里有个容易被忽视的事实Brave和Chrome在DNS解析、TCP连接、TLS握手这几个“网络建连”环节上几乎没有差异差距全部集中在HTML下载之后、DOMContentLoaded完成之前这个区间。也就是说Brave快的不是“网速”也不是“渲染引擎”。真正拉开差距的是它默认去掉了那几十个广告、追踪、分析脚本在渲染主线程上造成的排队和阻塞。以新闻门户首页为例我在Brave Shields面板里看到一个新闻首页被拦截的第三方请求有87个。这些请求在Chrome里会全部执行每个请求都要经历一次网络往返、下载脚本、解压、解析、执行期间还会产生大量的DOM操作和网络监听器。在页面加载高峰期这些脚本会跟正文脚本抢CPU时间片直接把关键渲染路径拉长。Brave拦截掉它们之后页面剩下的请求数量减少了将近七成渲染进程要干的活自然少了一大截。用生活化的类比来说Chrome像一家全自助餐厅每个顾客广告脚本都要进厨房炒两个菜后厨再大也会排队Brave的Shields像在餐厅门口放了个保安把一大半根本没点菜的闲人拦在外面厨房里真正的订单自然出得快。2.3 TTFB的微妙差异请求排队的影响比你想的更直接大家经常说TTFB主要看服务器浏览器在这个指标上造不了假。这个说法我基本同意但有一个细节TTFB的取值范围不是从浏览器发起请求那一刻就开始的它包含请求排队时间。当同一个页面挂了几十个第三方域名时Chromium的请求调度线程会有一部分排队延迟Brave拦截掉这些请求后剩余请求的排队更顺TTFB会小幅下降。实测里新闻首页的TTFBBrave大概比Chrome快90到120毫秒。这个幅度不算大但它发生在加载链路的最前端后续每个资源的下载和解析都受它影响所以在最终DCL上的差异会被放大。这也是为什么不能只盯着TTFB说“浏览器之间没区别”——前端的几十毫秒顺延到整个加载链路就是几百毫秒的体验差。3. 所谓“前提”其实是三个被忽略的变量3.1 前提一默认配置不等于最优配置Shields要靠“调”标题里说的“有个前提”第一个就是这件事很多人装了Brave之后什么都不动那它确实比Chrome快但快得有限。默认的标准Shields模式拦截了不少广告和追踪器但离“榨干性能”还差得远。我自己测了三种配置的差异配置方案新闻门户DCL电商首页DCL标准模式默认1520ms2440ms严格模式1350ms2290ms严格模式常用站点降级1280ms2260ms严格模式比标准模式快的原因很明显标准模式拦截的是“已知”的广告和追踪域名而严格模式会额外拦截跨站指纹脚本、加密货币挖矿脚本以及浏览器伪装检测脚本。这些东西在默认情况下也会加载和执行只是不一定算广告。把这一层拦掉之后第三方请求数量继续下降最关键的是JavaScript执行总量又少了一块。但全局开严格模式会有一个副作用某些网站的正常功能会出问题。评论区加载不出来、第三方登录弹窗白屏、某些视频站的播放器抽风这些我都遇到过。所以第4节的调校清单里我会强调“站点级例外”的用法而不是简单粗暴地全局开严格。3.2 前提二扩展越少才越显真功夫原生拦截远胜扩展组合第二个前提和扩展有关。我用“装了6个常用扩展的Chrome”和“干净Brave”跑了同一组页面数据很离谱Chrome加载新闻门户首页的DCL从1860ms直接涨到2150msLoad从4980ms涨到5600ms。浏览器启动时间也从2秒出头拉到接近4秒。这不是说扩展质量不行而是扩展的运行机制决定了它必然有开销。装进Chrome的每一个扩展都共享同一个事件系统和消息通道很多扩展还会随页面注入content script即使它什么都没做JavaScript引擎也得先把它解析一遍。Brave在这个场景下的优势是结构性的广告拦截不需要走扩展通道它是在网络请求发出前的url匹配阶段就被直接短路了省掉的不仅是网络流量还有content script注入、消息监听、后台页面常驻这一整套运行时开销。所以用Brave的用户绝大多数不需要再装uBlock Origin这类广告拦截扩展等于天然少了一层负担。3.3 前提三场景分化内容型网页优势大重型Web应用拉不开差距第三个前提也是我在标题里最想强调的Brave“最快”并不是全场景通吃的。我专门拿Figma、一个在线IDE、一个大文件PDF阅读器这类重型Web应用做了验证结果是各浏览器之间的差距非常小甚至多次测试的随机波动都盖过了真实差异。原因不复杂。这类应用的脚本体积巨大长连接多交互密集决定性能上限的是JavaScript引擎执行速度和渲染进程的稳定性而这些在Chromium系浏览器里几乎完全一致。Shields在重型应用上能拦截的第三方资源基本有限网站本身的第一方脚本就占了加载量的绝大部分。所以每当有人问“Brave是不是最快的浏览器”我都会反问一句你平时主要用浏览器干什么如果主要是看新闻、刷博客、逛电商、查文档、刷社交信息流那答案很明确Brave在“内容型网站的加载体验”这个维度上确实能排第一。如果你是重度Web IDE用户、主要跑大型在线协同应用那选哪个Chromium都差不多没必要为了“快”换浏览器。4. 把“最快的Brave”调教出来的完整清单4.1 性能相关设置硬件加速、内存节省、预加载先说设置界面里必须检查的几项路径以Brave稳定版为准新版本可能略有变动但关键词不会变。第一确认硬件加速已开启。在设置里搜索“硬件加速”确保开关是打开的。关闭状态下视频解码、Canvas绘制、CSS合成都会退回CPU软件运算页面滚动和动画帧率肉眼可见地下降。这个选项对任何浏览器都重要Brave也不例外。第二打开内存节省器和节能模式。位置在“设置 → 性能”。内存节省器会把不活跃的后台标签页整个冻结释放出来的内存优先供给前台页面。我实测开这个开关在多标签场景下能降低系统内存占用15%到25%对前台页面的稳定性也有帮助。节能模式控制的是后台任务和后台窗口的帧率日常插电使用影响不大用笔记本的时候能明显延长续航。第三打开页面预加载。在“设置 → 隐私和安全 → 页面预加载”里勾选“启用页面预加载”。这个选项会让浏览器在你输入网址还没来得及回车的时候就进行DNS预查询和TCP/TLS预连接甚至在地址栏匹配到地址时直接预渲染页面。对经常手动输入网址的用户来说体感提速非常明显。4.2 Shields分级与站点级例外怎样既不翻车又不慢回到Shields设置。我现在的建议是不要全局开严格而是以“严格 站点例外”的组合方式来用。点地址栏右侧的盾牌图标进入Shields面板把“跟踪和广告拦截”调整到“严格”。这是全局基准。然后正常上网遇到某个网站显示异常再点一下盾牌把该站点的Shields从严格降回标准或者干脆给这个站点加白名单。这个方法最大的好处是日常浏览的大多数内容型网站都跑在严格模式下性能收益吃满那些必须牺牲一点加载速度来换功能的站点单独豁免就好。我还专门把“阻止脚本”Block Scripts单独测了一遍。在Shields高级控件里打开“阻止脚本”后新闻门户首页的DCL能进一步降到1050ms左右是全场最快的配置。代价是页面上的评论、登录弹窗、懒加载图片全部失效绝大多数动态站点基本没法正常用。所以我现在的建议是只在纯文档站、技术手册、静态博客这类基本不需要JavaScript的页面上临时打开其他站点不碰。4.3 可以关闭的内置模块与常见误区Brave这几年内置了不少功能新闻流、钱包、Leo AI助手、积分系统。这些功能对部分用户很有价值但也有各自的资源开销。如果纯粹为性能可以在设置里依次处理“设置 → 新标签页”把背景主题改成极简模式新标签页上的卡片和新闻流能给关掉就关掉。这块每次打开新标签页都会加载属于纯闲置开销。“设置 → Web3”钱包功能用不上的话可以直接禁用。钱包组件会常驻一个后端进程虽然占用不大但没必要。Leo AI是点按触发的云端接口不主动打开不会有额外负载留着不影响日常速度。有个常见误区要提醒有些人为了“纯净”把Brave的自动更新服务、同步链路的后台进程全禁了。我不建议这么干浏览器安全更新比那几MB内存占用重要得多性能焦虑不该搭上安全底线。4.4 启动与标签策略从源头上减少加载负担最后一件事管好启动行为和标签页习惯。在“设置 → 启动时”选择“打开新标签页”不要选择“继续浏览上次打开的网页”。如果你习惯从上次会话接着工作让浏览器一次性恢复二三十个标签页就算Brave再快也会卡一阵子。想要继续上次工作手动用书签或者干脆开个标签组体验比全量恢复流畅得多。我也建议日常以“新标签页 地址栏搜索”作为主要交互路径而不是“保留所有标签页不放”。后台标签页即便被内存节省器冻结恢复时也需要重新渲染积累多了照样拖慢前台体验。5. 避坑观察测速时最容易犯的错以及我有意不做的对比5.1 测速方法论为什么缓存、后台进程、DNS缓存都在撒谎这次测速我踩过好几次坑说出来给大家当参考。第一个坑是缓存。就算开了无痕窗口浏览器进程退出后系统DNS缓存依然保留第二次访问任何网站都会比第一次快一大截。所以测试必须冷热分离每个浏览器测同一站点时要么统一全清缓存要么统一接受第一次访问的结果。我选的是后者每一轮测试都先清缓存然后记录首次加载数据。第二个坑是后台进程。Windows下很多软件会在后台悄悄联网下载更新、上传指标、同步文件都会抢占网络和磁盘。我测试的时候把所有无关软件全部退出只剩一个浏览器。你如果自己跑测试也至少要保证“两个浏览器对比时后台环境一致”。第三个坑是取数和样本。单次跑出来的数据方差很大CDN命中位置、某条连接被限速、甚至隔壁WiFi信号干扰都会让结果波动。我要求自己每个站点连测5次、取中位数就是这个原因。拿一次的数据说结论不靠谱。5.2 我为什么没把“装了uBlock Origin的Chrome”当对照组关于广告拦截有免不了会被问到Chrome装一个uBlock Origin是不是就跟Brave一样快了我没在表格里放这组对比是因为它测了以后很难得出干净的结论。uBlock能拦截Brave能拦的大部分请求但它作为扩展本身要占用一部分内存和CPU。实际跑下来装uBlock的Chrome页面DCL和Brave接近启动速度和多标签场景内存占用却明显落后。这说明扩展方案能缩短“加载性能”的差距但补不上“整体资源占用”的差距。当然如果只盯着页面加载那一瞬间装uBlock的Chrome确实可以把和Brave的差距缩得很小。但这恰恰证明了一个观点广告和追踪脚本是拖慢现代网页的头号元凶谁把它拦得干净谁就在体验上占优。Brave赢在把这个能力内置到了浏览器最底层。5.3 兼容性提醒当“最快”挡不住登录框和支付弹窗写了再多的性能优化兼容性这块还是得单拎出来说清楚。Shields开得越猛碰到的网站问题就越多。我遇到的典型情况包括某个知名评论系统在严格模式下加载不出来、一个票务平台的登录弹窗无限转圈、合作方的一个内部OA页面布局乱掉。这些问题都不致命但真实存在。处理方案就是我在4.2里说的站点级例外没有别的好办法。也因为这个原因我始终建议桌面用户至少保留一款备用的Chromium浏览器。Brave作为主力很好但遇到完全不兼容的站点用备用浏览器打开比跟Shields缠斗一下午高效得多。这不算打脸这叫工具理性。5.4 启动速度另算Brave冷启动不算最快别用启动时间否定它最后补一个容易被拿来抬杠的点Brave的冷启动速度在几款浏览器里并不领先甚至略微靠后。这主要是因为它内置了更多功能模块启动时要初始化的组件比Chrome多。我实测从双击图标到地址栏可以输入Brave大约是2.8秒Chrome大约2.2秒Edge大约1.9秒。但“浏览器快不快”对大多数用户来说指的其实是打开网页的快慢而不是软件本身启动那一下。这两个指标很容易被混淆。Brave冷启动稍慢换来的是页面加载阶段更干净的请求链路和更少的资源占用这笔账我是觉得划算的。你如果特别在意软件启动速度那把启动页设成新标签页并且关掉自动恢复标签Brave也能追回一秒左右。跑完这轮横评我的原始结论没变正确配置之下Brave在内容型页面上的加载速度确实能稳稳排第一。这个第一不是玄学是通过拦截几十个第三方请求、减少JavaScript执行和网络排队换来的。不过我更想强调的是别把“最快”当成万能优势。它在文档站、博客和新闻页面里都很突出但到了重型Web应用或者说只要某个网站在严格防护下出了问题速度和稳定就得做取舍。我现在的做法是把盾牌图标固定在工具栏第一排遇到不正常显示的页面点一下降级到标准模式遇到长期信任的内部系统直接加白名单。如果你想用Brave不要急着全盘照搬别人的“极速配置”先按第4节的清单调一遍然后在自己最常用的十几个站点上跑一周找出那个不会弄坏任何功能的最快档位。这种调校出来的速度才是真正属于你的“最快”。