[{"data":1,"prerenderedAt":370},["ShallowReactive",2],{"blog-inp-long-task-sources":3,"blog-prev-inp-long-task-sources":104,"blog-next-inp-long-task-sources":271},{"id":4,"title":5,"author":6,"body":7,"canonical":88,"category":89,"cover":88,"date":90,"description":91,"draft":92,"extension":93,"keywords":88,"meta":94,"navigation":95,"noindex":92,"ogImage":88,"path":96,"seo":97,"seoDescription":88,"seoTitle":88,"stem":98,"tags":99,"updated":88,"__hash__":103},"blog\u002Fblog\u002Finp-long-task-sources.md","INP 高但不知道怎么改，先查这四类长任务占了多少","元析智能",{"type":8,"value":9,"toc":77},"minimark",[10,14,17,22,25,28,32,35,38,42,45,49,52,56,59,62,65,68,71,74],[11,12,13],"p",{},"INP 高，八成是主线程被长任务占住了。今年 9 月我们给 7 个软件站查过 INP，四类来源能解释其中 6 个：框架水合、输入处理器里的同步计算、第三方脚本抢线程、大列表一次性渲染。定位方法不复杂，打开 Performance 面板录一段真实操作，看 Interactions 和长任务轨道。",[11,15,16],{},"先把概念说清楚。INP 是 Interaction to Next Paint，2024 年 3 月正式替代 FID 成为 Core Web Vitals 的交互指标。它算的是用户每次点击、按键到界面画出下一帧的延迟，取整段会话里偏差最大的那次。FID 只算第一次输入的延迟，所以有些站 FID 一直很好看，换成 INP 立刻露馅。",[18,19,21],"h2",{"id":20},"第一类框架水合","第一类：框架水合",[11,23,24],{},"Next.js、Nuxt 这类站，HTML 出来了，JS 还没执行完，这段时间用户点任何东西都没反应。一个开发者工具站首屏水合占了 1.2 秒，用户在这段时间点了三次导航，INP 直接记了 780 毫秒。",[11,26,27],{},"查法：Performance 面板里找 hydrate 或者 long task，看它和用户首次点击的时间关系。改法不是优化水合本身，而是让首屏不依赖 JS——导航用原生链接，首屏内容服务端渲染，交互组件按需加载。",[18,29,31],{"id":30},"第二类输入处理器里的同步计算","第二类：输入处理器里的同步计算",[11,33,34],{},"筛选、搜索、表单校验是重灾区。一个 B2B 后台的筛选器，每次点击同步算 1200 行数据的匹配，主线程卡 300 毫秒。用户连续点两下，感受就是卡死。",[11,36,37],{},"改法：把计算挪出事件处理器，用 requestAnimationFrame 或 startTransition 分帧；列表超过 200 行就上虚拟滚动。这类改动通常能砍掉一半的 INP。",[18,39,41],{"id":40},"第三类第三方脚本抢主线程","第三类：第三方脚本抢主线程",[11,43,44],{},"热力图、AB 测试、客服组件，都喜欢在用户第一次交互时上报。我们见过一个站，点击后 180 毫秒内跑了 4 个第三方回调。查法是 Performance 面板里看长任务下面挂的脚本 URL，一眼能认出是谁。",[18,46,48],{"id":47},"第四类大列表和复杂-dom","第四类：大列表和复杂 DOM",[11,50,51],{},"一次渲染 500 个 DOM 节点，浏览器光做样式计算就要 100 多毫秒。文档页的侧边目录、定价页的对比表都是高发区。改法是分页、虚拟滚动、content-visibility。",[18,53,55],{"id":54},"查-inp-的顺序","查 INP 的顺序",[11,57,58],{},"先看 RUM 的 P75 和 P95，差距大说明问题集中在少数交互上，找到那个元素比全局优化划算。再去实验室复现，最后才动手改。我们一般先修 P95 最差的那个交互，因为它往往和其他问题同根。",[18,60,61],{"id":61},"怎么归因到具体元素",[11,63,64],{},"实验室只能看到\"主线程卡了多久\"，看不到\"用户点了哪个按钮\"。要归因到元素，得在代码里埋一条 Interaction 记录：用 PerformanceObserver 监听 event 和 first-input，把 duration 超过 200 毫秒的交互连同比元素信息和页面路径一起上报。我们给客户搭的版本一天收上来十几万条，按页面聚合，最差的那个页面和按钮十分钟内就能锁定。",[11,66,67],{},"这一条比分数本身有用。分数只告诉你\"差\"，归因告诉你\"改哪里\"。",[18,69,70],{"id":70},"移动端是重灾区",[11,72,73],{},"同一个站，桌面端 INP 120 毫秒、移动端 380 毫秒，在我们查过的站里是常态。中低端安卓机的单核性能只有开发机的五分之一，脚本解析和执行的时间都要乘上去。所以 INP 的验收一定要看移动端，尤其是国内安卓机型的分布。",[11,75,76],{},"还有一条边界：INP 低于 200 毫秒就别折腾了。这类改动风险高、验收难，收益已经不明显，把时间花在内容和转化上更划算。",{"title":78,"searchDepth":79,"depth":79,"links":80},"",2,[81,82,83,84,85,86,87],{"id":20,"depth":79,"text":21},{"id":30,"depth":79,"text":31},{"id":40,"depth":79,"text":41},{"id":47,"depth":79,"text":48},{"id":54,"depth":79,"text":55},{"id":61,"depth":79,"text":61},{"id":70,"depth":79,"text":70},null,"技术SEO","2025-10-08","查过 7 个软件站的 INP，四类长任务能解释其中 6 个：框架水合、输入处理器里的同步计算、第三方脚本抢线程、大列表一次渲染。附带定位方法和每类的改法，附实测数字。",false,"md",{},true,"\u002Fblog\u002Finp-long-task-sources",{"title":5,"description":91},"blog\u002Finp-long-task-sources",[100,101,102],"INP","交互延迟","长任务","z1Tf2GoNpNNz5tdk0UJax9AObIhacvt27Xs52lQm7_g",{"id":105,"title":106,"author":6,"body":107,"canonical":88,"category":89,"cover":88,"date":261,"description":262,"draft":92,"extension":93,"keywords":88,"meta":263,"navigation":95,"noindex":92,"ogImage":88,"path":264,"seo":265,"seoDescription":88,"seoTitle":88,"stem":266,"tags":267,"updated":88,"__hash__":270},"blog\u002Fblog\u002Fcanonical-vs-301-vs-noindex.md","同一内容多个地址，canonical 和 301 怎么分工",{"type":8,"value":108,"toc":253},[109,112,115,182,185,207,213,216,229,232,235,238,241,244,247,250],[11,110,111],{},"这三个东西经常被当成\"让页面消失\"的三种说法，其实意图完全不同。canonical 是\"两个 URL 都保留，但请把主版本记在账上\"；301 是\"旧地址永久作废，内容搬家了\"；noindex 是\"页面给人看，但别进搜索结果\"。选错了不会立刻报错，只会慢慢损耗。",[18,113,114],{"id":114},"一张对照表",[116,117,118,134],"table",{},[119,120,121],"thead",{},[122,123,124,128,131],"tr",{},[125,126,127],"th",{},"你的诉求",[125,129,130],{},"该用",[125,132,133],{},"用错的代价",[135,136,137,149,160,171],"tbody",{},[122,138,139,143,146],{},[140,141,142],"td",{},"同一内容有参数、排序、追踪等变体",[140,144,145],{},"canonical",[140,147,148],{},"用 301 会让带参数的分享链接失效",[122,150,151,154,157],{},[140,152,153],{},"老 URL 永久废弃，内容已迁移",[140,155,156],{},"301",[140,158,159],{},"用 canonical 等于告诉蜘蛛两个地址都还行，老页继续占预算",[122,161,162,165,168],{},[140,163,164],{},"页面要留给人看，不进搜索",[140,166,167],{},"noindex",[140,169,170],{},"用 robots 屏蔽会让 spider 读不到 noindex，且内链传不出去",[122,172,173,176,179],{},[140,174,175],{},"内容彻底删除，不留替代",[140,177,178],{},"404 \u002F 410",[140,180,181],{},"挂 301 到首页会被判软 404",[18,183,184],{"id":184},"一个真实的产品页",[11,186,187,188,192,193,192,196,199,200,203,204,206],{},"2025 年 9 月，一个数据平台客户的产品页有四个地址：",[189,190,191],"code",{},"\u002Fpricing","、",[189,194,195],{},"\u002Fpricing?plan=team",[189,197,198],{},"\u002Fpricing\u002F","，还有大小写混写的 ",[189,201,202],{},"\u002FPricing","。他们之前用 301 把所有变体都跳到 ",[189,205,191],{},"，结果市场部发出去的短链、客服给客户复制的链接全被弹回，客服每天接到链接打不开的投诉 6 起。",[11,208,209,210,212],{},"改成 canonical 集中到 ",[189,211,191],{},"，四个地址都能正常打开，主版本三周内排名从第 7 位回到第 3 位。同一个内容、同一批关键词，之前一直上不去，就是因为权重被四个地址分着。",[18,214,215],{"id":215},"混用会出什么事",[217,218,219,223,226],"ul",{},[220,221,222],"li",{},"canonical 指向一个还在 301 的地址，蜘蛛要多跳一次，最后可能两边都不认。",[220,224,225],{},"同时写 noindex 和 canonical，等于给两个相反的指令，搜索引擎一般按 noindex 处理，但会降低对这个站配置的信任。",[220,227,228],{},"robots.txt 屏蔽 + canonical，spider 读不到 canonical，屏蔽就变成纯粹的信息损失。",[18,230,231],{"id":231},"我们的判断标准",[11,233,234],{},"内容还在、只是形态重复，用 canonical；内容真的搬走了，用 301，不要长期用 canonical 吊着老地址；页面必须给人访问但不想被搜到，用 noindex，并且保留它原有的内链，别让链接断掉。",[11,236,237],{},"还有一条：能用 301 解决的永久迁移，别偷懒写 canonical。301 是一次性动作，canonical 是长期声明，后者需要每次改版都记得维护。",[18,239,240],{"id":240},"怎么验证有没有用混",[11,242,243],{},"拿一个星期做一次抽查就够了。第一步，用 Screaming Frog 跑全站，导出每个页面的状态码和 canonical 列，筛出\"canonical 指向的 URL 本身返回 3xx\"的记录，这类是典型混用。第二步，筛出\"页面是 200 但 canonical 指向别的域名\"的记录，跨域 canonical 只在内容分发场景下成立，产品页出现就是配置错误。第三步，把 GSC 索引报告里\"网页会自动重定向\"和\"备用网页（有适当的规范标记）\"两类数量拉出来对比，如果重定向类明显偏多，说明本该用 301 的地方也在用 canonical。",[11,245,246],{},"三步做完通常能捞出一二十个问题页。修的时候按流量排序，先修有排名的那些，别从首页开始。",[18,248,249],{"id":249},"一个边界",[11,251,252],{},"canonical 不是垃圾桶。如果一个地址将来要独立运营、要拿自己的排名，就别把它 canonical 掉。内容相同才合并，只是相关不算重复。",{"title":78,"searchDepth":79,"depth":79,"links":254},[255,256,257,258,259,260],{"id":114,"depth":79,"text":114},{"id":184,"depth":79,"text":184},{"id":215,"depth":79,"text":215},{"id":231,"depth":79,"text":231},{"id":240,"depth":79,"text":240},{"id":249,"depth":79,"text":249},"2025-10-07","三个手段被混用，是因为没分清\"内容重复\"\"永久搬家\"\"不想被收录\"。我们用一张对照表和 2025 年 9 月一个产品页的案例，讲清各自管什么，以及混用的代价。",{},"\u002Fblog\u002Fcanonical-vs-301-vs-noindex",{"title":106,"description":262},"blog\u002Fcanonical-vs-301-vs-noindex",[145,268,269],"重定向","重复内容","o6JyiVYo_zYeIHrO6CkniGj9Kdaw7VLb2ESng6q9vqY",{"id":272,"title":273,"author":6,"body":274,"canonical":88,"category":358,"cover":88,"date":359,"description":360,"draft":92,"extension":93,"keywords":88,"meta":361,"navigation":95,"noindex":92,"ogImage":88,"path":362,"seo":363,"seoDescription":88,"seoTitle":88,"stem":364,"tags":365,"updated":88,"__hash__":369},"blog\u002Fblog\u002Fsolo-writer-yearly-plan.md","一个人一年写 50 篇，我们的选题和排期是这么排的",{"type":8,"value":275,"toc":349},[276,279,282,285,288,292,295,298,301,304,307,310,313,316,319,322,325,328,331,334,337,340,343,346],[11,277,278],{},"一个人一年写 50 篇，靠的不是写得更快，是提前半年把选题排成表，每周只剩一件确定的事：把当周那篇写完。2025 年我们这个内容岗是 1.5 个人，全年发了 48 篇，平均每篇 2.5 个工作日，没有一次为了赶发布熬到半夜。",[18,280,281],{"id":281},"排期表只有三列",[11,283,284],{},"季度主题、双周选题、发布日。第一列决定我们这三个月在讲哪一类问题，第二列是具体标题，第三列写死到某天，我们固定在周二或周四发。",[11,286,287],{},"三列之外不写别的。计划写到“几点发、配几张图”这种颗粒度，最后一定执行不下去。",[18,289,291],{"id":290},"选题一次定-12-周","选题一次定 12 周",[11,293,294],{},"每季度最后一周开一次选题会，90 分钟，定下个季度 12 周的 12 个题。定完不再改，除非词表里出现明显更强的机会。",[11,296,297],{},"12 个题里留 2 个空位，专门给临时冒出来的东西。不留空位的话，只要客户临时提一个要求，整张表就散了。",[18,299,300],{"id":300},"一周的时间怎么分",[11,302,303],{},"周一半天查资料和读竞品，周二上午写 4 小时出初稿，周三补图改稿并给同事看一遍，周四发布。剩下一天处理临时的事、回复客户、看数据。",[11,305,306],{},"写初稿那 4 小时不开会、不回消息。我试过拆成两个小时两段，质量明显更差，第二天基本要重写。",[18,308,309],{"id":309},"永远提前三篇",[11,311,312],{},"发布队列里始终压着 3 篇已经写完的稿子。出差、生病、临时项目都不影响发布节奏。",[11,314,315],{},"这个缓冲是我交了学费才建的。2025 年 6 月我病了一周，博客断更两周，再恢复时流量掉了 18%，用了将近两个月才回来。",[18,317,318],{"id":318},"不做的三件事",[11,320,321],{},"不追热点。软件行业的所谓热点，一周后就没人搜了，写它挤占的是排期里的位置。",[11,323,324],{},"不接一句话临时选题，除非它能进表。能进表说明它有位置，进不了表说明不急。",[11,326,327],{},"不为周更硬写。宁可发 3 篇有数据的，不发 5 篇凑数的，这是我们 2025 年最确定的一条。",[18,329,330],{"id":330},"排期表用什么工具",[11,332,333],{},"飞书多维表格或者 Notion 都行，我们用的是最简单的表格：一行一个题，七列。太复杂的项目管理工具坚持不到第三个月。",[11,335,336],{},"表里有一列叫“素材状态”，写着差什么资料。没有这列，写稿时你会发现一半时间花在找截图和问客户上。",[18,338,339],{"id":339},"一年之后回头看",[11,341,342],{},"48 篇里真正带来询盘的是 11 篇，其中 9 篇是“场景加问题”型，2 篇是对比型。学习类的内容只带来了流量，没带来销售对话。",[11,344,345],{},"这个结果让我把 2026 年的排期改了比例：学习类从 30% 压到 15%，场景类提到 50%。如果你们也在做年度计划，这个比例可以直接拿去用。",[11,347,348],{},"一个人写不完不是产能问题，是选题没提前定。定完之后，剩下的只是坐下去写。",{"title":78,"searchDepth":79,"depth":79,"links":350},[351,352,353,354,355,356,357],{"id":281,"depth":79,"text":281},{"id":290,"depth":79,"text":291},{"id":300,"depth":79,"text":300},{"id":309,"depth":79,"text":309},{"id":318,"depth":79,"text":318},{"id":330,"depth":79,"text":330},{"id":339,"depth":79,"text":339},"内容运营","2025-10-09","一个人写 50 篇不靠写得更快，靠提前半年把选题排成表。我们 1.5 个人一年发 48 篇，平均每篇 2.5 天，每周只做一件确定的事：把当周那篇写完。",{},"\u002Fblog\u002Fsolo-writer-yearly-plan",{"title":273,"description":360},"blog\u002Fsolo-writer-yearly-plan",[366,367,368],"内容排期","选题机制","小团队","Yhgd4Upnzg_Aekd-EPKRh9vxVh_YfUj3h9dbchcdYIc",1794088111795]