[{"data":1,"prerenderedAt":340},["ShallowReactive",2],{"blog-performance-budget":3,"blog-prev-performance-budget":126,"blog-next-performance-budget":238},{"id":4,"title":5,"author":6,"body":7,"canonical":110,"category":111,"cover":110,"date":112,"description":113,"draft":114,"extension":115,"keywords":110,"meta":116,"navigation":117,"noindex":114,"ogImage":110,"path":118,"seo":119,"seoDescription":110,"seoTitle":110,"stem":120,"tags":121,"updated":110,"__hash__":125},"blog\u002Fblog\u002Fperformance-budget.md","给页面定性能预算，超过就拦住不让上线","元析智能",{"type":8,"value":9,"toc":99},"minimark",[10,14,18,21,24,27,30,33,36,39,42,45,48,51,54,57,60,63,66,69,72,75,78,81,84,87,90,93,96],[11,12,13],"p",{},"2026 年 9 月我们给一个客户的官网加性能预算，第一次跑 CI 就拦下了两个提交：一个把 JS 包从 680KB 顶到 1.1MB，另一个加了四张大图。没有预算，这两件事在评审时都不会被发现。",[15,16,17],"h2",{"id":17},"为什么需要预算",[11,19,20],{},"性能是慢慢变差的。每次加一个脚本、一张图、一个统计工具，单独看都合理，加起来就超标了。",[11,22,23],{},"等到用户抱怨或者指标掉出合格线，已经很难回溯是哪个提交造成的。",[11,25,26],{},"预算就是在每次提交时设一道线，超过就得说清理由。",[15,28,29],{"id":29},"定哪四个数",[11,31,32],{},"第一个，首屏 JS 体积。我们的默认线是 300KB，压缩后。软件官网通常够用。",[11,34,35],{},"第二个，首屏图片总量。默认 500KB，超过就要换格式或者裁尺寸。",[11,37,38],{},"第三个，请求数。首屏不超过 40 个请求，超过多半是图标、字体、统计拆得太碎。",[11,40,41],{},"第四个，三个核心指标的实验室值。LCP 2.5 秒、INP 200 毫秒、CLS 0.1。",[15,43,44],{"id":44},"怎么落地",[11,46,47],{},"CI 里跑 Lighthouse CI，对核心页面测三次，取中位数，和预算比。",[11,49,50],{},"PR 里自动贴对比，说明哪个指标超了、超了多少。超过就阻塞合并，或者要求负责人写明原因。",[11,52,53],{},"我们通常给两个页面设门禁：首页和核心产品页。这两个页面决定了大部分流量和转化。",[15,55,56],{"id":56},"超了怎么办",[11,58,59],{},"先看是真超标还是误报。Lighthouse 波动大，一次超标可以重跑确认。",[11,61,62],{},"真超标就两条路：改回提交，或者调预算。调预算要有人批，而且要在 PR 里留下记录。",[11,64,65],{},"我们的规矩是预算每季度可以调一次，平时只降不升。",[15,67,68],{"id":68},"怎么跟不写代码的人解释",[11,70,71],{},"预算这个说法对业务方不直观。我们换个说法：这个页面在手机上打开不能超过三秒，超过就要改。",[11,73,74],{},"然后把目标和预算数字对应起来，让对方知道 300KB 的 JS 大概对应多少秒。",[11,76,77],{},"有了这个换算，评审时说这个库加进来会让首屏慢半秒，比说超过预算了有效得多。",[15,79,80],{"id":80},"一个真实的变化",[11,82,83],{},"2026 年 5 月预算上线前，这个站的 JS 从一年前的 400KB 涨到 1.2MB，没人说得清怎么涨的。",[11,85,86],{},"上了预算之后三个月，包体回落到 700KB 左右。不是做了大重构，是每次提交都被迫想一下这个依赖值不值。",[15,88,89],{"id":89},"一个态度",[11,91,92],{},"性能预算的本质是流程，不是技术。它把性能从上线后才发现的问题，变成提交前就要面对的问题。",[11,94,95],{},"没有流程，优化就是一阵风。做完一次冲进合格线，半年后又回到原点。",[11,97,98],{},"设定预算这件事，一个下午就能做完。真正难的是坚持执行，尤其是业务方催着上线的时候。",{"title":100,"searchDepth":101,"depth":101,"links":102},"",2,[103,104,105,106,107,108,109],{"id":17,"depth":101,"text":17},{"id":29,"depth":101,"text":29},{"id":44,"depth":101,"text":44},{"id":56,"depth":101,"text":56},{"id":68,"depth":101,"text":68},{"id":80,"depth":101,"text":80},{"id":89,"depth":101,"text":89},null,"技术SEO","2026-09-20","没有预算的站，JS 只会一年比一年多。这篇写预算定哪四个数、怎么在 CI 里落地、超了怎么办，以及我们给软件官网的默认阈值，一个下午就能配上。",false,"md",{},true,"\u002Fblog\u002Fperformance-budget",{"title":5,"description":113},"blog\u002Fperformance-budget",[122,123,124],"性能预算","前端工程","上线流程","UpePvQ3lvxowIQfMYlLg8RJ7ZrOvB8KjVdtHb44P5qI",{"id":127,"title":128,"author":6,"body":129,"canonical":110,"category":111,"cover":110,"date":227,"description":228,"draft":114,"extension":115,"keywords":110,"meta":229,"navigation":117,"noindex":114,"ogImage":110,"path":230,"seo":231,"seoDescription":110,"seoTitle":110,"stem":232,"tags":233,"updated":110,"__hash__":237},"blog\u002Fblog\u002Fnofollow-attributes-2026.md","nofollow 还有用吗：2026 年链接属性的正确用法",{"type":8,"value":130,"toc":218},[131,134,137,140,143,146,149,152,155,158,161,164,167,170,173,176,179,182,185,188,191,194,197,200,203,206,209,212,215],[11,132,133],{},"这三个链接属性被讨论了很多年，2026 年的实际作用已经很有限。我们的建议是：只在该用的地方用，别指望它们解决权重问题，也别把它们当惩罚工具。",[15,135,136],{"id":136},"三个属性的本意",[11,138,139],{},"nofollow：告诉搜索引擎\"这个链接不是我推荐的，别把权重传过去\"。",[11,141,142],{},"sponsored：标明是赞助或广告链接。",[11,144,145],{},"ugc：标明是用户生成内容里的链接，比如论坛、评论区。",[11,147,148],{},"2019 年 Google 把后两个当成\"提示\"而不是\"指令\"，nofollow 本身也从指令弱化成了提示。",[15,150,151],{"id":151},"现在还有没有用",[11,153,154],{},"有帮助，但没有想象中重要。",[11,156,157],{},"对内的作用：nofollow 可以用来控制抓取路径，减少蜘蛛进入无价值页面的次数。这个作用还在。",[11,159,160],{},"对外的作用：Google 会综合判断链接的可信度，不只看属性。一个 nofollow 链接如果被大量真实用户点击，它仍然可能被当成推荐信号。",[11,162,163],{},"百度的处理更简单：nofollow 基本会被尊重，但判断维度没那么多。",[15,165,166],{"id":166},"软件站最常误用的两处",[11,168,169],{},"第一处，把站内所有\"不重要\"的链接都加 nofollow。导航、页脚、侧边栏全 nofollow，结果蜘蛛的路径被切断，深层页面反而更难被发现。",[11,171,172],{},"我们的建议：站内链接尽量不加 nofollow，用 robots 或者 noindex 控制页面收录，别用 nofollow 切断路径。",[11,174,175],{},"第二处，给外链加 nofollow 表示\"我们没买链接\"。这没用。搜索引擎判断买卖链接看的是模式和来源，不是属性。加了 nofollow 的付费链接一样可能被识别。",[15,177,178],{"id":178},"我们的做法",[11,180,181],{},"站内：不加 nofollow。链接就是链接，路径要通畅。",[11,183,184],{},"友情链接和合作伙伴链接：如果是真实互链，正常链接；如果是付费或者交换，加 sponsored。",[11,186,187],{},"用户生成内容：评论区、论坛的链接加 ugc，这是规范用法。",[11,189,190],{},"广告位：加 sponsored，这个没有争议。",[15,192,193],{"id":193},"一个判断",[11,195,196],{},"链接属性是\"声明\"，不是\"开关\"。加不加，搜索引擎都会自己判断。",[11,198,199],{},"把精力从\"属性怎么配\"移到\"链接来源靠不靠谱\"，收益大得多。",[15,201,202],{"id":202},"一个反例",[11,204,205],{},"2026 年 2 月我们看过一个站，把页脚所有链接都加了 nofollow，包括产品、定价、文档这些核心页面。",[11,207,208],{},"他们的理由是\"页脚链接不算推荐\"。结果蜘蛛从首页进去，只能顺着导航爬到十几个页面，文档和博客基本发现不了。收录量两个月掉了 40%。",[11,210,211],{},"把 nofollow 去掉之后，三周恢复正常。这件事说明：站内链接不是\"推荐\"，是\"路径\"，别拿它当权重开关。",[15,213,214],{"id":214},"一句判断",[11,216,217],{},"2026 年做链接，重点在质量，不在属性。属性配得再标准，来源是垃圾站，一样没用。",{"title":100,"searchDepth":101,"depth":101,"links":219},[220,221,222,223,224,225,226],{"id":136,"depth":101,"text":136},{"id":151,"depth":101,"text":151},{"id":166,"depth":101,"text":166},{"id":178,"depth":101,"text":178},{"id":193,"depth":101,"text":193},{"id":202,"depth":101,"text":202},{"id":214,"depth":101,"text":214},"2026-09-19","这三个链接属性被讨论了很多年，2026 年的实际作用已经很有限。我们的建议是：只在该用的地方用，别指望它们解决权重问题，也别把它们当惩罚工具。软件站最常误用的两处和正确用法都在这篇，用错地方反而伤抓取。",{},"\u002Fblog\u002Fnofollow-attributes-2026",{"title":128,"description":228},"blog\u002Fnofollow-attributes-2026",[234,235,236],"链接属性","nofollow","外链","wl0-pXb1iUX3qBx8b5sm7lwIVBfAjxNqD-AVKUtk6m0",{"id":239,"title":240,"author":6,"body":241,"canonical":110,"category":329,"cover":110,"date":330,"description":331,"draft":114,"extension":115,"keywords":110,"meta":332,"navigation":117,"noindex":114,"ogImage":110,"path":333,"seo":334,"seoDescription":110,"seoTitle":110,"stem":335,"tags":336,"updated":110,"__hash__":339},"blog\u002Fblog\u002Fcontent-partnership.md","内容共创：和行业媒体、KOL 合作，写什么、怎么分工",{"type":8,"value":242,"toc":320},[243,246,249,252,255,258,261,264,267,270,273,276,279,282,285,288,291,294,297,300,303,306,309,312,314,317],[11,244,245],{},"内容共创不是找人转发。我们做过 12 次共创：联合报告、专家约稿、媒体专栏，效果差三倍，差别在选题和分工。",[15,247,248],{"id":248},"为什么做内容共创",[11,250,251],{},"三个好处：借对方的受众、借对方的可信度、分摊生产成本。",[11,253,254],{},"但共创做不好，就是互相发个稿、换个链接，没什么实际效果。我们前三次共创就是这样，白忙。",[15,256,257],{"id":257},"三种合作形式",[11,259,260],{},"第一种，联合报告。两家或多家一起做行业调研，联合署名发布。成本分摊，受众互补，可信度最高。",[11,262,263],{},"第二种，专家约稿。请行业专家、客户的技术负责人写稿，我们提供选题和编辑支持。信息增益高，但专家时间难约。",[11,265,266],{},"第三种，媒体专栏。在垂直媒体开专栏，定期供稿。稳定曝光，但内容要符合媒体调性，不能太硬广。",[15,268,269],{"id":269},"怎么分工",[11,271,272],{},"联合报告：一方出数据和案例，一方出调研和写作，共同审稿。署名和版权提前谈清楚。",[11,274,275],{},"专家约稿：我们定选题和结构，专家写核心观点和案例，我们做编辑和事实核查。",[11,277,278],{},"媒体专栏：媒体定调性和频率，我们出内容。标题和角度可以协商，但别硬塞产品。",[15,280,281],{"id":281},"怎么衡量效果",[11,283,284],{},"三个数：曝光（阅读、下载）、引用（外链、二次转载）、转化（留资、注册）。",[11,286,287],{},"我们的经验：联合报告的引用效果最好，专家约稿的转化最好，媒体专栏的曝光最稳。",[15,289,290],{"id":290},"一个失败的案例",[11,292,293],{},"2025 年 7 月，我们和一个行业媒体合作专栏，写了 6 篇。内容是通用的行业分析，没有独家数据，也没有产品关联。",[11,295,296],{},"结果：阅读量一般，外链为 0，转化几乎为 0。复盘发现：我们把专栏当成了\"发稿渠道\"，而不是\"内容合作\"。",[11,298,299],{},"后来改成：每篇专栏都带我们的独家数据，结尾链到一份深度报告。第二季度，专栏带来的下载量涨了 4 倍。",[15,301,302],{"id":302},"选题的三个标准",[11,304,305],{},"第一，对方受众关心。不是我们想说什么，是对方读者想看什么。",[11,307,308],{},"第二，我们有独家。数据、案例、经验，至少占一个。",[11,310,311],{},"第三，能承接。读者看完能做什么：下载报告、注册试用、关注专栏。",[15,313,214],{"id":214},[11,315,316],{},"内容共创的核心是\"互相增值\"，不是\"互相转发\"。没有独家内容的合作，做一次就够了，别做成常规。",[11,318,319],{},"找合作方的时候，先看对方的受众和我们重不重叠。重叠度 50% 到 80% 最好，太低没效果，太高是竞争。这件事我们每年复盘一次，合作方也在换。",{"title":100,"searchDepth":101,"depth":101,"links":321},[322,323,324,325,326,327,328],{"id":248,"depth":101,"text":248},{"id":257,"depth":101,"text":257},{"id":269,"depth":101,"text":269},{"id":281,"depth":101,"text":281},{"id":290,"depth":101,"text":290},{"id":302,"depth":101,"text":302},{"id":214,"depth":101,"text":214},"内容运营","2026-09-21","内容共创不是找人转发。我们做过 12 次共创：联合报告、专家约稿、媒体专栏，效果差三倍，差别在选题和分工。三种形式怎么选、分工怎么定、效果怎么衡量都在这篇。12 次合作里我们只留下了 5 个长期伙伴，这 5 个才是重点。",{},"\u002Fblog\u002Fcontent-partnership",{"title":240,"description":331},"blog\u002Fcontent-partnership",[337,338,329],"内容合作","行业媒体","TObSnUxp6tCFUrvuYJ99Q5npANIzDLG1yJf33_g7_Ok",1794088101598]