前端CMS【免费下载链接】wp-calypsoThe JavaScript and API powered WordPress.com项目地址https://gitcode.com/gh_mirrors/wp/wp-calypso点击查看免费下载导读automattic/browser-data-collector是 WordPress.com Calypso 仓库中用于采集浏览器端真实用户性能RUM数据的核心包它以start()/stop()的极简接口围绕一次页面测量会话聚合来自 Performance Timing、Network Information、Device Memory 等浏览器 API 的数据并通过 Logstash 通道上报到后端。本文将以 packages/browser-data-collector/CHANGELOG.md 为骨架结合包内源码与 Calypso 消费端实现完整讲解其架构概念、上报字段、生命周期以及 1.0.0 → 3.0.0 三个版本中 ESM/CJS 模块格式与收集器 API 的演进脉络。读完本文你将能独立使用该包接入页面性能埋点并理解其构建产物与破坏性变更对依赖方的影响。一、包定位浏览器 RUM 数据的采集与上报按 packages/browser-data-collector/README.md 的说明该包用于采集 RUM 数据并发送到 LogstashThis package is used to collect RUM data and send it to Logstash。从 package.json 可见其基本元信息包名automattic/browser-data-collector当前版本3.0.0描述A tool to collect data from different browser APIs一个从不同浏览器 API 采集数据的工具许可证GPL-2.0-or-later作者 Automattic Inc.依赖极轻运行时仅依赖tslib与wpcom-proxy-request后者即上报通道所依赖的代理请求库。也就是说这个包本身不负责页面渲染也不定义业务埋点它提供的是一次测量会话的通用框架由调用方指定报告 id框架负责在会话开始/结束时收集一组浏览器环境与性能数据最终把一条结构化报告投递到 Logstash。二、核心概念与架构Report / Collector / Transport / APIREADME 将包的架构划分为五个概念理解它们是使用该包的前提概念作用Report承载采集结果的对象包含 id、开始/结束时间与额外元数据也是最终发送给 Logstash 的 payloadCollector一个函数用额外的元数据扩充augment已有的 ReportGlobal Collectors应用于所有报告的收集器列表Transport将 Report 发送到后端系统的机制目前仅实现了 LogstashAPI访问某个浏览器 API或更广义的外部数据源的适配层由 Collector 调用以获取要写入 Report 的数据这套分层在源码中有清晰对应Report 类型与 Collector 函数签名定义在 src/types.tsCollector ( report: Report ) Promise Report | Report即收集器接收一个 Report 并返回它同步或异步均可ReportData Map string, number | string | boolean 表明报告数据以字符串键 数值/字符串/布尔值的形式存储Collector 的具体实现集中在 src/collectors/index.ts统一导出deviceMemory、performanceTiming、environment、networkInformation、fullPageStart、inlineStart、pageVisibilityStart/pageVisibilityStop、blockingResourcesAPI 适配层位于 src/api其中 device-memory.ts、environment.ts、network-information.ts、performance-timing.ts、resources-timing.ts 分别封装对应浏览器 API 的读取逻辑Transport 实现位于 src/transports/logstash.ts。三、快速上手start / stop / cancel 三接口README 给出了最小用法示例调用方只需要一个字符串 idimport { start, stop } from automattic/browser-data-collector; start( my-page, { fullPageLoad: true } ); // Later in the same page stop( my-page );三个公开接口的完整语义定义在 src/index.tsstart( id, options? )src/index.ts#L14-L30id报告名必须传给之后的stop()用于匹配options.fullPageLoad默认true为true时报告从页面导航开始navigation start起算时长为false时从当前时刻起算options.collectors额外的 Collector 列表会追加到内建收集器之后幂等保护同一id已存在进行中的报告时第二次start()会被直接忽略。cancel( id )src/index.ts#L37-L39取消一个进行中的报告且不发送。源码注释指出这是为了满足client/dashboard中startPerformanceTracking的需求例如页面在测量完成前发生路由切换需要放弃本次报告。stop( id, options? )src/index.ts#L48-L67结束报告并把 payload 交给 transport 发送返回true/false表示发送是否成功若该id不存在进行中的报告则静默失败返回false避免影响页面渲染源码注释fail silently to avoid messing with the rendering由于start()返回的 Promise 可能仍在执行报告异步启动stop()会先await已存在的报告再调用startedReport.stop( collectors )。一次start/stop会话发送到 Logstash 的报告至少包含README 声明durationstop()调用时刻相对start()调用时刻的耗时若fullPageLoad: true则相对导航开始时刻id报告名上例中即my-page环境数据如 Calypso 版本与构建目标build targetPerformance Timing API 的数据。四、内建 Collector 清单与上报字段所有内建收集器定义于 src/collectors/index.ts按报告起点与报告终点两个时机分组使用详见下一节生命周期。以下为各收集器写入 Report 的字段与数据来源4.1 起点类fullPageStart / inlineStartfull-page-start.ts 将report.beginning设为performance.getEntriesByType(navigation)[0].navigationStart即导航开始时间并写入fullPage: trueinline-start.ts 则将起点设为当前时刻Date.now()写入fullPage: false。这两个字段决定了duration的基准也标记了本次报告是整页加载还是页面内交互测量。4.2 终点类performanceTiming / blockingResourcesperformance-timing.ts 是字段最多的收集器它把 Navigation Timing API 的各时间戳统一规范化为相对report.beginning的偏移后写入覆盖navigationStart、unloadEventStart、unloadEventEnd、redirectStart、redirectEnd、fetchStart、domainLookupStart、domainLookupEnd、connectStart、connectEnd、secureConnectionStart、requestStart、responseStart、responseEnd、domLoading、domInteractive、domContentLoadedEventStart、domContentLoadedEventEnd、domComplete、loadEventStart、loadEventEnd共 20 个字段。其归一化逻辑src/collectors/performance-timing.ts#L26-L33值得注意当原始值为 0例如无重定向时redirectStart不存在时直接返回 0避免上报负数。blocking-resources.ts 基于 Resource Timing API 分析阻塞首屏的脚本资源它筛选initiatorType script、在domContentLoaded之前完成下载、且decodedBodySize 0用于排除跨域资源的资源随后写入字段含义resourcesCount阻塞脚本数量resourcesStart/resourcesEnd第一批资源的requestStart与最后一批的responseEndresourcesCompressed所有阻塞脚本encodedBodySize之和压缩后体积resourcesUncompressed所有阻塞脚本decodedBodySize之和解压后体积resourcesTransferred所有阻塞脚本transferSize之和实际传输字节含头resourcesCacheRatio缓存命中率0–100由100 - round( min( 1, transferred / compressed ) * 100 )计算并显式封顶 1 以避免负值4.3 全局类Global Collectors所有报告都会执行environmentenvironment.ts写入versionwindow.COMMIT_SHA、targetwindow.BUILD_TARGET、envwindow.configData.env_id这些全局变量的类型声明见 global-types.tsdeviceMemorydevice-memory.ts写入memorynavigator.deviceMemory单位 GB非整数networkInformationnetwork-information.ts写入networknavigator.connection.effectiveType取值slow-2g/2g/3g/4g枚举定义于 global-types.tspageVisibilityStart / pageVisibilityStoppage-visibility.ts用于检测报告期间标签页是否曾被切到后台。起点收集器注册visibilitychange监听终点收集器注销监听并写入hidden布尔值。源码注释明确指出其局限无法检测页面加载与 start 调用之间发生的隐藏且假定同一时刻只有一个报告在运行。五、Report 生命周期从启动到 payload 组装src/report.ts 中的ReportImpl是生命周期实现的核心两种启动方式ReportImpl.fromNow( id, collectors )与ReportImpl.fromPageStart( id, collectors )分别对应fullPageLoad: false/true内建收集器的分组装配构造器把收集器分成startCollectors与stopCollectors两组。整页模式isInitial下起点组为[ fullPageStart, pageVisibilityStart ]终点组为[ performanceTiming, blockingResources, deviceMemory, environment, pageVisibilityStop, networkInformation ]非整页模式下起点组为[ inlineStart, pageVisibilityStart ]终点组仅含全局收集器不采集 Performance Timing 与阻塞资源容错执行runCollectors用Promise.all并发执行收集器并用try/catch包住单个收集器src/report.ts#L61-L74——单个收集器抛错不会中断整份报告只会打印console.warnCollector #idx for report xxx failed to runpayload 组装stop()先记录this.end Date.now()执行全部终点收集器后把内部Map数据通过reduce展开为普通对象最终返回{ id, duration: end - beginning, ...data }src/report.ts#L81-L96。这里duration直接由end - beginning得出而beginning正是由起点收集器写入的导航时间或Date.now()。六、TransportLogstash 上报通道src/transports/logstash.ts 是当前唯一实现的 Transport它借助wpcom-proxy-request向后端发起 POST 请求export const send async ( payload ) { return request( { method: POST, apiVersion: 1.1, path: /logstash, body: { params: JSON.stringify( { feature: calypso_client, message: perf.nav, properties: payload, } ), }, } ); };可见上报的消息被标记为feature: calypso_client、message: perf.nav而start()/stop()采集到的完整字段id、duration、环境信息、Performance Timing 等整体放入properties。README 还提到发送是采样进行的以避免压垮 REST 端点并且采样决策可以基于完整报告内容而不仅是 id做出这为按采集到的任意字段条件化发送留出了空间。七、CHANGELOG 解读三个版本的破坏性变更与模块格式演进CHANGELOG.md 记录了三代版本的演进全部为 Breaking 变更下面结合仓库当前状态逐一解读。7.1 v1.0.0模块整体转换为 ESM-onlyBreaking: Module converted to ESM only. CJS build is not provided anymore.1.0.0 起包只提供 ESM 构建不再提供 CJS。这一决策的影响是Node 端require()该包的传统 CommonJS 消费方将无法加载必须改为 ESMimport。7.2 v2.0.0移除 Performance Mark 与 Measures 收集器Breaking: Drop support for Performance Mark and Measures collectors2.0.0 移除了基于 User Timing APIperformance.mark()/performance.measure()的收集器。从当前仓库源码结构看这一变更的痕迹仍然可见src/api/user-timing.ts 中仍保留着getMarks()performance.getEntriesByType(mark)与getMeasures()performance.getEntriesByType(measure)两个 API 适配函数但在 src/collectors/index.ts 的收集器出口列表中已不再有任何 marks/measures 收集器——即API 层残留、Collector 层移除升级到 2.0.0 及以上版本的依赖方不应再期望报告中包含 mark/measure 相关字段。7.3 v3.0.0撤销 ESM 独占重新提供 CJSBreaking: Undo ESM conversion, CJS is provided again.3.0.0 撤销了 1.0.0 的 ESM-only 决策重新提供 CJS 构建。当前 package.json 的产物声明与 tsconfig 配置完整印证了这一点构建命令tsc --build ./tsconfig.json ./tsconfig-cjs.json即一次构建产出两套产物tsconfig.jsonESMmodule继承自automattic/calypso-typescript-config/ts-package.jsonoutDir为dist/esm声明文件输出到dist/typestsconfig-cjs.jsonCJSmodule: commonjsoutDir为dist/cjs双入口声明main: dist/cjs/index.js、module: dist/esm/index.js、types: dist/types并在exports字段中同时暴露import: ./dist/esm/index.js与require: ./dist/cjs/index.js另有calypso:src指向src/index.ts供 Calypso 内部源码直引。对于使用方3.0.0 意味着Node/CommonJS 环境可再次require()现代打包器与浏览器端继续走 ESM 入口TypeScript 消费方统一从dist/types获取类型声明。由于 3.0.0 依然是 Breaking 变更相对 2.0.0 而言依赖方升级时应重新验证自身打包配置与require/import的解析路径。八、在 Calypso 中的实际应用performance-tracking 封装层browser-data-collector并不是直接被各个页面调用的Calypso 在 client/lib/performance-tracking 中为它封装了一层业务 API详见 client/lib/performance-tracking/README.md特性开关封装层通过config.isEnabled( rum-tracking/logstash )判断是否启用 RUM 上报client/lib/performance-tracking/lib.js#L54-L56未启用时startPerformanceTracking/stopPerformanceTracking为空操作默认业务收集器buildDefaultCollector( state )基于 Redux state 为所有性能报告附加站点与用户上下文包括siteId、siteIsJetpack、siteIsSingleUser、siteIsAtomic、sitesCount、sitesVisibleCount、userCountryCode、userBootstrapped、userLocale以及翻译 chunk 的加载时长与数量translationsChunksDuration/translationsChunksCount元数据收集器buildMetadataCollector( metadata )把调用方传入的任意键值对写入报告多种停止方式usePerformanceTrackerStophook、PerformanceTrackerStop/组件与withPerformanceTrackerStopHoC分别适配函数组件、可渲染多种状态loading/主内容的组件与类组件停止时以当前 section 名作为报告 id 与start()对应。这一层正好演示了 Collector 机制的扩展性业务侧可以像内建收集器一样通过传入额外 Collector 把任意上下文注入同一份 RUM 报告而无需改动包的框架代码。九、使用与升级注意事项小结基于上述源码与 CHANGELOG 事实在实际接入或升级时建议关注以下几点模块格式若在 Node/CommonJS 环境使用需依赖 3.0.0重新提供 CJS若仍锁定1.x则必须使用 ESM 导入不再有 mark/measure 数据依赖 2.0.0时不要期待报告包含 User Timing mark/measure 字段如需该能力只能在业务侧自行实现收集器fullPageLoad 语义整页测量默认的duration从导航开始起算适合页面加载性能页面内交互测量需显式传fullPageLoad: false此时不会采集 Performance Timing 与阻塞资源字段id 唯一性同一时刻同一 id 只能有一个进行中的报告重复start()会被忽略stop()不存在的 id 会静默返回false单点容错单个收集器抛错只会告警不会中断报告但浏览器 API 缺失如无navigator.deviceMemory、无connection.effectiveType会导致对应字段为undefined或缺失需在分析端做兼容处理上报通道数据经wpcom-proxy-requestPOST 到/logstashapiVersion: 1.1以feature: calypso_client、message: perf.nav的固定结构承载properties即完整报告字段可据此在 Logstash/Kibana 侧建立查询与告警。从架构上看这个包把浏览器 API 读取API 层、字段写入Collector 层、会话管理Report 层与数据投递Transport 层彻底解耦配合 Calypso 侧基于 Redux 状态的业务收集器形成了一套既可开箱即用、又可任意扩展的 RUM 采集链路——这正是它在 client/lib/performance-tracking 中被广泛复用的根本原因。赞分享前端CMS【免费下载链接】wp-calypsoThe JavaScript and API powered WordPress.com项目地址https://gitcode.com/gh_mirrors/wp/wp-calypso点击查看免费下载相关推荐OneUptime 前端浏览器 RUM 接入指南使用 OpenTelemetry Browser SDK 采集真实用户监控数据OneUptime 前端浏览器 RUM 接入指南使用 OpenTelemetry Browser SDK 采集真实用户监控数据 导读 本文是 OneUptim可观测性后端运维前端云原生微服务AI Agent使用 browser-data-collector 在 wp-calypso 中采集 RUM 数据并上报 Logstash使用 browser data collector 在 wp calypso 中采集 RUM 数据并上报 Logstash 导读 本文围绕 wp calypso前端CMS浏览器原生 ESM 引入 uuid 全指南browser-esmodules 示例深度解析浏览器原生 ESM 引入 uuid 全指南browser esmodules 示例深度解析 本指南以仓库中 examples/browser esmodule开发工具CLI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 深入解析 @automattic/browser-data-collector：Calypso 浏览器 RUM 数据采集架构与 ESM/CJS 演进
前端CMS【免费下载链接】wp-calypsoThe JavaScript and API powered WordPress.com项目地址https://gitcode.com/gh_mirrors/wp/wp-calypso点击查看免费下载导读automattic/browser-data-collector是 WordPress.com Calypso 仓库中用于采集浏览器端真实用户性能RUM数据的核心包它以start()/stop()的极简接口围绕一次页面测量会话聚合来自 Performance Timing、Network Information、Device Memory 等浏览器 API 的数据并通过 Logstash 通道上报到后端。本文将以 packages/browser-data-collector/CHANGELOG.md 为骨架结合包内源码与 Calypso 消费端实现完整讲解其架构概念、上报字段、生命周期以及 1.0.0 → 3.0.0 三个版本中 ESM/CJS 模块格式与收集器 API 的演进脉络。读完本文你将能独立使用该包接入页面性能埋点并理解其构建产物与破坏性变更对依赖方的影响。一、包定位浏览器 RUM 数据的采集与上报按 packages/browser-data-collector/README.md 的说明该包用于采集 RUM 数据并发送到 LogstashThis package is used to collect RUM data and send it to Logstash。从 package.json 可见其基本元信息包名automattic/browser-data-collector当前版本3.0.0描述A tool to collect data from different browser APIs一个从不同浏览器 API 采集数据的工具许可证GPL-2.0-or-later作者 Automattic Inc.依赖极轻运行时仅依赖tslib与wpcom-proxy-request后者即上报通道所依赖的代理请求库。也就是说这个包本身不负责页面渲染也不定义业务埋点它提供的是一次测量会话的通用框架由调用方指定报告 id框架负责在会话开始/结束时收集一组浏览器环境与性能数据最终把一条结构化报告投递到 Logstash。二、核心概念与架构Report / Collector / Transport / APIREADME 将包的架构划分为五个概念理解它们是使用该包的前提概念作用Report承载采集结果的对象包含 id、开始/结束时间与额外元数据也是最终发送给 Logstash 的 payloadCollector一个函数用额外的元数据扩充augment已有的 ReportGlobal Collectors应用于所有报告的收集器列表Transport将 Report 发送到后端系统的机制目前仅实现了 LogstashAPI访问某个浏览器 API或更广义的外部数据源的适配层由 Collector 调用以获取要写入 Report 的数据这套分层在源码中有清晰对应Report 类型与 Collector 函数签名定义在 src/types.tsCollector ( report: Report ) Promise Report | Report即收集器接收一个 Report 并返回它同步或异步均可ReportData Map string, number | string | boolean 表明报告数据以字符串键 数值/字符串/布尔值的形式存储Collector 的具体实现集中在 src/collectors/index.ts统一导出deviceMemory、performanceTiming、environment、networkInformation、fullPageStart、inlineStart、pageVisibilityStart/pageVisibilityStop、blockingResourcesAPI 适配层位于 src/api其中 device-memory.ts、environment.ts、network-information.ts、performance-timing.ts、resources-timing.ts 分别封装对应浏览器 API 的读取逻辑Transport 实现位于 src/transports/logstash.ts。三、快速上手start / stop / cancel 三接口README 给出了最小用法示例调用方只需要一个字符串 idimport { start, stop } from automattic/browser-data-collector; start( my-page, { fullPageLoad: true } ); // Later in the same page stop( my-page );三个公开接口的完整语义定义在 src/index.tsstart( id, options? )src/index.ts#L14-L30id报告名必须传给之后的stop()用于匹配options.fullPageLoad默认true为true时报告从页面导航开始navigation start起算时长为false时从当前时刻起算options.collectors额外的 Collector 列表会追加到内建收集器之后幂等保护同一id已存在进行中的报告时第二次start()会被直接忽略。cancel( id )src/index.ts#L37-L39取消一个进行中的报告且不发送。源码注释指出这是为了满足client/dashboard中startPerformanceTracking的需求例如页面在测量完成前发生路由切换需要放弃本次报告。stop( id, options? )src/index.ts#L48-L67结束报告并把 payload 交给 transport 发送返回true/false表示发送是否成功若该id不存在进行中的报告则静默失败返回false避免影响页面渲染源码注释fail silently to avoid messing with the rendering由于start()返回的 Promise 可能仍在执行报告异步启动stop()会先await已存在的报告再调用startedReport.stop( collectors )。一次start/stop会话发送到 Logstash 的报告至少包含README 声明durationstop()调用时刻相对start()调用时刻的耗时若fullPageLoad: true则相对导航开始时刻id报告名上例中即my-page环境数据如 Calypso 版本与构建目标build targetPerformance Timing API 的数据。四、内建 Collector 清单与上报字段所有内建收集器定义于 src/collectors/index.ts按报告起点与报告终点两个时机分组使用详见下一节生命周期。以下为各收集器写入 Report 的字段与数据来源4.1 起点类fullPageStart / inlineStartfull-page-start.ts 将report.beginning设为performance.getEntriesByType(navigation)[0].navigationStart即导航开始时间并写入fullPage: trueinline-start.ts 则将起点设为当前时刻Date.now()写入fullPage: false。这两个字段决定了duration的基准也标记了本次报告是整页加载还是页面内交互测量。4.2 终点类performanceTiming / blockingResourcesperformance-timing.ts 是字段最多的收集器它把 Navigation Timing API 的各时间戳统一规范化为相对report.beginning的偏移后写入覆盖navigationStart、unloadEventStart、unloadEventEnd、redirectStart、redirectEnd、fetchStart、domainLookupStart、domainLookupEnd、connectStart、connectEnd、secureConnectionStart、requestStart、responseStart、responseEnd、domLoading、domInteractive、domContentLoadedEventStart、domContentLoadedEventEnd、domComplete、loadEventStart、loadEventEnd共 20 个字段。其归一化逻辑src/collectors/performance-timing.ts#L26-L33值得注意当原始值为 0例如无重定向时redirectStart不存在时直接返回 0避免上报负数。blocking-resources.ts 基于 Resource Timing API 分析阻塞首屏的脚本资源它筛选initiatorType script、在domContentLoaded之前完成下载、且decodedBodySize 0用于排除跨域资源的资源随后写入字段含义resourcesCount阻塞脚本数量resourcesStart/resourcesEnd第一批资源的requestStart与最后一批的responseEndresourcesCompressed所有阻塞脚本encodedBodySize之和压缩后体积resourcesUncompressed所有阻塞脚本decodedBodySize之和解压后体积resourcesTransferred所有阻塞脚本transferSize之和实际传输字节含头resourcesCacheRatio缓存命中率0–100由100 - round( min( 1, transferred / compressed ) * 100 )计算并显式封顶 1 以避免负值4.3 全局类Global Collectors所有报告都会执行environmentenvironment.ts写入versionwindow.COMMIT_SHA、targetwindow.BUILD_TARGET、envwindow.configData.env_id这些全局变量的类型声明见 global-types.tsdeviceMemorydevice-memory.ts写入memorynavigator.deviceMemory单位 GB非整数networkInformationnetwork-information.ts写入networknavigator.connection.effectiveType取值slow-2g/2g/3g/4g枚举定义于 global-types.tspageVisibilityStart / pageVisibilityStoppage-visibility.ts用于检测报告期间标签页是否曾被切到后台。起点收集器注册visibilitychange监听终点收集器注销监听并写入hidden布尔值。源码注释明确指出其局限无法检测页面加载与 start 调用之间发生的隐藏且假定同一时刻只有一个报告在运行。五、Report 生命周期从启动到 payload 组装src/report.ts 中的ReportImpl是生命周期实现的核心两种启动方式ReportImpl.fromNow( id, collectors )与ReportImpl.fromPageStart( id, collectors )分别对应fullPageLoad: false/true内建收集器的分组装配构造器把收集器分成startCollectors与stopCollectors两组。整页模式isInitial下起点组为[ fullPageStart, pageVisibilityStart ]终点组为[ performanceTiming, blockingResources, deviceMemory, environment, pageVisibilityStop, networkInformation ]非整页模式下起点组为[ inlineStart, pageVisibilityStart ]终点组仅含全局收集器不采集 Performance Timing 与阻塞资源容错执行runCollectors用Promise.all并发执行收集器并用try/catch包住单个收集器src/report.ts#L61-L74——单个收集器抛错不会中断整份报告只会打印console.warnCollector #idx for report xxx failed to runpayload 组装stop()先记录this.end Date.now()执行全部终点收集器后把内部Map数据通过reduce展开为普通对象最终返回{ id, duration: end - beginning, ...data }src/report.ts#L81-L96。这里duration直接由end - beginning得出而beginning正是由起点收集器写入的导航时间或Date.now()。六、TransportLogstash 上报通道src/transports/logstash.ts 是当前唯一实现的 Transport它借助wpcom-proxy-request向后端发起 POST 请求export const send async ( payload ) { return request( { method: POST, apiVersion: 1.1, path: /logstash, body: { params: JSON.stringify( { feature: calypso_client, message: perf.nav, properties: payload, } ), }, } ); };可见上报的消息被标记为feature: calypso_client、message: perf.nav而start()/stop()采集到的完整字段id、duration、环境信息、Performance Timing 等整体放入properties。README 还提到发送是采样进行的以避免压垮 REST 端点并且采样决策可以基于完整报告内容而不仅是 id做出这为按采集到的任意字段条件化发送留出了空间。七、CHANGELOG 解读三个版本的破坏性变更与模块格式演进CHANGELOG.md 记录了三代版本的演进全部为 Breaking 变更下面结合仓库当前状态逐一解读。7.1 v1.0.0模块整体转换为 ESM-onlyBreaking: Module converted to ESM only. CJS build is not provided anymore.1.0.0 起包只提供 ESM 构建不再提供 CJS。这一决策的影响是Node 端require()该包的传统 CommonJS 消费方将无法加载必须改为 ESMimport。7.2 v2.0.0移除 Performance Mark 与 Measures 收集器Breaking: Drop support for Performance Mark and Measures collectors2.0.0 移除了基于 User Timing APIperformance.mark()/performance.measure()的收集器。从当前仓库源码结构看这一变更的痕迹仍然可见src/api/user-timing.ts 中仍保留着getMarks()performance.getEntriesByType(mark)与getMeasures()performance.getEntriesByType(measure)两个 API 适配函数但在 src/collectors/index.ts 的收集器出口列表中已不再有任何 marks/measures 收集器——即API 层残留、Collector 层移除升级到 2.0.0 及以上版本的依赖方不应再期望报告中包含 mark/measure 相关字段。7.3 v3.0.0撤销 ESM 独占重新提供 CJSBreaking: Undo ESM conversion, CJS is provided again.3.0.0 撤销了 1.0.0 的 ESM-only 决策重新提供 CJS 构建。当前 package.json 的产物声明与 tsconfig 配置完整印证了这一点构建命令tsc --build ./tsconfig.json ./tsconfig-cjs.json即一次构建产出两套产物tsconfig.jsonESMmodule继承自automattic/calypso-typescript-config/ts-package.jsonoutDir为dist/esm声明文件输出到dist/typestsconfig-cjs.jsonCJSmodule: commonjsoutDir为dist/cjs双入口声明main: dist/cjs/index.js、module: dist/esm/index.js、types: dist/types并在exports字段中同时暴露import: ./dist/esm/index.js与require: ./dist/cjs/index.js另有calypso:src指向src/index.ts供 Calypso 内部源码直引。对于使用方3.0.0 意味着Node/CommonJS 环境可再次require()现代打包器与浏览器端继续走 ESM 入口TypeScript 消费方统一从dist/types获取类型声明。由于 3.0.0 依然是 Breaking 变更相对 2.0.0 而言依赖方升级时应重新验证自身打包配置与require/import的解析路径。八、在 Calypso 中的实际应用performance-tracking 封装层browser-data-collector并不是直接被各个页面调用的Calypso 在 client/lib/performance-tracking 中为它封装了一层业务 API详见 client/lib/performance-tracking/README.md特性开关封装层通过config.isEnabled( rum-tracking/logstash )判断是否启用 RUM 上报client/lib/performance-tracking/lib.js#L54-L56未启用时startPerformanceTracking/stopPerformanceTracking为空操作默认业务收集器buildDefaultCollector( state )基于 Redux state 为所有性能报告附加站点与用户上下文包括siteId、siteIsJetpack、siteIsSingleUser、siteIsAtomic、sitesCount、sitesVisibleCount、userCountryCode、userBootstrapped、userLocale以及翻译 chunk 的加载时长与数量translationsChunksDuration/translationsChunksCount元数据收集器buildMetadataCollector( metadata )把调用方传入的任意键值对写入报告多种停止方式usePerformanceTrackerStophook、PerformanceTrackerStop/组件与withPerformanceTrackerStopHoC分别适配函数组件、可渲染多种状态loading/主内容的组件与类组件停止时以当前 section 名作为报告 id 与start()对应。这一层正好演示了 Collector 机制的扩展性业务侧可以像内建收集器一样通过传入额外 Collector 把任意上下文注入同一份 RUM 报告而无需改动包的框架代码。九、使用与升级注意事项小结基于上述源码与 CHANGELOG 事实在实际接入或升级时建议关注以下几点模块格式若在 Node/CommonJS 环境使用需依赖 3.0.0重新提供 CJS若仍锁定1.x则必须使用 ESM 导入不再有 mark/measure 数据依赖 2.0.0时不要期待报告包含 User Timing mark/measure 字段如需该能力只能在业务侧自行实现收集器fullPageLoad 语义整页测量默认的duration从导航开始起算适合页面加载性能页面内交互测量需显式传fullPageLoad: false此时不会采集 Performance Timing 与阻塞资源字段id 唯一性同一时刻同一 id 只能有一个进行中的报告重复start()会被忽略stop()不存在的 id 会静默返回false单点容错单个收集器抛错只会告警不会中断报告但浏览器 API 缺失如无navigator.deviceMemory、无connection.effectiveType会导致对应字段为undefined或缺失需在分析端做兼容处理上报通道数据经wpcom-proxy-requestPOST 到/logstashapiVersion: 1.1以feature: calypso_client、message: perf.nav的固定结构承载properties即完整报告字段可据此在 Logstash/Kibana 侧建立查询与告警。从架构上看这个包把浏览器 API 读取API 层、字段写入Collector 层、会话管理Report 层与数据投递Transport 层彻底解耦配合 Calypso 侧基于 Redux 状态的业务收集器形成了一套既可开箱即用、又可任意扩展的 RUM 采集链路——这正是它在 client/lib/performance-tracking 中被广泛复用的根本原因。赞分享前端CMS【免费下载链接】wp-calypsoThe JavaScript and API powered WordPress.com项目地址https://gitcode.com/gh_mirrors/wp/wp-calypso点击查看免费下载相关推荐OneUptime 前端浏览器 RUM 接入指南使用 OpenTelemetry Browser SDK 采集真实用户监控数据OneUptime 前端浏览器 RUM 接入指南使用 OpenTelemetry Browser SDK 采集真实用户监控数据 导读 本文是 OneUptim可观测性后端运维前端云原生微服务AI Agent使用 browser-data-collector 在 wp-calypso 中采集 RUM 数据并上报 Logstash使用 browser data collector 在 wp calypso 中采集 RUM 数据并上报 Logstash 导读 本文围绕 wp calypso前端CMS浏览器原生 ESM 引入 uuid 全指南browser-esmodules 示例深度解析浏览器原生 ESM 引入 uuid 全指南browser esmodules 示例深度解析 本指南以仓库中 examples/browser esmodule开发工具CLI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考