[{"data":1,"prerenderedAt":322},["ShallowReactive",2],{"blog-lcp-hero-image-bottleneck":3,"blog-prev-lcp-hero-image-bottleneck":118,"blog-next-lcp-hero-image-bottleneck":244},{"id":4,"title":5,"author":6,"body":7,"canonical":102,"category":103,"cover":102,"date":104,"description":105,"draft":106,"extension":107,"keywords":102,"meta":108,"navigation":109,"noindex":106,"ogImage":102,"path":110,"seo":111,"seoDescription":102,"seoTitle":102,"stem":112,"tags":113,"updated":102,"__hash__":117},"blog\u002Fblog\u002Flcp-hero-image-bottleneck.md","首图拖慢首屏，软件公司官网 LCP 卡住的三个真实原因","元析智能",{"type":8,"value":9,"toc":93},"minimark",[10,14,19,22,25,28,32,44,47,50,54,60,71,75,78,81,84,87,90],[11,12,13],"p",{},"我们审计过 11 个软件公司官网，其中 8 个的 LCP 元素是首屏那张产品截图，不是文字标题。原因集中在三处：图按设计稿尺寸直接导出、首屏图被统一加了懒加载、首图写在 CSS 背景里。改完这三处，平均能从 4 秒出头压到 2.2 秒左右，不需要动服务器。",[15,16,18],"h2",{"id":17},"原因一图按设计稿尺寸导出","原因一：图按设计稿尺寸导出",[11,20,21],{},"去年 11 月接的一个项目管理 SaaS，首页 hero 图是 2400×1350 的 PNG，1.8MB，而它在页面上实际只渲染 720 像素宽。设计师给的 2 倍图，前端直接放了原图，没人算过这一张占了首屏流量的七成。",[11,23,24],{},"改成 1440 宽、WebP 质量 78，体积 180KB。同一张图，在笔记本上肉眼分辨不出差别。这个站的 LCP 从 4.1 秒降到 2.9 秒，只动了这一处。",[11,26,27],{},"查法很简单：Performance 面板里看 LCP 请求的 transfer size，再和 Elements 里这张图的实际渲染尺寸对一下。传输体积超过渲染面积所需的两倍，就是浪费。这个判断不需要工具，手算一下就行。",[15,29,31],{"id":30},"原因二首屏图被统一加了懒加载","原因二：首屏图被统一加了懒加载",[11,33,34,35,39,40,43],{},"很多模板给所有 ",[36,37,38],"code",{},"img"," 统一加 ",[36,41,42],{},"loading=\"lazy\"","，图省事。首屏图懒加载的代价是浏览器不会在解析 HTML 阶段就拿它，要等布局算完、判断它进入视口，才开始下载。移动端这一步能拖 300 到 600 毫秒。",[11,45,46],{},"我们查过一个开发者工具站，LCP 元素明明是首屏的架构图，Lighthouse 里这个请求的发现时间排在第 9 位。把首屏那张图的 lazy 去掉，它从第 9 位提到第 2 位，LCP 从 3.6 秒到 2.4 秒。",[11,48,49],{},"判断标准：首屏内的图不要 lazy，首屏外的图必须 lazy。一个属性的事，值得单独检查一遍。",[15,51,53],{"id":52},"原因三首图是-css-背景图","原因三：首图是 CSS 背景图",[11,55,56,59],{},[36,57,58],{},"background-image"," 写在样式表里，浏览器要先下载 CSS、解析、匹配选择器，才知道有这么张图。这层依赖让它的发现时间比 HTML 里的 img 晚一个 RTT 以上。",[11,61,62,63,66,67,70],{},"一个安全工具站的首图是背景图，2.4MB。我们把它改成 ",[36,64,65],{},"\u003Cimg>"," 加 ",[36,68,69],{},"object-fit: cover","，顺手做了响应式尺寸，LCP 从 3.9 秒到 2.6 秒。如果非要用背景图，至少在 HTML 里加 preload，但维护成本更高，不如直接换标签。",[15,72,74],{"id":73},"先改图再谈别的","先改图，再谈别的",[11,76,77],{},"这三处的共同点是：改的是资源本身，不是加载策略。很多团队一上来就研究 CDN、预加载、HTTP\u002F3，方向反了。首图 1.8MB 摆在那儿，CDN 再快也得把这 1.8MB 传完。",[11,79,80],{},"顺序应该是：先把图减到该有的体积，再去掉阻碍发现的属性，最后才考虑链路优化。前两步能解决软件站七成的 LCP 问题，剩下三成才是服务端和协议的事。",[15,82,83],{"id":83},"一个我们常用的取舍",[11,85,86],{},"客户经常问，首图到底该放多大。我们的经验值是按容器渲染宽度的 2 倍出图，质量 75 到 80，WebP 优先。超过这个规格，画质提升用户看不出来，体积却线性上涨。遇到一定要放 3 倍图的设计需求，让设计师把纹理和高光做成渐变，比提高分辨率更省。",[11,88,89],{},"另一个容易忽略的点是首图的 alt 和尺寸属性。宽高写死能让浏览器提前占位，既避免 CLS，也让 LCP 记录更准。我们见过好几个站，首图没有 width 和 height，布局抖一下，LCP 时间跟着延后 200 毫秒。",[11,91,92],{},"最后提醒一句：改完图要清 CDN 缓存，再重新测。我们有一次改完等了两天没效果，最后发现是边缘节点还挂着旧的 1.8MB 版本。",{"title":94,"searchDepth":95,"depth":95,"links":96},"",2,[97,98,99,100,101],{"id":17,"depth":95,"text":18},{"id":30,"depth":95,"text":31},{"id":52,"depth":95,"text":53},{"id":73,"depth":95,"text":74},{"id":83,"depth":95,"text":83},null,"技术SEO","2025-09-06","审计 11 个软件公司官网，8 个的 LCP 元素是首屏产品截图。三个原因最常见：设计稿原图直出、首屏图被加懒加载、首图写在 CSS 背景里。改完平均从 4 秒压到 2.2 秒。",false,"md",{},true,"\u002Fblog\u002Flcp-hero-image-bottleneck",{"title":5,"description":105},"blog\u002Flcp-hero-image-bottleneck",[114,115,116],"LCP","图片优化","首屏速度","ZiTxUQwWAqBk7wb8pbARG82nSvZ0shnpFHsE2jbZh_s",{"id":119,"title":120,"author":6,"body":121,"canonical":102,"category":103,"cover":102,"date":233,"description":234,"draft":106,"extension":107,"keywords":102,"meta":235,"navigation":109,"noindex":106,"ogImage":102,"path":236,"seo":237,"seoDescription":102,"seoTitle":102,"stem":238,"tags":239,"updated":102,"__hash__":243},"blog\u002Fblog\u002Fcrawl-budget-diagnosis.md","软件站抓取预算被浪费的 4 个地方和查法",{"type":8,"value":122,"toc":226},[123,126,130,133,136,143,147,158,174,177,181,188,201,204,208,211,214,217,220,223],[11,124,125],{},"大多数软件公司站的抓取问题不是抓取不够，是抓取被浪费了。我们今年给 6 个软件公司站做日志分析，按百度蜘蛛和 Googlebot 的请求量算，平均 38% 的抓取花在了不该抓的 URL 上，真正会带来排名的产品页、文档页反而抓得很浅。下面是我们查出来的四类最常见浪费，以及具体的查法。",[15,127,129],{"id":128},"第一类参数和筛选页","第一类：参数和筛选页",[11,131,132],{},"产品列表页带筛选参数，是抓取浪费的大头。一个做项目管理软件的客户，产品列表页有状态、行业、规模三个筛选维度，组合出来的 URL 有 60 多种。百度蜘蛛每天来抓 800 次，其中 500 多次落在这些组合 URL 上，每个页面内容还差不多。",[11,134,135],{},"查法：把日志按 URL 里的问号参数分组，数每个参数组合的抓取次数，再看这些页面的收录和排名。如果某个组合抓了 50 次以上、排名在 50 名开外，基本就是浪费。",[11,137,138,139,142],{},"改法：给筛选页加 ",[36,140,141],{},"noindex"," 或者用 robots.txt 屏蔽参数组合，只保留默认列表页。这个客户屏蔽后第 3 周，核心产品页的抓取频次从每周 2 次涨到每周 11 次。",[15,144,146],{"id":145},"第二类cms-后台和测试环境暴露在公网","第二类：CMS 后台和测试环境暴露在公网",[11,148,149,150,153,154,157],{},"说出来有点丢人，但这真的常见。我们接手的一个开发者工具站，robots.txt 里没屏蔽 ",[36,151,152],{},"\u002Fadmin","，Google 收录了 200 多个后台页面，还有一批 ",[36,155,156],{},"staging.example.com"," 的页面被收录。后台页面不会被用户搜到，但会分走抓取频次，也有安全风险。",[11,159,160,161,163,164,163,167,163,170,173],{},"查法：GSC 的索引报告里筛 ",[36,162,152],{},"、",[36,165,166],{},"?preview=",[36,168,169],{},"staging",[36,171,172],{},"test"," 这些词；百度搜索资源平台的收录量也能看个大概。日志里看这些路径的抓取占比。",[11,175,176],{},"改法：robots.txt 屏蔽 + 后台加登录鉴权 + 测试环境加 Basic Auth。已经收录的页面用 410 或 301 处理，别放那里不管。",[15,178,180],{"id":179},"第三类分页和标签页无限翻","第三类：分页和标签页无限翻",[11,182,183,184,187],{},"博客标签页、分页的 ",[36,185,186],{},"?page=99","、日历归档，是第三类。一个 SaaS 站的分页参数被蜘蛛翻到了第 87 页，后面全是空列表。这种页面抓一次是浪费，抓几百次就是灾难。",[11,189,190,191,163,194,163,197,200],{},"查法：日志里筛 ",[36,192,193],{},"page=",[36,195,196],{},"tag=",[36,198,199],{},"category="," 这些参数，看最大页码和抓取次数。GSC 里看这些页面的抓取频次。",[11,202,203],{},"改法：分页加上限（比如只保留前 10 页 index，后面的 noindex），标签页合并或者 noindex，日历归档直接去掉。列表页本身要保留，但别让蜘蛛无限翻。",[15,205,207],{"id":206},"第四类已经放弃的老页面和重复域名","第四类：已经放弃的老页面和重复域名",[11,209,210],{},"老站迁移、换域名之后，旧域名的页面如果还挂着，蜘蛛会继续抓。我们见过一个客户，旧域名没做 301，两个域名同时在线 8 个月，新域名收录量一直上不去。还有一种是文章改版后旧 URL 没处理，同一个内容挂两个地址。",[11,212,213],{},"查法：日志里按 host 分组，看有没有多个域名；按 URL 的模式看改版前的路径还有没有请求。GSC 的重复网页报告、百度的重复内容提示也能辅助判断。",[11,215,216],{},"改法：旧域名整站 301 到新域名，旧 URL 写规则跳转，别保留双份内容。改完在 GSC 里提交改版，百度那边用抓取诊断确认新 URL 可抓。",[15,218,219],{"id":219},"我们自己的检查顺序",[11,221,222],{},"先看日志总量和各路径占比，再对照 GSC 索引报告，最后才动手改。顺序反了容易拍脑袋。改完至少观察 3 周，抓取频次的恢复比排名快，别指望第二天就见效。",[11,224,225],{},"如果你们站日抓取量在 1000 次以下，先别研究抓取预算，先把内容做起来。抓取预算是流量上来之后才值得抠的细节。",{"title":94,"searchDepth":95,"depth":95,"links":227},[228,229,230,231,232],{"id":128,"depth":95,"text":129},{"id":145,"depth":95,"text":146},{"id":179,"depth":95,"text":180},{"id":206,"depth":95,"text":207},{"id":219,"depth":95,"text":219},"2025-09-05","我们给 6 个软件公司站做过日志分析，抓取预算平均有 38% 花在没用的 URL 上。这篇文章列出最常浪费抓取预算的 4 个地方，以及用日志怎么查、怎么改。",{},"\u002Fblog\u002Fcrawl-budget-diagnosis",{"title":120,"description":234},"blog\u002Fcrawl-budget-diagnosis",[240,241,242],"抓取预算","日志分析","站点结构","y2yg1gFSRUpcAN5-1ElahpOo3Z4nsaSvEATrHZs4WFc",{"id":245,"title":246,"author":6,"body":247,"canonical":102,"category":309,"cover":102,"date":310,"description":311,"draft":106,"extension":107,"keywords":102,"meta":312,"navigation":109,"noindex":106,"ogImage":102,"path":313,"seo":314,"seoDescription":102,"seoTitle":102,"stem":315,"tags":316,"updated":102,"__hash__":321},"blog\u002Fblog\u002Fkeyword-research-five-steps.md","软件公司做关键词研究，我们固定跑这五步流程",{"type":8,"value":248,"toc":302},[249,252,256,259,262,265,269,272,275,279,282,286,289,292,296,299],[11,250,251],{},"关键词研究我们不是从工具开始的。顺序固定为：先翻手里已有的数据，再去噪，再分层，再跟具体页面匹配，最后上线复检。工具用在第一步和第二步之间，用完就退场。2025 年 3 月给一家做接口监控的软件公司重做词库，两万一千个词导进来，真正进排期的只有 71 个。",[15,253,255],{"id":254},"第一步先把手里已有的三份数据摆出来","第一步：先把手里已有的三份数据摆出来",[11,257,258],{},"一上来就买工具的公司很多，其实最值钱的三份数据在自己手里：客服工单、销售丢单记录、搜索后台的真实查询。",[11,260,261],{},"工单里客户怎么描述问题，就是他们会在百度里怎么搜。丢单记录里那句“我们最后选了别家，因为……”经常直接给出一个对比词。搜索后台最直接，最近 28 天有曝光、排不到名的查询，就是现成的高意图词表。",[11,263,264],{},"那次 71 个选题里，30 个来自工单，11 个来自丢单记录，剩下的来自后台。工具导出的两万一千个词贡献了几个？三个。",[15,266,268],{"id":267},"第二步去噪比挖词更费时间","第二步：去噪比挖词更费时间",[11,270,271],{},"两万一千个词，机器按词根去重和否定词过滤后剩一万二，再人工过一遍剩八千出头。噪音主要四类：破解下载、招聘外包、同名不同义、以及完全不相干的行业词。",[11,273,274],{},"否定词表我们固定三十几个，包括免费、破解、下载、教程、招聘、外包、源码、汉化。每次都要补充，但起点不动。这一步省不了，谁省谁后面写废稿。",[15,276,278],{"id":277},"第三步分层不是列一张长表","第三步：分层，不是列一张长表",[11,280,281],{},"词库按意图分成四张表：学习类、方案类、对比类、操作类。四张表分别对应四种页面，也分别对应四个负责人。分层之后，一个词该由谁写、写成什么，不用再开会讨论。",[15,283,285],{"id":284},"第四步词表要落到具体页面上","第四步：词表要落到具体页面上",[11,287,288],{},"词和页面是一对多。一个功能页能承接二十来个长尾词，但一个词只能落一个页面。两个页面对同一个词，等于自己跟自己抢位置。",[11,290,291],{},"定稿前我要求每个词后面写一个 URL。写不出来的词，说明还没想清楚写什么，先放着。",[15,293,295],{"id":294},"第五步上线四周后复检","第五步：上线四周后复检",[11,297,298],{},"发布后第 28 天翻一次后台。有曝光的留着，三周零曝光的，要么删掉，要么并进相邻页面。第一轮复检我们会砍掉大约 15% 的选题，这个比例比我预想的高，后来就接受了。",[11,300,301],{},"关键词研究不是做完一次就归档的项目。每次写稿之前，我都得把这些词重新看一遍。",{"title":94,"searchDepth":95,"depth":95,"links":303},[304,305,306,307,308],{"id":254,"depth":95,"text":255},{"id":267,"depth":95,"text":268},{"id":277,"depth":95,"text":278},{"id":284,"depth":95,"text":285},{"id":294,"depth":95,"text":295},"SEO","2025-09-07","关键词研究不是打开工具导一张表。我们的顺序是来源、去噪、分层、匹配、复检，两万多个词最后进排期的只有 71 个。五步分别怎么做、素材从哪来，都写在下面。",{},"\u002Fblog\u002Fkeyword-research-five-steps",{"title":246,"description":311},"blog\u002Fkeyword-research-five-steps",[317,318,319,320],"关键词研究","词库搭建","软件公司","选题","63BTO5nuoPqLe0chnAKs_sSuf-NtyXAJDEoj-i3xAYI",1794088112635]