1. 为什么我会写一个叫 rea 的小工具先说结论rea 不是一个框架也不是一个通用库它是我为了解决一个具体的性能排查问题自己写的资源加载分析工具。名字没有太深含义就是 Resource Efficiency Analyzer 的缩写简单直接方便项目里几个同事记。事情的起因是这样的团队负责的一个中后台系统用户投诉打开页面要转好几秒。我们在监控平台上能看到一堆资源加载的数据比如某个 JS 文件加载了 800ms某个图片加载了 500ms数据很准确可问题是——这些 URL 对应的业务代码在哪里一个 URL 看起来是很长的 hash 文件名光看地址根本不知道它是哪个页面模块、哪个组件、哪条业务链路。我们只能对着构建产物 map 文件一个个猜效率极低。我当时想能不能做一个工具把资源加载信息自动对应到“业务模块”上让监控平台输出的不再是“chunk-abc123.js”而是“订单列表页的列表组件”这样谁看一眼就知道问题出在哪。于是 rea 就诞生了。这个工具能做的核心事情有三个自动采集页面运行时所有资源加载的耗时、大小、类型通过构建产物的模块信息把资源 URL 还原成业务模块名按组件、页面、业务链路聚合输出生成可读性极高的分析报告。如果你是做前端性能优化、维护大型中后台项目或者只是对“网页为什么慢”这件事感兴趣这篇文章里的思路和踩坑记录应该都能帮到你。即使你不需要用 rea 本身理解它背后的“资源-模块映射”思路对你排查线上性能问题也会有启发。2. rea 的核心设计把一条加载链路拆成三段2.1 整体架构采集、映射、聚合rea 的逻辑其实不复杂核心就三步采集、映射、聚合。这三步分别解决三个不同层面的问题数据从哪来、数据怎么归因、数据怎么呈现。采集层在浏览器里监听所有资源加载事件拿到每一个 JS、CSS、图片、字体、接口请求的 URL、耗时、大小、发起时间。映射层把 URL 通过构建产物的元数据比如模块 ID、chunk 名、source 路径映射到对应的业务模块名。聚合层按业务模块做汇总比如“订单列表页下的 list-table 组件总共贡献了首屏 1200ms 的下载耗时”最终输出一份 JSON 或 HTML 报告。这样设计的好处是每一层都可以独立替换。比如采集层可以用浏览器原生 Performance API也可以换成自己的注入代码映射层如果构建工具变了只需要改映射表的生成逻辑聚合层甚至可以直接对接已有的监控系统。我一开始想过把这三层放一起后来发现拆开反而更好维护。因为浏览器环境、构建环境、后端分析环境是完全不同的运行时耦合在一起只会让调试变得难上加难。2.2 采集层不依赖 Performance API 的降级方案一般说到资源加载监控大家第一时间会想到PerformanceObserver配合resource类型的条目。但实际用起来会发现一个问题跨域资源的信息经常拿不全。比如第三方 CDN 上的脚本如果服务器没有返回Timing-Allow-Origin响应头responseEnd、transferSize这些字段全是 0根本没法分析。所以我在 rea 里做了两条采集路径优先使用PerformanceObserver能拿到完整时序就记录下来同时用MutationObserver监听脚本、图片、样式标签的插入通过「标签出现时间 - 页面开始时间」估算加载耗时作为降级数据。这个降级方案听起来不够精确但在实际排查中已经够用了。判断一个资源慢不慢我们往往只需要知道“是哪个业务模块加载了它”而不是精确到微秒。后面我会在踩坑部分细说具体问题。采集层还有一个容易忽略的点不是所有资源都需要分析。首屏只关心 JS、CSS、首屏图片和关键字体而埋点上报、音视频、懒加载图片这些不应该计入首屏耗时否则会把结论带偏。rea 里通过后缀名白名单和resourceType过滤规则来做这件事默认只统计 JS/CSS/图片/字体其余一律忽略。2.3 映射层从 URL 到业务模块的归因过程映射层是 rea 最有价值的地方也是最难写的一部分。做前端的人都知道构建工具会把源代码打包成带有 hash 的文件我们拿到的 URL 长这样/static/js/chunk-3f8a9b.1234.js如果不用 sourcemap任何人看到这个 URL 都只能靠猜。rea 的解决办法是让构建阶段生成一份映射表。简单说在 webpack 或 vite 打包结束后解析构建统计文件webpack 是stats.jsonvite 是build-metadata找出每个 chunk 包含的模块路径然后把这些路径里和业务代码相关的部分提取出来。举个例子chunk-3f8a9b.js: src/pages/order/list.vue src/components/order/status-tag.vue src/utils/order-helper.ts我只需要把这个 chunk 的主要归属识别出来规则也很粗暴路径中如果存在pages目录就优先取pages下的页面名如果不存在再看components下的组件名。最终生成这样一张映射表URL 片段业务归属chunk-3f8a9b订单列表页 / status-tag 组件chunk-admin-vendor公共第三方库 / 后台框架相关然后把这张表下发到浏览器采集层一旦抓到 URL就用表里的 key 做匹配自动替换成易读的业务名。这里有个关键问题映射表不能太大。如果直接把所有模块路径都下发动辄几百 KB反而拖慢首屏。我在实现时只保留每个 chunk 的页面名和核心组件名精确到页面级别就够用了组件级别的细分则通过页面内的代码标记来补充后面会讲。2.4 聚合层输出一份“能看懂”的报告拿到一堆“业务模块 耗时 大小”的记录后聚合层要做的是把碎片整理成洞察。我的做法是输出两部分内容。第一部分是页面级汇总表展示这个页面首屏加载了哪些 chunk、每个 chunk 的业务归属、占总耗时的百分比。第二部分是模块贡献排行榜比如1. 订单列表页业务代码 812ms 40% 2. moment.js 等第三方库 436ms 21% 3. 首屏图片资源 310ms 15% ...这样一列用户自己就知道首屏慢的锅到底该扣在谁头上。而且聚合层还支持按用户粒度抽样可以区分“首次访问”和“二次访问”的差异避免缓存干扰判断。聚合层最容易被忽略的需求是可比较性。如果这次优化后报告显示订单页从 812ms 降到了 500ms团队才有信心继续做。所以我在输出里固定了一个 schema包含时间戳、项目版本、环境标识方便横向对比。否则过一个月再看历史数据都不知道是哪次发版的影响。3. 落地过程中的 4 个坑与对应的补救办法3.1 跨域资源拿不到详细时序这个坑我前文提到过实际操作起来比想象中更严重。我们的项目里字体文件和部分第三方统计脚本都放在 CDN而这些 CDN 的响应头并没有Timing-Allow-Origin。结果就是用PerformanceObserver拿到的条目里duration为 0transferSize为 0看起来像资源根本没加载过。解决思路是分层降级第一层完整时序可用直接使用duration第二层时序缺失但有响应头信息用fetchStart到responseEnd的差值估算第三层如果完全拿不到资源本身的数据则用PerformanceEntry.startTime减去页面 navigation 开始时间得到一个“该资源从页面开始到发起加载”的累计时间这个时间能反映出它是首屏第几批资源结合瀑布图依旧可以判断优先级。实际使用中我发现降级数据虽然精度不高但对于定位问题完全够用。比如字体文件耗时难测但通过它在瀑布图里的位置就能看出它是被某个页面组件里的font-face动态触发加载的问题归因方向没有变。3.2 映射表体积膨胀第一版实现时我直接把所有 chunk 的所有模块路径写进映射表结果一个大型中后台项目的映射表 JSON 压缩后仍然有 900 多 KB这对低端机用户来说是不能接受的。一开始我想用 gzip 压缩下发但后来发现更干净的办法是只在本地调试和灰度环境启用完整映射表生产环境只下发“页面级映射表”并且用布隆过滤器做一些模糊匹配。具体做法是构建时先根据 chunk 名和入口文件归属生成一份粗粒度映射表只保留 chunk 名到业务页面的关系对组件级细节不在运行时下发而是把采样数据上报到后端后直接在服务端用 sourcemap 做二次归因——这样浏览器端只承担很轻的采集工作大量计算都放到服务端。最终生产下发的映射表被压缩到不到 20KB。如果你是个人项目或者内部分析系统同样建议把重计算放到后端浏览器端保持轻量否则很容易因为工具本身影响了性能。3.3 异步组件动态加载的边界情况我们在项目里用了不少import()动态加载比如用户点击某个按钮后才去加载弹窗组件、图表组件。问题也随之而来这些资源严格来说不属于首屏但如果点击发生得足够早它们就会混在首屏资源列表里甚至被误判为“首屏慢的元凶”。后面我在采集规则里加入了用户交互时间戳记录页面 ready 时间点之前发起的资源加载作为“首屏资源”记录首次点击、滚屏事件发生之后发起的资源加载标记为“交互触发资源”两类资源在报告里分开统计。这样处理之后报告里不会再出现“用户点了一个按钮导致首屏多 1 秒”这种荒谬结论。我也在思路层面建议团队优化首屏时不要一门心思只盯着所有资源的总耗时要先分清哪些资源是首屏必经链路哪些是交互链路把两个问题分开看待。3.4 本地开发和生产环境行为不一致本地开发时资源都是由 dev server 实时编译返回的耗时普遍偏大而且热更新会产生很多额外的模块请求。如果只在本地跑 rea很容易得出“页面好慢”的错误结论。我在使用规范上做了三条约定只分析生产构建或预发构建的结果本地数据只用于功能调试生产环境剥离 sourcemap 后模块路径已经不可读所以需要依赖构建期生成的统计文件如果要在本地验证映射是否正确必须单独跑一次带 sourcemap 的构建。这三条约定写进 rea 的文档后团队在使用时就没有再出现过“本地几百毫秒线上却没问题”这种困惑。4. 从“能用”到“好用”rea 的后续增强4.1 支持子应用拆分上报中后台项目经常是几个团队共同开发不同的业务子域比如财务模块、运营模块、数据分析模块。如果所有数据混在一份报告里每个团队都只关心自己那块报告价值就大打折扣。我在后面给 rea 加了一个简单的分组机制构建时给每个子应用打上标记上报数据时带上appName字段聚合层按 appName 二次分组。这样各团队可以在同一个平台上看自己子域的独立报告同时也可以汇总看整体情况。这个改动不难但收益很大。团队之间的“性能甩锅”明显少了因为每个人都能直接看到自己模块的贡献度讨论问题也有数据依据。4.2 自动圈复杂度与预算告警资源大小和加载耗时本质上和代码复杂度强相关。如果一个模块在首屏贡献了 300ms但实际业务逻辑非常简单那大概率是依赖了某个体积巨大的第三方库。为了快速发现这类问题我在 rea 里集成了一个简单的审计规则对每个业务模块计算它打包后的体积如果体积超过设定阈值自动标记为“待优化模块”如果模块体积连续两个版本上升就在报告中显示趋势警告。阈值怎么定我们粗略按“目标首屏预算为 3 秒内”反推。如果一个页面首屏资源最多只能下载 900KB JS而页面级汇总显示某模块占了 300KB那它就被判定为高开销模块。这套审计机制不需要很精确能提醒人去看一眼就达到目的了。4.3 生成瀑布图和火焰图纯文字报告虽然能看清整体但处理“谁等谁”的问题时还是不够直观。比如一个组件的 JS 加载了 700ms但这 700ms 里面其实包含了对另一个资源的串行等待。为了看清这类依赖关系我利用 performance 资源条目里的initiatorType和上下文信息生成了一份简化版的瀑布图。瀑布图用纯 CSS 渲染成 HTML纵向列出资源时间轴横向按时间排列鼠标悬停可以看到归属模块。虽然没有专业性能平台的交互那么丰富但胜在可以直接分享给团队成员让后端或者测试同事也能一眼看懂。火焰图则用来展示模块之间的调用依赖一个页面模块加载了哪些子组件每个子组件触发了哪些资源请求。这个功能实现起来比较复杂目前我只是做了第一版但已经能解决 80% 的“这个资源到底是谁发起的”问题。5. 实际使用后我的一些体会工具做出来之后团队已经日常用了三个月。最大的感受不是报告多好看而是性能优化终于从“凭感觉”变成“按证据”。以前排查首屏慢大家第一反应是“图片是不是没压缩”“有没有可能是某个接口太慢”现在只要打开 rea 报告就能直接看到是某个业务模块的某个 chunk 占了绝对大头省掉了很多不必要的争论。有一个例子特别明显之前监控平台一直提示首页某个 JS 文件加载慢我们试过拆包、预加载各种手段都没有明显效果。后来用 rea 才发现这个 chunk 本来只属于一个“帮助中心弹窗”组件但在入口文件里被同步引入了导致首屏白白承担了这 400 多毫秒。把引入方式改成异步import()后首屏耗时直接下降了 15%。这种问题如果只看性能监控平台的资源耗时列表根本发现不了——因为资源时间本身就包含了大量并行下载的时间根本没法定位到代码逻辑。另一个体会是这种资源归因工具的维护成本并不低千万别指望写完就能一劳永逸。构建工具版本一升级统计文件格式可能就变了代码目录一调整映射规则又得跟着改。我在实践里摸索出来的经验是把映射规则尽量做简单只保留“页面-入口”这一层关系组件层交给后端 sourcemap 二次分析这样前端升级时只需要维护很少的代码。最后说一个实用的小技巧。如果你们暂时没有人力去写一个像 rea 这样的完整工具有一个最简陋的替代方案在webpack或vite构建完成后用脚本读取统计文件把 chunk 名和页面名对应关系输出成一份 JSON然后在浏览器里通过PerformanceObserver拿到资源 URL 之后手动去查这个 JSON。虽然过程笨拙但至少能让你在一两个小时内找到首屏最可疑的那几个 chunk。性能优化最怕的不是复杂而是无从下手。rea 本质上就是把“资源加载”这种底层的浏览器行为翻译成“业务代码”的人话。如果你也在为线上性能问题头疼不妨按这个思路做一个小小的分析脚本说不定会比买高昂的监控服务更有用。