海外客户用低端机、弱网打开你的独立站有多卡？移动端性能优化实战

做出海独立站，很多人优化性能时有个隐形的盲区——他们是拿自己手里的高端旗舰机、连着公司千兆光纤、在离服务器很近的地方测的，测出来秒开，于是放心了。可你的真实客户，可能是东南亚、印度、中东、拉美、非洲的用户，用着两三年前的千元安卓机，连着时好时坏的4G甚至3G网络，离你的服务器隔着半个地球。同一个页面，你这边是丝滑大片，他那边是卡顿幻灯片。

保哥这篇专门讲这个被严重低估的问题：怎么为弱网和低端机优化你的独立站移动端体验。它和保哥上一篇讲的网络层排障是一对——网络层解决“连不连得上”，这篇解决“连上了之后，在又慢又弱的机器和网络上，还用不用得了”。从图片瘦身、JavaScript减负、首屏抢跑，到弱网下的缓存与容错，再到怎么测出真实的低端机弱网体验，一条条给你拆开。一句话：你的客户不在你的测试环境里，别拿旗舰机的流畅，去想象千元机的卡顿。

为什么你测着飞快的独立站，海外客户用起来却卡成幻灯片？

保哥先戳破一个几乎人人都中招的盲区。你优化独立站性能，是怎么测的？多半是掏出自己手里的旗舰手机，连着办公室的高速WiFi，打开页面，秒开，心里一块石头落地：挺快的嘛。然后呢，就没有然后了，你以为性能这关过了。

问题是，你的测试环境和你真实客户的使用环境，可能是两个世界。你用的是最新款高端机，CPU性能强劲；客户用的可能是两三年前的千元安卓机，CPU弱、内存小。你连的是稳定的千兆光纤；客户连的可能是时好时坏的4G、信号差时掉到3G的移动网络。你离服务器近，可能就在同一个国家；客户在东南亚、在印度、在中东、在拉美、在非洲，离你的服务器隔着半个地球。

这三重差距叠加起来，结果就是：同一个页面，你这边是流畅的丝滑大片，客户那边是一卡一卡的幻灯片。你看不到这个卡顿，因为你的设备和网络把所有性能问题都掩盖了。而你的客户看得真真切切——图片半天刷不出来，点个按钮要等好几秒才有反应，滚动起来一顿一顿，很多人没等页面加载完，就失去耐心关掉了。你流失了订单，却完全不知道问题出在哪，因为在你的环境里，一切正常。

这事儿对做出海生意的人尤其要命，因为新兴市场恰恰是很多独立站增长最快的客户来源，而新兴市场的设备和网络现实，和欧美发达地区差得远。那里有大量价格敏感、用着入门级安卓机、流量也未必充裕的用户。你想赚他们的钱，就得让你的网站在他们的真实条件下能用、好用，而不是只在你的旗舰机上好看。

这篇要讲的，就是怎么为这种弱网加低端机的真实环境，优化你的独立站移动端体验。它和保哥上一篇讲的海外用户打不开、加载慢的网络层排障正好是配套的一对：网络层排障解决的是“用户到底连不连得上你的服务器”，是通不通的问题；而这篇解决的是“用户连上之后，在又弱又慢的机器和网络上，页面还用不用得了、卡不卡”，是好不好用的问题。连得上只是起点，连上之后的体验，才决定他会不会下单。下面一条条拆怎么优化。

一个先打的预防针：这篇不是教你把网站做残。优化弱网体验，核心是让真实的内容和功能在弱设备上变得流畅可用，不是阉割内容去换一个好看的速度分数。这个分寸，贯穿后面每一节。

弱网和低端机到底会放大哪些性能问题？

动手优化之前，得先理解你的敌人——弱网和低端机，分别在折磨用户的哪一环。它们是两个不同的瓶颈，叠在一起威力翻倍，但成因和应对各不相同，分开看才看得清。

先说弱网。弱网的特征是带宽低、延迟高、还时常丢包重连。带宽低意味着同样大小的资源，下载要花更长时间——你那张在快网上一闪而过的大图，在弱网上可能要转好几秒。延迟高意味着每一次请求来回的等待都被拉长，页面如果要发起很多次请求，这些等待累加起来很可观。丢包重连则意味着连接不稳定，一个请求可能传到一半断了要重来，体验断断续续。所以弱网最怕的是“大”和“多”——资源体积大、请求次数多，在弱网下都会被成倍放大成漫长的等待。

再说低端机。低端机的瓶颈在于算力和内存。CPU性能弱，最直接的后果是解析和执行JavaScript慢得多——同一段脚本，高端机几十毫秒跑完，低端机可能要几百毫秒甚至更久，这期间页面是卡住的、点了没反应的。内存小，则意味着同时能处理的东西有限，页面太重、脚本太多，容易卡顿甚至崩溃。屏幕和浏览器也可能偏旧，对新特性支持不好。所以低端机最怕的是“重”——JavaScript重、页面结构重、运行时负担重，这些都会卡在它孱弱的CPU上。

把这两个瓶颈翻译成大家熟悉的性能指标，就更清楚了。弱网主要拖垮加载类指标，比如LCP（最大内容绘制，首屏主要内容多久能显示）——资源下载慢，首屏自然出得慢。

低端机主要拖垮交互类指标，比如INP（交互到下一次绘制，点击后多久有反应）——CPU忙着解析执行脚本，没空响应你的点击，按钮就像没按下去一样。web.dev — Optimize Largest Contentful Paint（官方拆解LCP由资源加载延迟、渲染阻塞等环节构成及优化方法）里把LCP拆成了资源加载延迟、渲染阻塞等几段，弱网恰恰是在资源加载这段疯狂拖后腿。

理解了这个，后面的优化思路就有了主线：对付弱网，核心是给资源减重、给请求减量；对付低端机，核心是给JavaScript和运行时减负。两条主线交织，就是接下来几节要拆的具体打法。先从收益最大的那一刀——图片，开始。

图片是弱网下最大的累赘，怎么给它瘦身？

如果弱网优化只能做一件事，保哥会毫不犹豫地说：先搞定图片。原因很简单，在绝大多数电商和独立站页面上，图片是体积占比最大的资源，往往占到整个页面下载量的一大半甚至更多。对带宽紧张的弱网用户来说，图片就是压在他们网速上最重的那块石头。把图片瘦身做好，是投入产出比最高的一刀，没有之一。给图片瘦身，有几个层层递进的手段。

第一，换用现代图片格式。很多站还在用老旧的JPEG、PNG，体积偏大。换成WebP这样的现代格式，能在几乎看不出画质差别的前提下，把文件砍小一大截。web.dev — Use WebP images（WebP通常比同质量JPEG／PNG小25–35% 的官方说明）里给的数据是，WebP通常比同质量的JPEG、PNG小百分之二三十，更新的AVIF格式还能更小。光是把全站图片转成WebP，弱网用户的图片下载量就能直降一截，这一步性价比极高。

第二，按设备尺寸提供合适大小的图，别让手机下载电脑用的大图。一个常见的浪费是：不管用户屏幕多大，一律推送同一张为大屏准备的高清大图。手机屏幕就那么大，塞给它一张几千像素宽的图，绝大部分像素是浪费的，弱网用户却要为这些用不上的数据买单。用响应式图片的手段（比如srcset配多个尺寸），让浏览器根据设备屏幕自动挑选合适大小的版本，手机就拿手机该用的小图，能省下大量带宽。

第三，老老实实做压缩。很多图片直接从设计稿或相机里导出来就上传了，没经过压缩，藏着大量可以挤掉的水分。用图片压缩工具或自动化的处理流程，在可接受的画质范围内把每张图压到最小，是个一劳永逸的好习惯。关于图片的格式、压缩、命名这些细节，保哥在网站图片SEO优化技巧那篇里讲得很细，这里不展开，但弱网场景下，图片压缩的优先级要再往前提。

第四，懒加载首屏以外的图片。一个页面往往有很多图，但用户一打开只看得到首屏那几张，下面的要滚动才看得到。没必要在一开始就把所有图都下载下来——用懒加载，让首屏外的图片等用户快滚动到时再加载。web.dev — Browser-level image lazy loading（用原生loading属性延迟加载首屏外图片、省带宽的官方指南）说明了用原生的loading属性就能轻松实现这一点，省下的初始带宽对弱网用户意义重大。

但这里有个关键的坑——首屏内的图片绝对不能懒加载，尤其是首屏那张最大的主图，懒加载它会直接拖慢LCP，这点保哥在FAQ里专门讲。

这四步做下来，图片这块的体积通常能压掉一大半。对弱网用户，这意味着页面从转好几秒才出图，变成图片唰地就刷出来了，体验是质变的。所以再强调一遍：弱网优化，从图片开刀，收益最快最猛。

JavaScript在低端机上为什么是性能杀手，怎么减负？

如果说图片是弱网的头号敌人，那JavaScript就是低端机的头号杀手。这两个要分开理解：图片再大，浏览器下载下来显示就行，不怎么费CPU；而JavaScript不光要下载，下载完还得让CPU去解析、编译、执行，这个解析执行的过程，在CPU孱弱的低端机上会慢得令人发指。

具体会发生什么？当大量JavaScript涌进来，低端机的CPU被占满，主线程被一个个长任务堵死。这期间，页面对用户的任何操作都没法响应——你点了按钮，它在忙着跑脚本，没空理你，要等好几百毫秒甚至更久才反应过来。在用户感受上，这就是“这网站怎么点了没用、卡死了”。前面说的INP指标差，根子大多在这。这个主线程被长任务堵塞的机制，正是INP（交互到下一次绘制）恶化的根源，低端机只是把这个问题放大了无数倍。

怎么给JavaScript减负？核心思路是四个字：少、晚、散。

“少”，就是减少JavaScript的总量。最大的水分往往来自第三方脚本——各种分析、客服、弹窗、营销插件，每一个都往页面里塞自己的一坨JS。前面讲应用栈治理时说过，这些第三方脚本是性能的重灾区，能砍的坚决砍，留下的也要审视它值不值这个性能代价。自己写的代码，也尽量精简、别引入用不上的大型库。总量降下来，低端机的CPU负担直接减轻。

“晚”，就是延迟加载非关键的JavaScript。不是所有脚本都得在页面一打开就执行。和首屏渲染、核心交互无关的脚本——比如底部的统计、不在首屏的功能模块——可以用延迟加载的方式，等关键内容渲染完、甚至等用户有交互意图时再加载执行，别在最金贵的首屏阶段跟核心内容抢CPU。

“散”，就是别让单个任务把主线程占太久。把又大又长的JavaScript任务拆成小块，给浏览器留出响应用户操作的空隙，避免一个长任务把主线程一占就是大半秒，用户点啥都没反应。这一步偏技术，但对改善低端机上的卡顿感效果很直接。把“少、晚、散”这三招用上，你的页面在低端机上的“跟手”程度，会明显不一样。

怎么让首屏在弱网下尽快出来，先抓住用户？

弱网用户的耐心是以秒计的，转圈超过几秒，很多人就走了。所以有一个策略性的取舍极其重要：与其让用户对着白屏等整个页面都加载完，不如想尽办法让首屏——用户一打开看到的那一屏——尽可能快地先出来，先抓住他，剩下的边滚边加载。这就是优化关键渲染路径的思路。

要让首屏尽快出来，得先搞清楚什么在挡着它。浏览器要渲染出首屏，需要拿到关键的HTML、CSS，有时还要等字体。这其中任何一个是“渲染阻塞”的、或者下载很慢，首屏就被卡住。优化的方向，就是把首屏真正需要的东西最快送到，把不影响首屏的东西往后推。

第一招，优先保障首屏内容和它的关键样式。把渲染首屏所必需的那部分关键CSS尽早就位（比如内联进HTML），让浏览器拿到HTML就能立刻把首屏画出来，而不用干等一个完整的大样式表下载完。首屏用不到的样式，可以延后加载。哪些算首屏关键内容、怎么排布局，保哥在首屏内容与页面布局机制那篇里有专门的拆解，弱网下，“把价值塞进首屏、让首屏最快出来”这件事的权重要再调高。

第二招，管好字体，别让它拖白屏。如果用了自定义网络字体，弱网下字体文件下载慢，可能导致文字迟迟不显示（白屏等字体）。解决办法是设置合理的字体显示策略（比如让文字先用系统备用字体显示出来，自定义字体到了再替换），别让用户对着没有文字的页面干等。涉及中文字体的还要格外当心体积问题，这点FAQ里细说。

第三招，用骨架屏之类的手段管理等待感知。弱网下加载需要时间是客观现实，但你可以让这个等待不那么难熬。与其显示一片空白或者一个干转的圈，不如先渲染出页面的骨架结构（灰色的占位块，勾勒出内容大概的样子），让用户感觉“它在加载、马上就好”，而不是“它是不是卡死了”。这虽然没真的让加载变快，但显著改善了用户对速度的主观感受，降低了弱网下的跳出。

这三招合起来是一个心法：在弱网下，先让用户看到东西、看到希望，比让他看到完整的页面更重要。首屏抢跑成功，你就争取到了让他继续等下去、继续逛下去的机会；首屏迟迟不出，再好的内容他也看不到了。

弱网的“不稳定”怎么应对，别让用户卡在半路？

前面讲的多是“慢”，但弱网还有一个更难缠的特性——“不稳定”。它不是匀速地慢，而是时快时慢、时断时续，信号好的时候还行，一进电梯、一过隧道、一到信号死角，连接就抖动甚至中断。针对这种不稳定，光做“快”不够，还得做“稳”和“容错”，别让用户在网络抖一下时就卡死在半路、前功尽弃。

第一，把能缓存的尽量缓存下来，减少对网络的依赖。用户第一次访问加载过的资源——比如logo、图标、CSS、JS、字体这些不常变的静态文件——通过合理的缓存策略存在他本地，下次再访问、或者在站内跳转时，就能直接从本地拿，不用再走一遍弱网。这样即便网络抖动，已经缓存的部分照样能用，体验稳得多。更进一步，可以用Service Worker做更主动的缓存控制，甚至让一部分内容在断网时也能展示。

第二，对可能失败的网络请求做容错和重试。弱网下请求失败是常态，不是异常。如果你的页面在一个请求失败后就彻底卡住、白屏、或者报个用户看不懂的错，那体验就崩了。更稳妥的做法是：关键请求失败了，自动悄悄重试一两次；万一确实拿不到，给一个友好的提示和重试按钮，而不是让用户对着卡死的页面发懵。让页面在网络出问题时“优雅地降级”，而不是“粗暴地崩溃”。

第三，避免把太多东西压在一个大请求上。如果你的页面要靠一个巨大的请求一次性把所有数据都拉回来才能显示，那在弱网下，这个大请求一旦慢了或者断了，整个页面就全完了。把数据请求拆细、让页面能分块渐进地展示——核心内容先到先显示，次要内容后到后补上——既能让首屏更快，也能让单个请求失败时的影响面更小，不至于一损俱损。

这一节的思路，和前面追求“快”是互补的：快，是让顺利的时候更顺；稳和容错，是让不顺利的时候不至于全盘崩掉。弱网用户的网络注定会时不时掉链子，你的页面能不能在掉链子时还撑得住、还给用户留条退路，往往就是“勉强能用”和“彻底用不了”的分界线。说到底，给弱网用户做体验，要默认网络是会出问题的，然后为出问题那一刻做好准备。

怎么测出真实海外低端机弱网的体验，而不是自欺欺人？

讲了这么多优化手段，最后必须回到最开始那个盲区——测试。如果你还是只拿旗舰机连快网测，那做再多优化你也不知道效果，甚至不知道还有哪些问题没解决。要让优化真正落地，你得先有办法测出接近真实低端机弱网用户的体验。好在这件事门槛并不高，几种办法搭配着用就够了。

第一，用浏览器开发者工具的双节流。这是最方便、最该养成习惯的一招。Chrome开发者工具里有网络节流和CPU节流：网络节流把你的快网限速成模拟的4G、3G，重现弱网；CPU节流把你的高性能电脑降速成模拟低端设备，重现CPU慢。两个一起开到位，再走一遍你的页面，平时被高配掩盖的卡顿立刻原形毕露。这套不花一分钱，却能解决大部分盲测问题。

第二，用Lighthouse跑移动端审计。Lighthouse（Chrome自带、PageSpeed Insights也在用）跑移动端测试时，默认就是在模拟的移动设备加节流网络下进行的，所以它给的移动端分数本就比你肉眼感受严苛。把它当成一个能纵向对比的体检工具：优化前后各跑一次，看LCP、INP这些指标有没有改善，比凭感觉靠谱得多。它还会直接列出具体的优化建议，照着排查很省事。

第三，条件允许就上真机和现场数据。模拟终究是模拟，和真实的低端安卓机、真实的当地网络还是有差距。条件允许的话，弄一两台目标市场常见型号的真机实测，或者用云端的远程真机测试服务，在接近真实的环境下走一遍关键流程，能逮到模拟器漏掉的问题。更进一步，通过真实用户监控（RUM）和Search Console的核心网页指标报告，看你真实用户在现场的实际指标分布——这是最真实的数据，因为它直接来自你客户的真机真网，不掺一点想象。

这几招的关系是层层逼近真实：开发者工具双节流用于日常快速自查，Lighthouse用于优化前后的量化对比，真机和现场数据用于最终验证真实体验。核心就一条铁律——别再拿你的旗舰机当标准了。你的客户不在你的测试环境里，你得主动把测试环境，调到你客户真实所处的那个又弱又慢的世界里去，优化才有意义。

海外弱网移动端优化最容易踩的5个坑是什么？

最后照例上一份保哥的踩坑清单。这五个坑，是为弱网做优化时最常见的几种栽法，对照着自查，能帮你少走弯路。

坑一：只用高端机快网测，根本没意识到问题存在。这是所有坑的根源，也是最普遍的。你的测试环境太好，把所有性能问题都掩盖了，于是你压根不知道海外低端机弱网用户在经历什么。破解它的唯一办法，就是逼自己用节流工具、用真机，去真实地感受一次客户的卡顿。意识不到问题，谈何解决。

坑二：把首屏图片也加了懒加载，弄巧成拙。懒加载是好东西，但用错地方会坏事。给首屏内、尤其首屏那张主图加懒加载，会让浏览器一开始不去加载它、要显示时才临时拿，直接拖慢LCP。记住懒加载只给首屏以外、需要滚动才看到的图片用，首屏图片要正常甚至优先加载。这是个高频低级错误，对照检查一下你的页面。

坑三：图片不优化，光指望上CDN解决一切。CDN能让资源传得更近更快，但它没法替你把一张几MB的巨图变小，再近的CDN也得把这几MB实实在在塞过弱网。顺序应该是先给图片和资源彻底瘦身、把体积砍下来，再上CDN加速，别本末倒置地指望CDN替你擦屁股。先减重，再加速。

坑四：为了轻量把内容和功能也砍了，矫枉过正。做轻是对的，做残就错了。把页面做精简、砍掉花哨无用的特效是对的，但用户要看的产品图、要读的关键信息、要走的购买流程一样都不能少。轻量化的目标是让真实内容在弱设备上流畅可用，不是用阉割体验去换一个好看的速度分数，砍出一个加载飞快但转化崩盘的页面，是赔本买卖。

坑五：忽略中文等大字体文件这个隐形炸弹。做面向海外的站，如果页面涉及中文等CJK内容又用了自定义字体，要格外当心——一个完整中文字体动辄几MB，砸到弱网上是灾难，却很容易被忽略，因为在你的快网上它一闪就下来了。要么用系统字体，要么做字体子集化只保留用到的字。别让一个被你忽略的字体文件，成了弱网用户打开网站时最大的那块绊脚石。

把这五个坑都避开，再加上前面那套优化，你的独立站在海外低端机弱网下的表现，会和现在判若两站。配套地，先用出海DTC极简设计的8步转化法那篇的思路把设计做克制，弱网优化会事半功倍——因为最快的资源，永远是你根本没加载的那个。

常见问题解答

我没有那些低端安卓机，怎么测真实的弱网卡顿体验？

不用真去买一堆千元机，浏览器开发者工具就能模拟个八九不离十。Chrome开发者工具里有网络节流和CPU节流两个开关：网络节流把你的快网限速成模拟的4G、3G，重现弱网下载慢、延迟高；CPU节流把高性能电脑降速成模拟低端设备（比如4到6倍降速），重现低端机解析执行JavaScript慢的窘境。两个一起开到位再跑一遍页面，平时被高配掩盖的卡顿立刻现形。Lighthouse跑分默认用的也正是模拟移动设备加节流的环境，所以它的移动端分数本就比你肉眼感受的严苛。当然模拟终究是模拟，条件允许就弄一两台目标市场常见型号的真机、或用云端远程真机服务走一遍关键流程，能发现模拟器漏掉的问题。但对多数中小站长，先把双节流用起来，就能解决八成的盲测问题。

图片优化和上CDN，哪个对弱网体验提升更大？应该先做哪个？

两个都重要，但只能先做一个的话，建议先啃图片，投入产出比更高也更可控。CDN解决的是内容离用户更近、传输更快，但你的图片要是几MB的巨无霸，再近的CDN也得把这几MB实实在在塞过弱网管道，用户照样等。而图片优化是从源头砍数据量——把一张2MB的图压成200KB，弱网下载时间直接缩到十分之一，这是任何CDN都替代不了的。理想情况是两个一起做：先用WebP、响应式尺寸、压缩、懒加载把图片彻底瘦身，再上一个在目标客户地区节点充足的CDN就近送达。但资源精力有限时，先做图片瘦身，往往能用最小成本拿到最明显的弱网体验提升。先减重，再加速，顺序别搞反。

为弱网做了一堆优化，会不会反而把高端机用户的体验做差了？

基本不会，恰恰相反，绝大多数弱网优化对高端机用户也是净收益。你想，图片更小、JavaScript更少、首屏更快——这些改进在高端机快网上同样成立，只不过高端用户本来就快，提升的绝对值没那么戏剧化，但页面变轻、变快对他们一样是好事，没有谁会因为页面加载更快而不高兴。真正需要留意的是少数“自适应”手段别做过头：比如根据网络状况给弱网用户发低清图、给快网用户发高清图，这种分级如果实现得糙，可能让高端用户看到的画质打折。但这属于精细化的取舍，做的时候把握好分寸、给好网络足够好的版本就行，不是不做弱网优化的理由。保哥的态度很明确：性能优化的大方向上，弱网和高端机的利益是一致的，让最弱的设备能用，强设备只会更爽，不存在“为了照顾穷设备牺牲富设备”这种伪矛盾。

新兴市场用户网络这么差，是不是干脆做个超级精简的版本就行了？

做轻是对的，但别走到“做残”那个极端。把页面做精简、做轻量，砍掉花哨无用的特效、删掉用不上的第三方脚本、让设计回归克制，这个方向完全正确，弱网用户会感激你。但精简不等于把内容和功能阉割掉——用户要看的产品图、要读的关键信息、要走的购买流程，一个都不能少，少了就不是快不快的问题，是能不能成交的问题了。正确的做法是“该有的都有，但每一样都做到最轻”：图片该展示还展示，只是用最优格式压到最小；功能该提供还提供，只是把实现做到最省资源；首屏该传达的价值一点不缺，只是用最快的方式先送达。保哥见过有人矫枉过正，为了极致轻量把产品详情砍得七零八落，结果加载是快了，转化反而崩了，得不偿失。轻量化的目标是让真实的内容和功能在弱设备上流畅可用，不是用牺牲体验去换一个好看的速度分数。

懒加载是不是把所有图片都加上loading=lazy就万事大吉了？

方向对，但有个关键细节很多人做反了——首屏内的图片千万别懒加载。懒加载的原理是延迟加载那些首屏外、用户暂时看不到的图片，等用户滚动到附近再加载，这样能省下初始加载的带宽，对弱网帮助很大。但如果你无脑地给页面上所有图片都加上lazy，包括首屏最顶部那张最大的主图，反而会坏事：浏览器一开始不去加载它，等到要显示时才临时去拿，首屏最重要的那个元素就被推迟了，LCP（最大内容绘制）不升反降。正确的做法是分清楚——首屏内、用户一打开就看到的关键图片，让它正常优先加载，甚至可以用预加载提示让它更快；首屏以下、需要滚动才看到的图片，才加lazy延迟加载。简单说，懒加载是给“看不见的”图片用的，给“一眼就看到的”图片用，等于自己拖自己后腿。这个边界划对了，懒加载才是弱网下的利器。

字体加载会拖慢弱网体验吗？中文站要注意什么？

会，字体在弱网下是个容易被忽略的拖累，尤其涉及非系统字体时。原理是：用了自定义网络字体，浏览器要先下载字体文件才能渲染文字，弱网下这个下载很慢，期间可能出现两种尴尬——文字先不显示、等字体到了才出现（白屏一段，叫FOIT），或先用系统字体顶上、字体到了再替换（闪一下，叫FOUT）。处理办法是设置合理的font-display策略（一般用swap，让文字先用备用字体显示，别让用户对着空白等），并尽量精简、只加载真正用到的字重。但涉及中文等CJK内容要格外当心：中文字体动辄几MB，一个完整字体包砸到弱网上是灾难，要么用系统字体，要么做字体子集化——只把页面用到的字打成一个很小的子集。别让一个字体文件，成了弱网用户打开网站时最大的那块石头。

权威参考资料