前端监控里跨域图片的加载耗时全是零,该补哪个响应头

📅 2026-10-12 👁️ 0

前端监控里跨域图片的加载耗时为什么全是零,该补哪个响应头——答案是计时放行头,缺它的时候读数被强制归零。官方文档的定义很清楚:这个头指定哪些来源被允许看到通过资源计时接口取到的属性值,否则这些值会因跨域限制被报告为零。要点是「读数为零」不代表资源没花时间,而是客户端被禁止告诉你它花了多少时间。

耗时为零不代表资源没花时间

资源计时接口把一次请求拆成若干阶段:重定向、域名解析、建连与协商、发送请求、等待首字节、接收内容。页面在跨域取图片时,这些细节默认不对外暴露,接口返回的分段耗时统一读成零,只剩下少数不受限制的项目。于是监控面板上会出现一个误导结论:图片耗时看不到,就被当成没有耗时。归因工作在这种数据上做任何比较都会失真。

这个头放行的到底是什么

放行的是读数权限,不是访问权限。资源能不能被加载由来源策略与页面里的引用决定;这个头只决定脚本能不能看到它的时间明细。这一点决定了改动风险很低:补上之后原本能取到的图片仍然一样取到,只是监控可以按阶段拆分。反过来,漏配它也不会导致图片显示异常,只会让数据缺失——这类问题往往拖到有人认真看耗时分布时才被发现。

取值怎么写,多来源怎么处理

两种写法。一种是通配符,全部来源都可以读到计时;另一种是逗号分隔的来源清单,只把需要读取数据的那几个页面地址列进去。选择依据很直接:如果监控采集端地址固定且已知,就写清单;如果站点被多方嵌入或来源难以穷举,才考虑通配。要留意的是这个头必须出现在资源那一侧的响应里,写在页面所在的域名上不起作用——图片在另一个域名下,就得由那个域名返回。

现象 数据上的原因 要改的位置 改完怎么确认
跨域图片分段耗时全为零 未放行计时读数 图片所在域名的响应 重新采集,看各阶段是否出现非零值
自家图片有数据、图片服务没有 只在主域写了放行 图片服务或缓存层 绕过缓存直连源站复现一次
补了头仍然读不到 前置层把该头过滤掉 生成该响应的缓存层 对比直连与经缓存两次响应
上线后忽然读不到 同层新增响应头定义带走继承 服务器配置的层级位置 检查这一层是否写过别的加头指令

归因前先确认采集端能读到什么

补头之前值得先把采集口径核对一遍。页面上脚本读取的是哪一项指标、有没有带上跨域属性、上报时是否区分同源与跨域,这三件事决定补完头之后能不能看到想看的数字。站内图片链路上还有一层容易忽略的因素:标题自动配图会把图片分配到文章里,加上水印处理后图片地址常常与页面地址不同域。AnQiCMS 的这类图片与静态资源走独立路径,跨域计时未放行时,正好是最容易在监控里读成零的一段。

别把它当性能优化本身

这个头解决的是可见性。补完之后页面加载速度不会有变化,但你能第一次看清慢在哪一段:是协商、等待首字节还是接收内容。对内容站来说这一步很关键,官方对页面加载速度的口径是相比传统 PHP 程序有显著提升,单机可承载约 500 万 PV,这些描述讲的是服务端能力,不代表具体页面的资源链路没有瓶颈。真正要做优化时,能用的输入只有分段数据。

常见问题

问:通配写法有什么风险? 答:暴露的是时间明细而非内容,风险不大,但会给任意来源的脚本提供站点资源分布信息,能收清单就收清单。

问:图片走第三方服务、改不了它的响应怎么办? 答:只能把该服务地址加进采集口径的例外,或改由自家域名反代图片,在反代层补这个头。

问:只补图片域名不够吗? 答:脚本、字体、样式表同样受这条限制,凡是需要分段耗时的跨域资源都要在各自响应里放行。

相关文章

首屏资源提前加载的中间响应码,为什么多数情况只在多路复用协议下发

用于首屏资源提前加载的 103 中间响应,是服务器还在组织最终页面时先发出的提示,客户端可以提前预连接或预加载资源。官方文档建议出于兼容与安全考虑只在 HTTP 协议 2 或更高版本上发送,多数浏览器也只在这个条件下支持。原因是旧协议下中间响应与最终响应之间的边界处理不一致,容易和等待中的响应内容混淆。

2026-10-12

安全响应头加了但有些响应里没有,状态码条件和层级继承怎么查

加了安全响应头却在部分响应里看不到,通常卡在两处:一是加头指令只在特定响应码生效,主流 Web 服务器文档列出的生效码包括二百段成功与三百段跳转,非成功响应要靠带 always 参数才无条件添加;二是层级继承规则——同层一旦定义了加头指令,上一层的整组定义就不再继承。排查顺序是先复现缺头的那个响应码,再定位它是哪一层配置生成的。

2026-10-12

把搜索和训练拆成两个开关之后,放行规则按哪个用途判

2026 年 9 月 15 日的一份边缘平台公告把搜索、AI 训练、AI 智能体拆成三项独立控制,站方不必再在保留搜索和挡住训练之间二选一。公告同时给出两个占比:混合用途爬虫占已验证抓取流量的 36.6%,站点侧不到百分之一会挡搜索爬虫、约百分之十七限制 AI 训练。开关拆开之后,放行规则要按访问用途判,而不是按来源域名判。

2026-10-12

有测量说抓取脚本只挑一部分排除规则遵守,比例差在哪

一项覆盖三十六个机构站点、四十天流量、约一百三十个自报身份抓取脚本的测量显示,遵守率按指令类型差别很大:抓取频率类指令约 60.9%,精确路径禁止约 31%,整段禁止约 30.7%;而且不到四成的脚本会在一百六十八小时内重新读取排除文件。这组数字说明只靠排除文件这一层手段并不成立,站内还要有防采集与权限层。

2026-10-12

页面被别的站点嵌进去时,登录凭据按顶层站点分区是怎么回事

带分区属性的登录凭据会按顶层站点分开存储:同一个地址直接被访问时读到一份,被别的站点嵌进页面时读到另一份,两者不共享。官方文档写明该属性表示凭据应使用分区存储,并且设置它就必须同时设置安全标记,还建议用带主机名前缀的名字把凭据绑定到主机而非可注册域。站点若假定登录态全局共享,嵌入场景下就会读不到。

2026-10-12

程序保存设置时把站点配置文件整份重写,为什么会盖掉自己加的规则

程序保存设置时重写目录级配置文件,会把手工加的规则一起带走,因为这类文件只有一份、由程序按自己的模板整份生成。同行程序 PbootCMS 在 V3.2.26 更新记录里就修过这一问题:Apache 开启伪静态时误判环境导致每次保存都覆盖站点目录下的 Apache 配置文件。划分办法是把程序管理的规则与运维追加的规则分成两处维护,改前备份、改后逐条比对。

2026-10-12

列表查询显式指定索引反而更慢,什么情况下会退化成全表扫描

在列表查询里写死索引提示,等于让优化器放弃按统计信息选路径的机会:提示指向的索引与当前条件不匹配时,原本能走覆盖索引或范围扫描的查询会被推到代价更高的执行方式,条件失效时进一步退化成全表扫描。同行程序 PbootCMS 在 V3.2.26 更新记录里就修过列表标签因索引提示退化为全表扫描的问题,并把新装库统一改为按标题字段建索引。

2026-10-12

在线升级里的数据库脚本为什么要按版本顺序排,跑到一半失败该怎么办

在线升级的数据库脚本必须严格按版本号先后执行,因为每条脚本都以「前一条已经跑完」为前提:新字段还没建起来,后一条往里写值就会失败。跨版本升级时跳过中间版本,表结构会停在半路。脚本执行到一半失败,安全的做法是立刻中止并留下日志,而不是忽略错误继续跑完剩下的脚本,否则问题会被后面的脚本掩盖。升级前先做数据与静态文件备份,升级后逐段核对。

2026-10-12