[{"data":1,"prerenderedAt":339},["ShallowReactive",2],{"blog-homepage-video-weight":3,"blog-prev-homepage-video-weight":129,"blog-next-homepage-video-weight":224},{"id":4,"title":5,"author":6,"body":7,"canonical":113,"category":114,"cover":113,"date":115,"description":116,"draft":117,"extension":118,"keywords":113,"meta":119,"navigation":120,"noindex":117,"ogImage":113,"path":121,"seo":122,"seoDescription":113,"seoTitle":113,"stem":123,"tags":124,"updated":113,"__hash__":128},"blog\u002Fblog\u002Fhomepage-video-weight.md","首页背景视频值不值得那两秒，我们算过账","元析智能",{"type":8,"value":9,"toc":102},"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,99],[11,12,13],"p",{},"2026 年 8 月一个客户的首页自动播放背景视频，12 兆，移动端 4G 下首屏 6 秒。市场部坚持要留，说品牌感靠它。我们最后改成点击播放，首屏回到 2.1 秒，视频还在，只是不再自动加载。",[15,16,17],"h2",{"id":17},"视频的成本不只是字节",[11,19,20],{},"字节是最直观的：12 兆的视频，4G 网络按 3 兆每秒算，光下载就四秒。",[11,22,23],{},"解码是第二层：手机解码视频吃 CPU，同时还要渲染页面，主线程被占，交互会卡。",[11,25,26],{},"内存是第三层：移动浏览器对自动播放的视频有内存限制，低端机经常直接不播，用户看到一块黑。",[15,28,29],{"id":29},"什么情况值得放",[11,31,32],{},"产品演示视频，用户点了会看，值得放，但别自动播。",[11,34,35],{},"品牌片，放在关于页或者首屏下面，用户想看会自己点。",[11,37,38],{},"氛围视频，比如抽象的光影流动，这类基本是自我感动，收益最低，成本最高。",[11,40,41],{},"我们的判断标准很简单：这段视频能不能回答用户一个问题。不能，就别放在首屏。",[15,43,44],{"id":44},"替代方案",[11,46,47],{},"用视频的第一帧做静态图，视觉上差不多，体积小几十倍。",[11,49,50],{},"如果一定要动，做三到五秒的无声循环，体积控制在 500KB 以内，并且用 poster 保证首帧立刻显示。",[11,52,53],{},"动效也可以用 CSS 做，几百字节的事，别为了一个渐变动画加载一个视频。",[15,55,56],{"id":56},"如果一定要放",[11,58,59],{},"用 preload=none，别预加载。",[11,61,62],{},"只放 poster，等用户交互或者滚到位置再加载视频。",[11,64,65],{},"移动端直接隐藏视频，给一张静态图。这条最有效，因为大部分流量和大部分性能问题都在移动端。",[15,67,68],{"id":68},"一个对比数据",[11,70,71],{},"改之前，移动端 LCP 5.2 秒，首屏视频占 12 兆。改成点击播放之后，LCP 2.1 秒，视频文件还在服务器上，想看的人照样能看。",[11,73,74],{},"转化数据没有变差。市场部最担心的品牌感，也没人反馈丢了。",[11,76,77],{},"这件事的难点不在技术，在沟通。把视频的字节数、加载时间、移动端占比摆出来，比讲技术道理有效。",[15,79,80],{"id":80},"移动端单独处理",[11,82,83],{},"同一个首页，桌面放视频、移动端放静态图，这个做法我们用了很多次。",[11,85,86],{},"用户不会因为手机上没有视频就觉得品牌差，但会在意打开要等六秒。",[11,88,89],{},"实现上用媒体查询或者服务端判断，别用 JS 判断，因为 JS 判断本身就要等脚本加载完。",[15,91,92],{"id":92},"一个规矩",[11,94,95],{},"我们给新站定了一条规矩：首屏不放自动播放的视频和音频，不放超过 500KB 的动画资源。",[11,97,98],{},"要放，走评审，说明为什么这段视频必须在首屏、为什么不能用静态图替代。",[11,100,101],{},"规矩定在前头，比上线后再砍容易得多。",{"title":103,"searchDepth":104,"depth":104,"links":105},"",2,[106,107,108,109,110,111,112],{"id":17,"depth":104,"text":17},{"id":29,"depth":104,"text":29},{"id":44,"depth":104,"text":44},{"id":56,"depth":104,"text":56},{"id":68,"depth":104,"text":68},{"id":80,"depth":104,"text":80},{"id":92,"depth":104,"text":92},null,"技术SEO","2026-08-11","一个 12 兆的背景视频让移动端首屏到了 6 秒。这篇算清视频的字节、解码和内存成本，写什么情况值得放、怎么延迟加载、以及改成点击播放后的效果。",false,"md",{},true,"\u002Fblog\u002Fhomepage-video-weight",{"title":5,"description":116},"blog\u002Fhomepage-video-weight",[125,126,127],"视频优化","首屏","页面体验","ABcPPox_njcv_afb8oFr8f-AdAWlbsWDz6KVzV2M7Vg",{"id":130,"title":131,"author":6,"body":132,"canonical":113,"category":114,"cover":113,"date":213,"description":214,"draft":117,"extension":118,"keywords":113,"meta":215,"navigation":120,"noindex":117,"ogImage":113,"path":216,"seo":217,"seoDescription":113,"seoTitle":113,"stem":218,"tags":219,"updated":113,"__hash__":223},"blog\u002Fblog\u002Fsitemap-lastmod-correct-usage.md","站点地图的更新日期乱写，等于告诉蜘蛛别来",{"type":8,"value":133,"toc":203},[134,137,141,144,147,150,158,161,165,168,172,175,178,181,185,188,191,194,197,200],[11,135,136],{},"lastmod 是\"这页什么时候真的变过\"的声明。全站都填当前时间，等于宣布每个页面每秒都在更新，搜索引擎会直接忽略这个字段，你就白白丢了一个让蜘蛛优先回来的信号。",[15,138,140],{"id":139},"_2026-年-5-月的对比测试","2026 年 5 月的对比测试",[11,142,143],{},"同一个站拆两组页面：A 组 lastmod 按内容真实修改时间写，B 组每次生成都填当天日期。观察 6 周。",[11,145,146],{},"A 组页面的重新抓取次数是 B 组的 2.3 倍；A 组新内容的平均收录时间 4 天，B 组 11 天。两组内容质量、内链条件都一样，唯一的变量就是 lastmod。",[15,148,149],{"id":149},"正确写法",[11,151,152,153,157],{},"只对真正改动的 URL 更新 lastmod，格式用完整的 ISO 8601 带时区，比如 ",[154,155,156],"code",{},"2026-05-12T10:30:00+08:00","。批量生成时按内容表里的实际修改时间戳映射，别用生成任务的执行时间。",[11,159,160],{},"注意时区。有的 CMS 用 UTC 存时间，输出时没带时区，搜索引擎会按自己的时区解释，可能把时间判到未来。",[15,162,164],{"id":163},"priority-和-changefreq-别调了","priority 和 changefreq 别调了",[11,166,167],{},"这两个字段现在基本被忽略。见过一些站花时间给每个页面调 priority，从 1.0 调到 0.8，指望影响抓取优先级。没意义，把时间花在内链上。",[15,169,171],{"id":170},"增量-sitemap-的用法","增量 sitemap 的用法",[11,173,174],{},"内容量大的站可以拆两份：固定 sitemap 放全量 URL，增量 sitemap 只放最近 7 天变动的 URL。搜索引擎对后者的读取频率通常更高，新内容被发现得更快。两份都在 sitemapindex 里声明。",[15,176,177],{"id":177},"别和发布日期混用",[11,179,180],{},"lastmod 是内容最后修改时间，不是发布时间。改个错别字也算修改，但要判断值不值得更新——只改了导航栏、换了张图，就别动 lastmod，不然又变成\"全站都在变\"。我们的标准是正文可见内容有实质变化才更新。",[15,182,184],{"id":183},"给-cms-加一行判断","给 CMS 加一行判断",[11,186,187],{},"生成器里加个判断：内容没变就不动 lastmod。这一行改动，比在 SEO 上做很多别的优化都直接。我们给客户交付时会把这条写进技术验收清单。",[15,189,190],{"id":190},"和抓取预算的关系",[11,192,193],{},"抓取预算是有限的配额。lastmod 可信的站，蜘蛛能用\"哪些页变了\"来决定先抓谁，效率高；lastmod 全是当天的站，蜘蛛只能按内链和权重盲抓，效率低。这个差异在小站上看不出来，几万页的站上非常明显。",[11,195,196],{},"我们做过一次实验：同一个站只修 lastmod 逻辑，不做其他改动，30 天后新页面的平均发现时间从 9 天降到 3 天。这是整个技术 SEO 里投入产出比最高的改动之一，可惜很少人做。",[15,198,199],{"id":199},"立场",[11,201,202],{},"sitemap 里真正有用的字段只有两个：loc 和 lastmod。把这两个做对，其他都是装饰。",{"title":103,"searchDepth":104,"depth":104,"links":204},[205,206,207,208,209,210,211,212],{"id":139,"depth":104,"text":140},{"id":149,"depth":104,"text":149},{"id":163,"depth":104,"text":164},{"id":170,"depth":104,"text":171},{"id":177,"depth":104,"text":177},{"id":183,"depth":104,"text":184},{"id":190,"depth":104,"text":190},{"id":199,"depth":104,"text":199},"2026-08-10","每次生成 sitemap 都把 lastmod 写成当前时间，是 CMS 的常见默认行为。搜索引擎发现这个字段不可信就会忽略它。这篇讲正确用法、增量拆分，以及一个 2026 年 5 月的对比测试。",{},"\u002Fblog\u002Fsitemap-lastmod-correct-usage",{"title":131,"description":214},"blog\u002Fsitemap-lastmod-correct-usage",[220,221,222],"sitemap","lastmod","收录","q2_vcS1lz1YcDwwvxtLPUvhgKzERg-sqvttTp33LPRA",{"id":225,"title":226,"author":6,"body":227,"canonical":113,"category":327,"cover":113,"date":328,"description":329,"draft":117,"extension":118,"keywords":113,"meta":330,"navigation":120,"noindex":117,"ogImage":113,"path":331,"seo":332,"seoDescription":113,"seoTitle":113,"stem":333,"tags":334,"updated":113,"__hash__":338},"blog\u002Fblog\u002Fauthor-page-credentials.md","作者页别只放头像，放三样能核对的东西",{"type":8,"value":228,"toc":316},[229,232,236,239,242,246,249,252,256,259,262,265,268,271,274,277,280,283,286,289,292,295,298,301,304,307,310,313],[11,230,231],{},"作者页的作用只有一个：让人验证这个人真做过这件事。所以别只放头像和一句“从业十年”。我们固定放三样能点开核对的东西，客户站的作者页改完之后，页面平均停留时间从 25 秒涨到 1 分 10 秒。",[15,233,235],{"id":234},"第一样做过什么","第一样：做过什么",[11,237,238],{},"写具体的项目和职责，不写职级。比如“负责过 3 个日志平台的迁移，处理过单日 20TB 的写入”。",[11,240,241],{},"具体到这个程度，读者才会觉得你说的话有分量。写“负责架构设计”这种，谁都能写。",[15,243,245],{"id":244},"第二样写过什么","第二样：写过什么",[11,247,248],{},"列出这个作者写的所有文章，带链接。这一条是把作者页和内容页绑起来的关键。",[11,250,251],{},"读者看完一篇技术文章，点作者名，看到他还写过五篇同类内容，信任感会明显不同。",[15,253,255],{"id":254},"第三样在哪能查到他","第三样：在哪能查到他",[11,257,258],{},"GitHub、知乎、掘金、技术社区、会议演讲、开源项目。至少给一个能打开的链接。",[11,260,261],{},"注意别放已经废弃的账号。2025 年我们查一个客户站，三个作者里有两位的链接已经 404。",[15,263,264],{"id":264},"别做的事",[11,266,267],{},"别买头衔。什么“资深专家”“行业顾问”，查不到对应经历，写了反而扣分。",[11,269,270],{},"别写大段自我描述。作者页是让人核对信息的，不是让人读散文的。",[15,272,273],{"id":273},"多久更新一次",[11,275,276],{},"每季度核对一次：人还在不在、写的方向变没变、链接有没有失效、文章列表是不是最新。",[11,278,279],{},"人离职了就换成新的负责人，别让页面挂着已经不在的人。我们见过一个站，作者页上的人两年前就离职了。",[15,281,282],{"id":282},"文章页上怎么显示",[11,284,285],{},"标题下面一行：作者名、发布日期、更新日期。作者名要能点。",[11,287,288],{},"有些站把作者藏在页脚，或者只写“编辑部”。匿名写技术内容，可信度天然打折。",[15,290,291],{"id":291},"一个判断标准",[11,293,294],{},"把作者页给一个陌生人看，问他“你觉得这个人真的做过这件事吗”。答案是肯定，这一页就合格。",[15,296,297],{"id":297},"作者页和文章的关系",[11,299,300],{},"作者页不是孤立的。每篇文章都要能链到作者页，作者页要能链回他写的文章，两头都通，信任才建立得起来。",[11,302,303],{},"2026 年 6 月我们查过一个站，作者页有 5 个，但文章页上没有一处能点到作者页。等于白做。",[15,305,306],{"id":306},"团队署名怎么办",[11,308,309],{},"有些内容是多个人写的，署名写“元析智能内容组”也行，但要有一个页面对应这个署名，写清这个组负责什么、谁在维护。",[11,311,312],{},"别让署名变成一个没有落点的词。",[11,314,315],{},"如果他说“看着像营销页”，那就得重写。",{"title":103,"searchDepth":104,"depth":104,"links":317},[318,319,320,321,322,323,324,325,326],{"id":234,"depth":104,"text":235},{"id":244,"depth":104,"text":245},{"id":254,"depth":104,"text":255},{"id":264,"depth":104,"text":264},{"id":273,"depth":104,"text":273},{"id":282,"depth":104,"text":282},{"id":291,"depth":104,"text":291},{"id":297,"depth":104,"text":297},{"id":306,"depth":104,"text":306},"SEO","2026-08-12","作者页的作用是让人验证“这个人真做过这件事”。我们固定放三样：做过什么项目、写过哪些文章、在哪能查到他。三样都能点开核对，比任何头衔有用。",{},"\u002Fblog\u002Fauthor-page-credentials",{"title":226,"description":329},"blog\u002Fauthor-page-credentials",[335,336,337],"作者页","E-E-A-T","内容可信度","71F0M8fduVF3Xn9bak_-yBEkeIgIOyCOdZCe_jZzEto",1794088102939]