[{"data":1,"prerenderedAt":330},["ShallowReactive",2],{"blog-font-loading-chinese":3,"blog-prev-font-loading-chinese":114,"blog-next-font-loading-chinese":218},{"id":4,"title":5,"author":6,"body":7,"canonical":98,"category":99,"cover":98,"date":100,"description":101,"draft":102,"extension":103,"keywords":98,"meta":104,"navigation":105,"noindex":102,"ogImage":98,"path":106,"seo":107,"seoDescription":98,"seoTitle":98,"stem":108,"tags":109,"updated":98,"__hash__":113},"blog\u002Fblog\u002Ffont-loading-chinese.md","中文字体加载慢，问题不在字体文件大小","元析智能",{"type":8,"value":9,"toc":88},"minimark",[10,14,18,21,24,27,30,33,36,40,43,46,49,52,55,58,61,64,67,70,73,76,79,82,85],[11,12,13],"p",{},"2026 年 7 月我们给一个站查首屏，字体请求花了 1.9 秒，字体包 8 兆。中文字体确实大，但把它变慢的往往不是体积，而是加载时机和切换方式。改完之后同一个包首屏基本感觉不到等待。",[15,16,17],"h2",{"id":17},"中文字体为什么这么大",[11,19,20],{},"一个完整的思源黑体，包含两万多个字形，压缩后也有五到八兆。网页上真正用到常用字大概三千五，剩下九成多是浪费。",[11,22,23],{},"所以中文字体优化的第一件事不是压缩，是子集化：把你实际用到的字挑出来，生成一个只有几百 KB 的字体文件。",[15,25,26],{"id":26},"子集化怎么做",[11,28,29],{},"第一种，按页面用字生成。统计页面里出现的所有字符，生成对应子集。缺点是页面内容一改就要重新生成，适合内容稳定的官网。",[11,31,32],{},"第二种，按 unicode-range 分片。把字体切成多个小文件，浏览器按需加载。首屏常用字在第一个分片里，加载很快。",[11,34,35],{},"第三种，用在线字体服务，它们默认做分片。代价是多一个外部依赖，国内访问还要考虑稳定性。",[15,37,39],{"id":38},"font-display-三种取值","font-display 三种取值",[11,41,42],{},"block，字体没加载完文字不显示，最多等三秒。体验最差，用户看到一片空白。",[11,44,45],{},"swap，先用系统字体显示，加载完再换。文字马上可见，但切换时会有位移，字号大的时候很明显。",[11,47,48],{},"optional，如果字体没在很短的时间内加载好，这次就用系统字体，不切换。最不影响体验，但品牌字体可能经常不显示。",[11,50,51],{},"我们的选择是标题用 swap 加尺寸校正，正文直接用系统字体。",[15,53,54],{"id":54},"预加载和预连接",[11,56,57],{},"字体文件藏在 CSS 里，浏览器要等 CSS 解析完才发现它。用 preload 提前告诉浏览器，能省掉一个来回。",[11,59,60],{},"preload 要带 crossorigin，否则会因为请求类型不匹配被下载两次。这个坑我们踩过，字体反而更慢了。",[11,62,63],{},"字体放在第三方域名上，再加一条 preconnect，把 TLS 握手提前做掉。",[15,65,66],{"id":66},"什么时候干脆别用",[11,68,69],{},"一个官网只用了两种英文字体、没有中文需求，完全可以不加载自定义字体，用系统字体栈。",[11,71,72],{},"系统字体在 macOS、Windows、安卓上都不一样，但都好看，且零加载时间。首屏速度能提升几百毫秒。",[11,74,75],{},"品牌必须用特定字体，那就只用在标题和 logo 上，正文用系统字体。我们的默认建议就是这条。",[15,77,78],{"id":78},"一个验证方法",[11,80,81],{},"改完别只看 Lighthouse 的分数。把网络降到 3G，清缓存刷新，观察文字什么时候出现、什么时候变形。",[11,83,84],{},"再看真实用户数据。CrUX 里没有字体指标，但 LCP 如果卡在文字上，说明字体拖了后腿。",[11,86,87],{},"字体优化的收益常常被低估，因为它不像图片那么显眼。但首屏里最大的那块如果是标题文字，字体就是 LCP 的直接原因。",{"title":89,"searchDepth":90,"depth":90,"links":91},"",2,[92,93,94,95,96,97],{"id":17,"depth":90,"text":17},{"id":26,"depth":90,"text":26},{"id":38,"depth":90,"text":39},{"id":54,"depth":90,"text":54},{"id":66,"depth":90,"text":66},{"id":78,"depth":90,"text":78},null,"技术SEO","2026-06-13","一个中文字体包动辄八兆，但真正拖慢首屏的是加载时机和字形切换。这篇写子集化怎么做、font-display 三种取值怎么选、什么时候干脆别用自定义字体。",false,"md",{},true,"\u002Fblog\u002Ffont-loading-chinese",{"title":5,"description":101},"blog\u002Ffont-loading-chinese",[110,111,112],"字体加载","页面体验","首屏","Sj3AIAaQl9sp9T_6h0hDGKZlWOxFU1oPgRu62eF9Nog",{"id":115,"title":116,"author":6,"body":117,"canonical":98,"category":99,"cover":98,"date":207,"description":208,"draft":102,"extension":103,"keywords":98,"meta":209,"navigation":105,"noindex":102,"ogImage":98,"path":210,"seo":211,"seoDescription":98,"seoTitle":98,"stem":212,"tags":213,"updated":98,"__hash__":217},"blog\u002Fblog\u002Fbaidu-js-rendering-test.md","百度对 JS 渲染支持到什么程度，我们测了 6 个页面",{"type":8,"value":118,"toc":198},[119,122,125,128,131,138,144,150,156,162,168,171,174,177,180,183,186,189,192,195],[11,120,121],{},"百度能渲染一部分 JS，但对异步数据、懒加载内容、动态注入的元信息支持不稳定。2026 年 3 月我们搭了一个独立测试域，用 6 个页面把这件事测了一遍。",[15,123,124],{"id":124},"怎么测的",[11,126,127],{},"6 个页面分别只测一个变量：纯 React 渲染标题和正文、正文通过接口异步加载、内链由 JS 动态插入、图片懒加载、Web Component 渲染正文、JSON-LD 由 JS 注入。观察方法用百度搜索资源平台的抓取诊断，看\"抓取到的 HTML\"里到底有什么。",[15,129,130],{"id":130},"结果",[11,132,133,137],{},[134,135,136],"strong",{},"纯 React 渲染","：标题和首屏正文被渲染出来，折叠面板里的内容没有渲染。",[11,139,140,143],{},[134,141,142],{},"接口异步加载的正文","：大部分没抓到，只有个别几次拿到了部分。",[11,145,146,149],{},[134,147,148],{},"JS 动态插入的内链","：没有被推理到，蜘蛛没有顺着这些链接去抓新页面。",[11,151,152,155],{},[134,153,154],{},"懒加载图片","：未被识别，图片没有进索引。",[11,157,158,161],{},[134,159,160],{},"Web Component 渲染的正文","：部分失败，不同页面结果不一致。",[11,163,164,167],{},[134,165,166],{},"JS 注入的 JSON-LD","：完全没被识别。",[15,169,170],{"id":170},"结论怎么用",[11,172,173],{},"首屏静态内容可靠。异步接口、懒加载、动态注入这三类不可靠。所以：标题、正文、内链、结构化数据，必须出现在服务端返回的 HTML 里。图片如果要参与索引，首屏别用懒加载。",[15,175,176],{"id":176},"我们还顺手测了抓取节奏",[11,178,179],{},"同样的 6 个页面，静态版和 JS 版各一份，观察百度蜘蛛的抓取次数。30 天里静态版平均被抓 4 次，JS 版平均 2 次，而且 JS 版的抓取集中在页面刚上线那几天，之后明显减少。这说明百度对渲染成本高的页面会降低抓取频率，这个结论比单个页面的收录结果更值得注意。",[15,181,182],{"id":182},"给前端的三个要求",[11,184,185],{},"标题和正文在服务端返回；内链用真实 a 标签，别用 onclick 跳转；结构化数据写在模板里，别在组件挂载后插入。三条做到，百度的收录表现会稳定很多，Google 那边也不会更差。",[15,187,188],{"id":188},"一个现实的做法",[11,190,191],{},"如果前端改不动，至少把关键内容预渲染一层，让蜘蛛拿到静态 HTML。用户走原 SPA，两边并行一段时间，等前端排期再做真正的 SSR。这条路我们走过几次，可行，但要接受维护成本。",[15,193,194],{"id":194},"立场",[11,196,197],{},"百度不是不能渲染，是别把 SEO 的关键内容压在渲染上。赌蜘蛛的行为，收益不确定，成本却是确定的——每次改版都要重新赌一次。",{"title":89,"searchDepth":90,"depth":90,"links":199},[200,201,202,203,204,205,206],{"id":124,"depth":90,"text":124},{"id":130,"depth":90,"text":130},{"id":170,"depth":90,"text":170},{"id":176,"depth":90,"text":176},{"id":182,"depth":90,"text":182},{"id":188,"depth":90,"text":188},{"id":194,"depth":90,"text":194},"2026-06-12","百度能执行 JS，但能力有限。我们设计 6 个测试页面，分别测 React 渲染、接口异步数据、动态内链、懒加载、Web Component、JSON-LD 注入，记录百度的实际抓取结果。",{},"\u002Fblog\u002Fbaidu-js-rendering-test",{"title":116,"description":208},"blog\u002Fbaidu-js-rendering-test",[214,215,216],"JS渲染","百度收录","SPA","HYlisdd4OJXU-B0mgc-w9gjgjZ9pgcYrpptfcwc8WpI",{"id":219,"title":220,"author":6,"body":221,"canonical":98,"category":319,"cover":98,"date":320,"description":321,"draft":102,"extension":103,"keywords":98,"meta":322,"navigation":105,"noindex":102,"ogImage":98,"path":323,"seo":324,"seoDescription":98,"seoTitle":98,"stem":325,"tags":326,"updated":98,"__hash__":329},"blog\u002Fblog\u002Fcontent-repurposing.md","一篇长文拆成 6 个渠道：我们的内容复用流程和偷懒清单",{"type":8,"value":222,"toc":310},[223,226,229,232,235,238,241,244,247,250,253,256,259,262,265,268,271,274,277,280,283,286,289,292,295,298,301,304,307],[11,224,225],{},"写完一篇 4000 字长文只发一个渠道，是最常见的浪费。我们把它拆成 6 个渠道：公众号、Newsletter、知乎、视频脚本、社交媒体卡片、销售物料。",[15,227,228],{"id":228},"为什么要复用",[11,230,231],{},"一篇深度长文的成本不低：调研、写作、审稿，加起来 20 到 30 小时。只发一个渠道，等于只用了 30% 的价值。",[11,233,234],{},"我们 2025 年算过一笔账：复用流程跑起来之后，同样一篇内容带来的总曝光是原来的 3.2 倍，增量成本不到 6 小时。",[15,236,237],{"id":237},"六个渠道怎么拆",[11,239,240],{},"公众号：取长文的一个核心观点，写成 2000 字左右的独立文章，开头直接抛结论，结尾链回长文。",[11,242,243],{},"Newsletter：把长文缩成 800 字摘要，列 3 个要点，加一个\"完整版在这里\"的链接。",[11,245,246],{},"知乎：回答一个和长文主题对应的问题，用长文里的数据和案例，别整篇复制。",[11,248,249],{},"视频脚本：取最有画面感的一节，改成 3 分钟口播脚本，配 PPT 或录屏。",[11,251,252],{},"社交媒体卡片：把长文里的 5 个数字或 5 个结论做成图，配一句短文案。",[11,254,255],{},"销售物料：把长文里的框架整理成一页 PDF，给销售在和客户沟通时用。",[15,257,258],{"id":258},"拆的时候改什么",[11,260,261],{},"改开头：每个渠道的读者进入场景不同，开头要重写，别用同一个。",[11,263,264],{},"改长度：长文 4000 字，公众号 2000 字，Newsletter 800 字，卡片 100 字。",[11,266,267],{},"改钩子：公众号用故事开头，知乎用问题开头，视频用画面开头。",[11,269,270],{},"不改的：核心数据、案例、观点。这些是长文的价值，拆分时要保留。",[15,272,273],{"id":273},"一个例子",[11,275,276],{},"2026 年 4 月我们发了一篇\"API 限流怎么做\"的长文，4200 字。",[11,278,279],{},"公众号版讲了一个客户被限流打挂的故事，阅读 1.2 万。知乎版回答\"API 限流有哪些方案\"，拿了 800 多赞。视频脚本做了 3 分钟，播放 2 万。Newsletter 版带来 200 多个订阅。销售物料那页 PDF，被销售用了 30 多次。",[11,281,282],{},"同一批内容，六个渠道，总曝光是长文本身的 5 倍。",[15,284,285],{"id":285},"什么时候别复用",[11,287,288],{},"时效性内容别复用。热点过了，拆出来的内容也没人看。",[11,290,291],{},"数据没验证的别复用。一个渠道出错还能改，六个渠道同时出错，就是事故。",[11,293,294],{},"内部资料别外发。客户案例、报价逻辑这类内容，拆之前先确认能不能公开。",[15,296,297],{"id":297},"偷懒清单",[11,299,300],{},"我们内部有一个\"复用检查表\"：开头改了吗、长度改了吗、钩子改了吗、链接对吗、数据核实了吗、发布渠道的格式适配了吗。六项全过才能发。",[11,302,303],{},"这个表看起来麻烦，但比每个渠道重新写一遍省事得多。六个渠道的改法都是我们自己摸出来的，没有理论，全是试错。",[15,305,306],{"id":306},"一句判断",[11,308,309],{},"内容复用的核心不是\"一稿多投\"，是\"一稿多写\"。同一份素材，按渠道重写开头和结构，才是复用；直接把长文复制到五个平台，那是偷懒，效果也差。",{"title":89,"searchDepth":90,"depth":90,"links":311},[312,313,314,315,316,317,318],{"id":228,"depth":90,"text":228},{"id":237,"depth":90,"text":237},{"id":258,"depth":90,"text":258},{"id":273,"depth":90,"text":273},{"id":285,"depth":90,"text":285},{"id":297,"depth":90,"text":297},{"id":306,"depth":90,"text":306},"内容运营","2026-06-14","写完一篇 4000 字长文只发一个渠道，是最常见的浪费。我们把它拆成 6 个渠道：公众号、Newsletter、知乎、视频脚本、社交媒体卡片、销售物料。拆什么、改什么、哪些不能复用都在这篇，拆分清单可以直接抄，我们每周都在用。",{},"\u002Fblog\u002Fcontent-repurposing",{"title":220,"description":321},"blog\u002Fcontent-repurposing",[327,328,319],"内容复用","内容分发","4pV4s2sH-f31_5hUn4CbmwYe60yRFEPMyF96OmmeCM0",1794088104789]