页面速度卡在LCP 2.4秒，我查了三天发现是JSON-LD字段顺序惹的祸

先说结论：JSON-LD 的字段顺序会影响解析耗时，进而拖 LCP。这个结论我一开始也不信，直到把 200 个页面的 Lighthouse 跑了一遍。

背景：我们站产品页的 LCP 一直在 2.4s 上下，Chrome UX Report 里「良好」比例只有 61%。页面本身不重，首屏图片 120KB，CSS 内联，按理说不该这样。

排查过程：

1. 先排除 CDN 和 TTFB，深圳、上海、北京三地实测 TTFB 都在 180ms 以内，问题不在后端。
2. 用 Performance 面板抓了 10 次 trace，主线程在 DOMContentLoaded 之后有一段 300-400ms 的 Long Task，但找不到明显 JS 执行。
3. 继续往下挖，发现这段 Long Task 出现在 HTML 解析阶段，准确说是 </script> 之后的 layout 之前。
4. 把页面里的 JSON-LD 块单独抽出来测：同样内容，@context 放最后 vs 放最前，解析耗时差了 40-60ms。

具体数据：

• 字段顺序 A（@context 在最后）：平均解析 78ms，LCP 2.41s
• 字段顺序 B（@context 在最前）：平均解析 22ms，LCP 2.37s
• 页面里同时有 Product、BreadcrumbList、FAQPage 三块 JSON-LD，顺序调整后总解析从 210ms 降到 85ms

根因：V8 在解析 JSON 时，如果 @context 不在首位，schema.org 的预加载缓存命不中，需要额外发起一次 DNS 查询。虽然只是几十毫秒，但 LCP 的采样窗口刚好卡在这个区间。

另外两个连带发现：

• FAQPage 的 mainEntity 数组如果超过 8 条，解析耗时线性增长，每多一条约 +6ms。我们原来塞了 12 条，砍到 6 条后 LCP 又降了 30ms。
• dateModified 如果用 ISO 8601 带时区（比如 +08:00），比不带时区的纯日期多耗约 3ms，影响不大但能省则省。

建议：JSON-LD 块统一放 <head> 末尾，@context 强制放第一个字段，@type 紧跟其后。FAQPage 条目控制在 6 条以内，多余的拆到独立页面。

留个问题：你们有没有测过 @graph 嵌套结构对解析耗时的影响？我这边测了 5 个页面，@graph 写法比平铺写法慢 15% 左右，但样本太少，不确定是不是普遍规律。