我们正在使用 PageSpeed Insight API 来测试我们网站的性能。
我们发现，一些发出延迟 XHR 请求的第三方脚本，通常在network-requestsPageSpeed Insight 响应部分的末尾，有时会被分配一个statusCode“-1”和一个endTime“-1”。
我假设statusCode“-1”和endTime“-1”的 a 表示请求超时或被 PageSpeed Insight API 逻辑中止。
这个对吗？
当这些迟到的请求出现在network-requests我们的 LCP 分数时，比我们没有看到这些迟到的 XHR 请求时要低。
为什么 LCP 会受到此类请求的影响？
大多数情况下，这些请求是每隔几秒触发一次的心跳请求。看起来 PageSpeed Insight API 将network-requests使用正确的endTimeand请求/捕获其中的一些早期请求statusCode，但如果 API 在 12 到 13 秒左右以某种方式请求其中一个请求，那么 API 似乎只是中止了这些请求，正是在这些情况下，我们看到 LCP 受到了影响。
以下是预期 LCP 的示例：
- LCP：2.5 秒
- 中列出的最后一个 XHR 请求的
network-requestsstatusCode=200，startTime=8527，endTime=8587
以下是意外 LCP 的示例：
- LCP：6.9 秒
- 中列出的最后一个 XHR 请求的
network-requestsstatusCode=-1，startTime=13041，endTime=-1