[{"data":1,"prerenderedAt":352},["ShallowReactive",2],{"blog-inp-common-questions":3,"blog-prev-inp-common-questions":138,"blog-next-inp-common-questions":254},{"id":4,"title":5,"author":6,"body":7,"canonical":122,"category":123,"cover":122,"date":124,"description":125,"draft":126,"extension":127,"keywords":122,"meta":128,"navigation":129,"noindex":126,"ogImage":122,"path":130,"seo":131,"seoDescription":122,"seoTitle":122,"stem":132,"tags":133,"updated":122,"__hash__":137},"blog\u002Fblog\u002Finp-common-questions.md","INP 是什么、怎么测、怎么改：客户最常问的八个问题","元析智能",{"type":8,"value":9,"toc":114},"minimark",[10,14,18,24,27,32,35,40,43,46,51,54,59,62,67,70,73,78,81,86,89,94,97,102,105,108,111],[11,12,13],"p",{},"INP 是 Core Web Vitals 里最容易被误解的指标，因为它不像 LCP 那样有一个\"看得见的元素\"。下面是我们被客户问得最多的八个问题，答案尽量短。",[15,16,17],"h2",{"id":17},"定义和阈值",[11,19,20],{},[21,22,23],"strong",{},"Q：INP 到底测什么？",[11,25,26],{},"用户每次交互（点击、按键、触摸）到浏览器画出下一帧的延迟，取整个会话里偏差最大的那次作为分数。它衡量页面响应快不快。",[11,28,29],{},[21,30,31],{},"Q：多少算合格？",[11,33,34],{},"低于 200 毫秒算好，200 到 500 毫秒需要改进，超过 500 毫秒算差。和 LCP 一样，要求 75% 的用户访问达标。",[11,36,37],{},[21,38,39],{},"Q：它和 FID 什么关系？",[11,41,42],{},"FID 是旧指标，2024 年 3 月被 INP 替代。FID 只看第一次输入，而且只算输入延迟不算渲染，所以经常一片绿。INP 看所有交互，包含处理耗时和下一帧渲染耗时，严格得多。",[15,44,45],{"id":45},"怎么测",[11,47,48],{},[21,49,50],{},"Q：为什么 PageSpeed 测出来和客户说的不一样？",[11,52,53],{},"PageSpeed 的 INP 是实验室模拟，很多交互它触发不了，有时直接显示无数据。要看真实情况，用 GSC 的 Core Web Vitals 报告或 CrUX。",[11,55,56],{},[21,57,58],{},"Q：移动端为什么普遍比桌面差？",[11,60,61],{},"CPU 性能差，加上主线程任务没有为低端机优化。同一段 JS 在开发机上 30 毫秒，在四年前的中端安卓上就是 200 毫秒。",[11,63,64],{},[21,65,66],{},"Q：有没有必要自己搭 RUM？",[11,68,69],{},"访问量超过每天一千就建议搭。web-vitals 库加一个上报接口，半天能上线。实验室数据只能定位方向，验收必须靠自己的真实数据。",[15,71,72],{"id":72},"怎么改",[11,74,75],{},[21,76,77],{},"Q：改哪里收益最大？",[11,79,80],{},"按我们的经验排序：去掉事件处理器里的同步重活、列表虚拟化、第三方脚本延后、减少首屏水合。这四项能覆盖大多数站。",[11,82,83],{},[21,84,85],{},"Q：加服务器有用吗？",[11,87,88],{},"基本没用。INP 是浏览器主线程的问题，服务器再快，JS 还是要在用户设备上跑。带宽和机器解决 LCP 和 TTFB，解决不了交互。",[11,90,91],{},[21,92,93],{},"Q：改完多久能看到指标变化？",[11,95,96],{},"真实用户数据一般要两到四周才稳定。INP 取的是偏差最大的那次交互，样本量不够的时候波动很大。我们有个客户改完第三天看数据反而变差了，第二周才回落到 180 毫秒。别用三天的数据下结论。",[11,98,99],{},[21,100,101],{},"Q：能不能只改最慢的那个交互？",[11,103,104],{},"可以，而且往往是性价比最高的做法。INP 的分数由少数极差交互决定，修好 P95 那一个交互，整站分数就能上一个台阶。前提是你得先知道是哪一个，这就要有能归因到元素的 RUM。",[15,106,107],{"id":107},"补一句",[11,109,110],{},"INP 有个天然缺陷：它只统计交互延迟，不统计\"用户想点但没有可点元素\"的时间。按钮灰着、加载中不能操作，这些体验问题不会进 INP。所以别把 INP 当体验的全部，它只是一个及格线。",[11,112,113],{},"我们的做法是把 INP 和两个自建指标放一起看：首次可交互时间、关键操作完成时间。三个数一起看，才不容易被漂亮的单项分数骗过去。",{"title":115,"searchDepth":116,"depth":116,"links":117},"",2,[118,119,120,121],{"id":17,"depth":116,"text":17},{"id":45,"depth":116,"text":45},{"id":72,"depth":116,"text":72},{"id":107,"depth":116,"text":107},null,"技术SEO","2025-11-01","INP 是替代 FID 的交互指标，200 毫秒合格、500 毫秒算差。八个高频问题：阈值、和 FID 区别、移动端为什么更差、PSI 为什么测不出、加服务器有没有用、多久见效。",false,"md",{},true,"\u002Fblog\u002Finp-common-questions",{"title":5,"description":125},"blog\u002Finp-common-questions",[134,135,136],"INP","问答","Core Web Vitals","522k-jzEwKKosFlHmpbLJLKkw62jUa1ys0fCETNMh6s",{"id":139,"title":140,"author":6,"body":141,"canonical":122,"category":123,"cover":122,"date":244,"description":245,"draft":126,"extension":127,"keywords":122,"meta":246,"navigation":129,"noindex":126,"ogImage":122,"path":247,"seo":248,"seoDescription":122,"seoTitle":122,"stem":249,"tags":250,"updated":122,"__hash__":253},"blog\u002Fblog\u002Furl-naming-rules-software.md","软件公司 URL 怎么起名，我们的 6 条规矩",{"type":8,"value":142,"toc":234},[143,146,150,161,165,182,186,192,196,202,206,209,213,216,219,222,225,231],[11,144,145],{},"URL 不是技术细节，是内容资产。三年后它还要出现在你的 API 文档、客户邮件、微信群里。改一次的成本远高于起名时多想十分钟。下面 6 条是我们给软件公司定 URL 规矩时最常用的。",[15,147,149],{"id":148},"_1-全小写短横线分隔","1. 全小写，短横线分隔",[11,151,152,156,157,160],{},[153,154,155],"code",{},"\u002Fdocs\u002Fapi-rate-limit"," 对，",[153,158,159],{},"\u002FDocs\u002FAPI_RateLimit"," 错。大小写混写和下滑线不会让页面打不开，但会让同一个页面出现两个地址，多一层重复内容要处理。",[15,162,164],{"id":163},"_2-用英文关键词不要拼音不要数字-id","2. 用英文关键词，不要拼音、不要数字 ID",[11,166,167,156,170,173,174,177,178,181],{},[153,168,169],{},"\u002Fproducts\u002Fdata-sync",[153,171,172],{},"\u002Fproduct\u002F12345","、",[153,175,176],{},"\u002Fchanpin\u002Fshujutongbu"," 错。数字 ID 对搜索引擎和用户都没有信息量；拼音对英文搜索没有帮助，对海外用户不可读。软件公司的产品名如果是自造词，就把功能词放进去，比如 ",[153,179,180],{},"\u002Fproducts\u002Fedge-cache","。",[15,183,185],{"id":184},"_3-层级不超过四层","3. 层级不超过四层",[11,187,188,191],{},[153,189,190],{},"\u002Fdocs\u002Fapi\u002Frate-limit"," 够了。再往下一层，点击深度和抓取效率都会变差。语言和版本不要塞进路径主层级，宁可放子域或参数。",[15,193,195],{"id":194},"_4-版本号别进主路径","4. 版本号别进主路径",[11,197,198,201],{},[153,199,200],{},"\u002Fdocs\u002Fv2\u002Frate-limit"," 会让每个版本变成一批独立页面，升级大版本时整批 301。2025 年 3 月一个 API 工具站把 v2 挪到主路径，1800 个文档页全换了 URL，三个月排名都没回到原来的位置。建议路径保持稳定，版本用页面内切换，旧版单独放一个归档区。",[15,203,205],{"id":204},"_5-参数只留功能性的","5. 参数只留功能性的",[11,207,208],{},"筛选、排序、分页参数可以存在，但要配 canonical 或 robots 规则处理。追踪参数（utm 那一堆）不要出现在可索引的链接里，服务端能拦就拦。参数越多，重复内容治理越麻烦。",[15,210,212],{"id":211},"_6-改了就必须-301","6. 改了就必须 301",[11,214,215],{},"URL 一改，旧地址 301 到新地址，sitemap 同步更新，站内链接一次性替换干净。别留旧链接挂着 404，也别让两个地址同时可访问。",[15,217,218],{"id":218},"改名的操作顺序",[11,220,221],{},"已经上线的 URL 要改，顺序别乱：先盘点旧 URL 和流量（GSC 里按点击排序，取前 200 个），再定新 URL 规则，然后写 301 映射表并上线，同时改站内链接和 sitemap，最后在 GSC 提交改版。这个客户改 800 个 URL 用了三天，映射表核对占了两天，上线本身半小时。上线后前两周流量会掉 10% 到 20%，属于正常波动，别急着回滚。",[15,223,224],{"id":224},"一个反例",[11,226,227,230],{},[153,228,229],{},"\u002Fblog\u002F2025\u002F03\u002F12\u002Fseo-tips"," 这种带日期的路径，除非你真的按时间归档，否则别用。用户和蜘蛛都会觉得旧文章过期，日历层级又多两层。我们给客户改版时，带日期的博客路径是最常被顺手收拾的一类。",[11,232,233],{},"起名的时候把 URL 念一遍，看能不能在电话里说清楚。念不清的，重起。",{"title":115,"searchDepth":116,"depth":116,"links":235},[236,237,238,239,240,241,242,243],{"id":148,"depth":116,"text":149},{"id":163,"depth":116,"text":164},{"id":184,"depth":116,"text":185},{"id":194,"depth":116,"text":195},{"id":204,"depth":116,"text":205},{"id":211,"depth":116,"text":212},{"id":218,"depth":116,"text":218},{"id":224,"depth":116,"text":224},"2025-10-31","URL 是会被写进文档、发到群里的长期资产，改一次成本极高。这 6 条规矩来自我们改过的三万多条软件站 URL：全小写、短横线、能看出内容、不随版本变、改了必须 301。",{},"\u002Fblog\u002Furl-naming-rules-software",{"title":140,"description":245},"blog\u002Furl-naming-rules-software",[251,252,123],"URL设计","站点结构","gKD3HPdkPazEvttQVeqFrANB7XHDD0cFy85m6dJajBA",{"id":255,"title":256,"author":6,"body":257,"canonical":122,"category":340,"cover":122,"date":341,"description":342,"draft":126,"extension":127,"keywords":122,"meta":343,"navigation":129,"noindex":126,"ogImage":122,"path":344,"seo":345,"seoDescription":122,"seoTitle":122,"stem":346,"tags":347,"updated":122,"__hash__":351},"blog\u002Fblog\u002Fold-post-rewrite-judgment.md","旧文翻新前先判断：这篇到底值不值得重写",{"type":8,"value":258,"toc":331},[259,262,266,269,272,276,279,282,286,289,292,295,298,301,304,307,310,313,316,319,322,325,328],[11,260,261],{},"旧文翻新最大的浪费，是把一篇救不回来的文章改了三个版本。我们的做法是先判断，再动手。2025 年 9 月整理了一批 40 篇 2023 年到 2024 年的老文，判断下来只重写 12 篇，8 周后其中 9 篇回到前 20 名，剩下 28 篇里 19 篇合并、9 篇删除。",[15,263,265],{"id":264},"第一个问题还有搜索需求吗","第一个问题：还有搜索需求吗",[11,267,268],{},"翻出这个页面最近 12 个月的曝光和点击。曝光持续下滑到接近 0 的，先别改，去查关键词还在不在被搜。",[11,270,271],{},"有时候不是文章不行，是那个词没人搜了。产品功能改名、行业换说法、用户改用英文缩写，这些都会让一个词直接消失。需求没了，重写就是白写。",[15,273,275],{"id":274},"第二个问题有没有排名基础","第二个问题：有没有排名基础",[11,277,278],{},"看这个 URL 现在排在多少名，有没有外链，收录了多久。",[11,280,281],{},"排在前 30 名以内、有一两个外链的，值得救。排在 100 名开外、零外链的，其实等于新写一篇，成本一样，收益更低。",[15,283,285],{"id":284},"第三个问题原文有没有独家内容","第三个问题：原文有没有独家内容",[11,287,288],{},"翻一遍原文，找那些只能从我们这里得到的东西：实测数据、客户场景、内部截图、踩坑记录。",[11,290,291],{},"一条都没有的，弃掉。这种文章重写之后还是跟同行一个样，问题不在文字，在信息存量。",[15,293,294],{"id":294},"决定重写的怎么改",[11,296,297],{},"URL 不动，标题里的核心词不动，正文重排：结论前置，补近两年的数据，加作者署名和更新日期。",[11,299,300],{},"结构上砍掉一半。老文普遍太啰嗦，2023 年那批平均 3200 字，重写后压到 1800 字左右，可读性和抓取效率都更好。",[15,302,303],{"id":303},"一个反常识的观察",[11,305,306],{},"排名下滑最厉害的那批文章，问题往往不在内容质量，在搜索结果页本身变了。搜同样的词，前十多了文档站、视频和问答，你一篇博客挤不进去。",[11,308,309],{},"这种时候该做的不是翻新，是换页面类型：写文档页、做视频、或者把内容搬到能排上去的载体上。我们 2025 年就干过这事，把 6 篇博客改成了产品文档，流量回来了七成。",[15,311,312],{"id":312},"多久做一次",[11,314,315],{},"我们按季度做，每次只看两类：最近 12 个月曝光下滑超过 50% 的，和排名在 11 到 30 名之间卡住的。前一类救，后一类推。",[11,317,318],{},"一次看 30 到 50 篇，两三个小时能出结论。攒到几百篇一起看，判断质量一定下降。",[15,320,321],{"id":321},"重写之后怎么观察",[11,323,324],{},"发布后第 14 天看是否重新被收录，第 28 天看曝光，第 56 天看排名。三周没收录，先查是不是被 noindex 或者被砍了内链。",[11,326,327],{},"我们自己的一个规律是：重写后曝光恢复通常比排名快两到三周。曝光起来了排名不动，说明内容对了但页面权重不够，该补内链而不是继续改稿。",[11,329,330],{},"翻新不是改字，是给这篇内容换一个能打的版本。",{"title":115,"searchDepth":116,"depth":116,"links":332},[333,334,335,336,337,338,339],{"id":264,"depth":116,"text":265},{"id":274,"depth":116,"text":275},{"id":284,"depth":116,"text":285},{"id":294,"depth":116,"text":294},{"id":303,"depth":116,"text":303},{"id":312,"depth":116,"text":312},{"id":321,"depth":116,"text":321},"内容运营","2025-11-02","翻新旧文先问三个问题：还有搜索需求吗、有没有排名基础、原文有没有别人没有的东西。40 篇老文里我们只重写了 12 篇，8 周后 9 篇回到前 20，其余直接删或并。",{},"\u002Fblog\u002Fold-post-rewrite-judgment",{"title":256,"description":342},"blog\u002Fold-post-rewrite-judgment",[348,349,350],"旧文翻新","内容更新","SEO复盘","jv6-BYvQEOmZQZ02WeVIXY2ClGoGx20kFtU10fn7xmg",1794088111182]