[{"data":1,"prerenderedAt":343},["ShallowReactive",2],{"blog-lcp-metric-vs-user-wait":3,"blog-prev-lcp-metric-vs-user-wait":113,"blog-next-lcp-metric-vs-user-wait":189},{"id":4,"title":5,"author":6,"body":7,"canonical":97,"category":98,"cover":97,"date":99,"description":100,"draft":101,"extension":102,"keywords":97,"meta":103,"navigation":104,"noindex":101,"ogImage":97,"path":105,"seo":106,"seoDescription":97,"seoTitle":97,"stem":107,"tags":108,"updated":97,"__hash__":112},"blog\u002Fblog\u002Flcp-metric-vs-user-wait.md","LCP 一点二秒客户还说卡，我们查到了指标外的问题","元析智能",{"type":8,"value":9,"toc":89},"minimark",[10,14,19,22,25,38,41,44,47,56,59,62,65,68,71,74,77,80,83,86],[11,12,13],"p",{},"上个月一个 B2B 数据工具客户找我们，说后台打开\"特别慢\"，可 PageSpeed 跑出来 LCP 1.3 秒，三项指标全绿。我们跟了 20 个真实用户的操作录屏，问题不在渲染，在于他们要等 2.4 秒才看到数据。Core Web Vitals 测的是\"画出来\"，不是\"能不能用\"。",[15,16,18],"h2",{"id":17},"骨架屏把-lcp-做漂亮了","骨架屏把 LCP 做漂亮了",[11,20,21],{},"这个产品的首屏是仪表盘。骨架屏 0.3 秒就出现了，LCP 元素被记为骨架屏里的标题文字，所以 1.3 秒这个数很好看。但真正的报表数据来自一个 2.4 秒才返回的接口，用户盯着骨架屏转圈，感受就是慢。",[11,23,24],{},"同类情况还有三种：",[26,27,28,32,35],"ul",{},[29,30,31],"li",{},"图片用渐进式加载，LCP 记的是低清图首次渲染的时间",[29,33,34],{},"按钮渲染出来了，JS 还没加载完，点了没反应，这属于 INP 的范畴",[29,36,37],{},"字体 swap 后文字重绘，LCP 记的是第一次绘制",[11,39,40],{},"指标没坏，只是它衡量的是\"页面出现了\"，不是\"页面能用了\"。",[15,42,43],{"id":43},"我们补了两条自建埋点",[11,45,46],{},"从今年 3 月开始，我们给客户站加两条埋点，用 PerformanceObserver 加自定义打点：",[48,49,50,53],"ol",{},[29,51,52],{},"首屏关键数据到位时间：接口 resolve 到第一次渲染完成的间隔",[29,54,55],{},"首次可用交互时间：用户第一个真实点击得到响应的时刻",[11,57,58],{},"这两个数不需要精确到毫秒，能看出量级就够。上面那个客户，数据到位时间 P75 是 2.6 秒，LCP 的 P75 是 1.4 秒。差出来的这 1.2 秒，就是用户嘴里那个\"慢\"。",[15,60,61],{"id":61},"别拿分数当体验的替代品",[11,63,64],{},"我的立场很直接：PSI 分数是给外人看的，真实用户指标是给自己看的。B2B 软件站如果只盯 LCP、INP、CLS 三个数，会漏掉一整类问题——数据链路的等待。",[11,66,67],{},"SaaS 后台、控制台、数据看板这类产品，用户对\"多久能用\"的敏感度远高于\"多久能看见\"。这类站的性能优化，接口和渲染必须一起看，单测前端没有意义。",[11,69,70],{},"怎么查：抽 20 个真实用户会话录屏，找\"页面已加载但用户停顿超过 2 秒才开始操作\"的片段。这类片段占比超过三成，就别再修 LCP 了，去查接口和首屏数据编排。",[11,72,73],{},"顺带说下取舍：给首屏数据做串行请求还是并行，很多团队为了页面的视觉顺序选择串行，代价就是可用时间翻倍。我们的做法是并行拉取、按视觉顺序渲染，宁可多一次请求，也不让用户在骨架屏上等。",[15,75,76],{"id":76},"两个常被问到的问题",[11,78,79],{},"Q：这种站还要不要做 Core Web Vitals？",[11,81,82],{},"要做，但别把它当验收标准。LCP、INP、CLS 是及格线，及格之后用户满不满意，取决于数据什么时候到。我们的做法是两套指标并列看，谁差修谁。",[11,84,85],{},"Q：怎么跟不懂技术的老板解释这件事？",[11,87,88],{},"别讲指标定义，讲他的使用场景。我就问了一句：你早上打开后台，看到表格出来能用，需要几秒？他想了想说三四秒。然后我把 2.6 秒的数据放到他面前，他就明白了。用户感知的时间，才是要优化的那个数。",{"title":90,"searchDepth":91,"depth":91,"links":92},"",2,[93,94,95,96],{"id":17,"depth":91,"text":18},{"id":43,"depth":91,"text":43},{"id":61,"depth":91,"text":61},{"id":76,"depth":91,"text":76},null,"技术SEO","2025-09-22","一个 B2B 数据工具的 LCP 只有 1.2 秒，用户却抱怨打开很慢。原因是骨架屏先渲染、真实数据 2.4 秒才回来。我们补了两条自建埋点，才把用户嘴里的\"慢\"量化出来。",false,"md",{},true,"\u002Fblog\u002Flcp-metric-vs-user-wait",{"title":5,"description":100},"blog\u002Flcp-metric-vs-user-wait",[109,110,111],"LCP","真实用户指标","SaaS 性能","U_--kaAL7I71n3S3whQR3cskX0TPt2vwP7Xk3Qn9S6Q",{"id":114,"title":115,"author":6,"body":116,"canonical":97,"category":177,"cover":97,"date":178,"description":179,"draft":101,"extension":102,"keywords":97,"meta":180,"navigation":104,"noindex":101,"ogImage":97,"path":181,"seo":182,"seoDescription":97,"seoTitle":97,"stem":183,"tags":184,"updated":97,"__hash__":188},"blog\u002Fblog\u002Fbaidu-tongji-vs-ga4-diff.md","百度统计和 GA4 的流量差 30%，问题常在这四处",{"type":8,"value":117,"toc":169},[118,121,124,127,130,133,136,139,142,145,148,151,154,157,160,163,166],[11,119,120],{},"百度统计显示 1.2 万次访问、GA4 只有 8600，这种差距是正常的；不正常的是你花一周去找谁在说谎。两个工具的统计口径天生不同，差异只能解释，不能调平。2025 年 9 月我们给一个站做过完整对账，差异主要来自四处。",[15,122,123],{"id":123},"时区先错位",[11,125,126],{},"百度统计默认东八区。GA4 的媒体资源时区在建资源时设定，很多人选了 UTC，或者干脆没留意默认值。跨过 0 点的那部分流量会算到不同日期，做周对比时，光这一项就能吃掉一半差异。先去 GA4 管理后台把时区改成 Asia\u002FShanghai，再比数据。",[15,128,129],{"id":129},"过滤规则不对称",[11,131,132],{},"GA4 没配内部流量过滤，办公室 IP、测试机的访问全算进去；百度统计如果开了排除 IP，同一批人又不算。反过来，广告拦截插件对 GA4 的 gtag 脚本影响更大，大约 10% 到 20% 的访客不会上报。",[15,134,135],{"id":135},"会话和归因逻辑不同",[11,137,138],{},"百度统计会话默认 30 分钟，GA4 也能设。真正的区别在来源归因：GA4 按 last non-direct 处理，用户先搜索进来、第二天直接访问，仍可能记成 organic；百度统计记成直接访问。评估 SEO 效果时，这个差异会让自然搜索看起来更好。",[15,140,141],{"id":141},"站内跳转被算成推荐流量",[11,143,144],{},"支付回调、帮助中心子域、带参数的站内链接，在 GA4 里经常触发 self-referral，多出一条来源；百度统计基本没这个问题。处理办法是把这些域加进不需要的推荐流量列表，一次配好，后面不用管。",[15,146,147],{"id":147},"我们自己的口径",[11,149,150],{},"海外站以 GA4 为主口径，国内落地页看百度统计，报告里写一句口径不同、不做互相校验。别花时间把两个数字调平，调不平。要判断 SEO 有没有起效，只盯一个工具里有机搜索的落地页和转化事件，趋势对了就够了。",[15,152,153],{"id":153},"对账时我们固定做三件事",[11,155,156],{},"第一，两个工具都切到东八区，取自然月 1 日到月底的数据，避开跨日边界。",[11,158,159],{},"第二，GA4 里导出渠道组为 Organic Search 的会话数，百度统计里导出搜索引擎来源的访问次数，只看这两个数，别看总访问量。",[11,161,162],{},"第三，把差异按落地页拆开，看是哪些页面差得多。通常首页和产品页差 10% 以内，博客文章页能差 30% 以上，因为文章页的访客更多装了拦截插件。",[11,164,165],{},"做完这三步，剩下的差距基本都有解释。写进报告就一句话：两工具口径不同，本站以 GA4 为准。列两个数字让客户自己算，比解剖差异更累。",[11,167,168],{},"上个月还有客户问，能不能用两个工具的平均值当真实流量。不能。平均值只是把两个偏差混在一起，误差不会抵消，只会更难解释。2025 年 9 月那次对账之后，我把这句话变成了报告模板里的固定一行。",{"title":90,"searchDepth":91,"depth":91,"links":170},[171,172,173,174,175,176],{"id":123,"depth":91,"text":123},{"id":129,"depth":91,"text":129},{"id":135,"depth":91,"text":135},{"id":141,"depth":91,"text":141},{"id":147,"depth":91,"text":147},{"id":153,"depth":91,"text":153},"工具评测","2025-09-20","两个统计工具口径天生不同，差 20% 到 40% 都正常。我们做过一次完整对账，差异集中在时区、过滤规则、会话归因和站内引流四个地方，查完就不用再纠结谁在说谎。",{},"\u002Fblog\u002Fbaidu-tongji-vs-ga4-diff",{"title":115,"description":179},"blog\u002Fbaidu-tongji-vs-ga4-diff",[185,186,187],"百度统计","GA4","数据口径","6ytRWfa-wJoyzx9q6AYF-UwBp6xdkRWjnZLY5A4zCTU",{"id":190,"title":191,"author":6,"body":192,"canonical":97,"category":331,"cover":97,"date":332,"description":333,"draft":101,"extension":102,"keywords":97,"meta":334,"navigation":104,"noindex":101,"ogImage":97,"path":335,"seo":336,"seoDescription":97,"seoTitle":97,"stem":337,"tags":338,"updated":97,"__hash__":342},"blog\u002Fblog\u002Flongtail-keyword-scoring.md","长尾词别按搜索量排序，我们改按四个维度打分",{"type":8,"value":193,"toc":324},[194,197,200,203,206,209,212,215,284,287,291,294,297,300,303,306,309,312,315,318,321],[11,195,196],{},"月搜 30 的词我们写，月搜 5000 的词我们不写。不是反着来，是把四个维度分开打分之后，搜索量的权重只剩 10 分。",[15,198,199],{"id":199},"四个维度",[11,201,202],{},"意图给 40 分：这个搜索有没有采购或选型信号。带“怎么选”“对比”“替代”的接近满分，带“是什么”的给 10 分。",[11,204,205],{},"空位给 30 分：搜这个词，前十有几个是同行官网，有几个是点评站和论坛。官网占不到三个，给满分。",[11,207,208],{},"承接给 20 分：我们有没有现成页面能接这个词。没有落地页的先扣 10 分，逼自己先把页面做出来。",[11,210,211],{},"搜索量给 10 分：300 到 500 给满分，超过 5000 反而扣分，因为那种词我们一年也打不上去。",[15,213,214],{"id":214},"一张打分卡长什么样",[216,217,218,243],"table",{},[219,220,221],"thead",{},[222,223,224,228,231,234,237,240],"tr",{},[225,226,227],"th",{},"词",[225,229,230],{},"意图",[225,232,233],{},"空位",[225,235,236],{},"承接",[225,238,239],{},"量",[225,241,242],{},"总分",[244,245,246,267],"tbody",{},[222,247,248,252,255,258,261,264],{},[249,250,251],"td",{},"接口监控怎么做告警降噪",[249,253,254],{},"34",[249,256,257],{},"27",[249,259,260],{},"20",[249,262,263],{},"8",[249,265,266],{},"89",[222,268,269,272,274,277,279,282],{},[249,270,271],{},"免费代码托管平台",[249,273,263],{},[249,275,276],{},"5",[249,278,276],{},[249,280,281],{},"2",[249,283,260],{},[11,285,286],{},"第二行那个词月搜 5400，第一行月搜 90。按总分排，第一行先写。",[15,288,290],{"id":289},"搜索量只给-10-分的原因","搜索量只给 10 分的原因",[11,292,293],{},"2024 年我们按搜索量给一个开发工具客户排了 30 个选题，前 10 个全是搜索量最大的词。写了六个月，9 个没进过前 30 名。",[11,295,296],{},"那些词的前十名是站点级别的信息聚合页，我们一篇博客挤不进去。同时期顺手写的几个小词，三个月就排到第一，带来 40 多个试用申请。",[11,298,299],{},"搜索量告诉你这个池塘有多大，不告诉你鱼在不在你这半边。",[15,301,302],{"id":302},"打分卡的两个副作用",[11,304,305],{},"一个副作用是会砍掉很多看起来不错的词。词表从 800 个压到 120 个，客户第一反应是“这么点够写吗”。够写十个月。",[11,307,308],{},"另一个副作用是分数要重算。每季度重跑一次，竞争格局变了，分数就跟着变。我们有过一个词从 82 分掉到 41 分，因为两家同行开始认真做那篇内容。",[15,310,311],{"id":311},"打分是手算还是建表",[11,313,314],{},"前 50 个词我们手算，Word 里拉个表，半小时。超过 100 个词就得上表格，公式不用复杂，四个加权列加一列总分够用。",[11,316,317],{},"2025 年 5 月我们把这套表塞进客户的飞书多维表格，周会上直接按总分行排序，谁写的谁认领。一个月之后，客户自己开始改权重——把承接分提到 25，因为他发现自己更缺的是落地页，不是文章。",[11,319,320],{},"打分卡不是标准答案。但它把“我觉得这个词好”变成了可以拿出来对账的东西。",[11,322,323],{},"后来我自己的习惯是：每周一上午花 40 分钟把新词丢进表里打分，分数低的直接删，不留悬念。选题会从此少了一半争吵，也少了很多“这篇是不是可以再等等”的犹豫。",{"title":90,"searchDepth":91,"depth":91,"links":325},[326,327,328,329,330],{"id":199,"depth":91,"text":199},{"id":214,"depth":91,"text":214},{"id":289,"depth":91,"text":290},{"id":302,"depth":91,"text":302},{"id":311,"depth":91,"text":311},"SEO","2025-09-23","我们把长尾词拆成四个维度打分，给搜索量的权重只有 10 分。改完之后选题结果变了：月搜 30 的词排进计划，月搜 5000 的词被砍掉，这不是勇敢，是算过账。",{},"\u002Fblog\u002Flongtail-keyword-scoring",{"title":191,"description":333},"blog\u002Flongtail-keyword-scoring",[339,340,341],"长尾词","关键词优先级","内容排期","aKuXjPNF9gqpH9mfVkDr1rUx1zEubvIhheP7SGV3mYs",1794088112208]