设计与产品meowni.ca
Web 字体，老实说我也不知道
Web fonts, boy, I don't know
2016 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇博文讨论网页字体带来的现实麻烦：自定义字体让页面变重，慢速连接下加载迟缓和字体闪烁会影响阅读，作者在美观与性能、用户体验之间提出疑问。文章也涉及是否改用系统字体、如何权衡设计效果与页面负担。
为什么经久不衰：网页字体带来的页面重量和渲染闪烁问题至今仍在，文中讨论的取舍以及评论里补充的 font-display、子集化等方案仍有参考价值。
HN 评论精选
慢连接下 web 字体弊大于利，作者希望有原生按网速条件加载的机制，并推荐系统字体。
我上个月就有完全一样的体验。在慢速连接下，我越来越讨厌 web 字体。它们本身没什么问题，只是已经成了过度放纵的象征，也代表一种只重美观、忽视用户实际任务需求的短视。部分问题在于慢速连接下的渐进增强。你怎么解决？据我所知没有不依赖 JS 的原生浏览器 API，这不理想。希望能给 script 和 link 标签加一个根据连接速度生效的条件属性。另外也建议有选择的人用系统字体而不是 web 字体，这更符合 Web 精神，而且系统字体通常经过充分测试。
mouzogu查看英文原文
I have had the exact experience in the last month. Being on a slow connection, I've come to loath web fonts. There is nothing wrong with them in general but it's just that they've come to symbolise over-indulgence and a myopia towards the users actual task-focused needs as opposed to aesthetics. Part of the issue is dealing with progressive enhancement as far as slow internet connections go. How do you solve that problem? There is no native browser API to my knowledge that does not depend on using JS which isn't ideal imo. Would love an attribute on script and link tags that could be conditional based on connection speeds. P.S Would also encourage those who have the choice to use system fonts (https://medium.design/system-shock-6b1dc6d6596f) instead of web fonts. Seems more in-line with the spirit of the web and these fonts are very well tested in general.
FOUC 在快连接下也很烦，需要在快慢连接之间找折中，浏览器和工具需改进。
是的，web 字体在慢连接下常常很糟。但在较快连接下，我又觉得 FOUC（先显示后备字体再切换）很烦。那 1–2 秒先看到 Times/Helvetica，再变成 Freight Text Pro/Proxima Nova，让我抓狂。我认为在快连接下的 FOUC 和慢连接下令人愤怒的 FOIC 之间一定有个折中点。不幸的是，大多数开发者（包括我）不常在不同网速下测试网站，所以字体动态效果调得很差很常见。底线：作为在意设计和视觉体验的人，我不认为答案就是接受并忍受处处 FOUC；浏览器和开发工具都需要改进以找到折中点。
jaredcwhite查看英文原文
Yes, web fonts often suck on slow connections. Meanwhile, on fast-ish connections, I find the FOUC effect to be greatly annoying. That 1-2 seconds of seeing Times and Helvetica and then seeing Freight Text Pro and Proxima Nova drives me bonkers. I think there must be some kind of happy medium between FOUC for faster connections and rage-inducing FOIC for slow connections. Unfortunately, most devs (and sadly I claim to be one) don't test their sites frequently on a range of connection speeds so it's common to have badly-tuned font dynamics on sites. Bottom line: as someone who cares about design and visual experiences, I don't think the answer is just accept and live with FOUC everywhere. Browsers and dev tooling both need to improve in order to find that happy medium.
即使设计标杆 Stripe 的首页也被 web 字体占据大量体积，说明美观有成本。
HN 上常有人夸 Stripe 的页面好看、功能清晰、设计好。但 Stripe 首页有 75% 是 web 字体（432k）。
metafunctor查看英文原文
The HN crowd frequently compliments Stripe on their good looking, functional, well designed web pages. The Stripe home page is 75% web fonts (432k).
文章已过时，font-display: fallback 和字体子集化能在体积/渲染之间取得不错平衡。
这篇文章有点过时了，标题大概应该加上“(2016)”。如今可以用 font-display: fallback，它在各种取舍之间是比较合理的平衡：1）先等很短时间（100ms）让字体加载，暂不渲染；2）如果字体还没加载就用系统字体把页面显示出来，并继续再加载字体 3 秒；3）字体加载后替换，或者没加载就继续用系统字体。如果 web 字体足够小（我站点上约 16k，斜体和粗体各三倍，总共约 50k），即使在较慢的 2G 连接下效果也不错。我还会删掉未使用的码点，能大幅减小体积；我的情况从约 150k 降到约 50k。我有个小脚本扫描目录里所有文本文件并删掉不存在的码点：https://github.com/arp242/ttftrim
arp242查看英文原文
This article is a little bit outdated; should probably add "(2016)" to the title. These days you can use "font-display: fallback" and that's a fairly reasonable trade-off between all the various things: 1. Wait very briefly (100ms) for the font to load, don't render anything yet. 2. If the font hasn't loaded then use a system font and render the page visibly, keep loading the font for another 3 seconds. 3. Substitute the font once it's loaded, or just continue with the system font if it's not. If the webfont is small enough (~16k on my site, times three for italics and bold, ~50k in total) then this works quite well even on slower 2G connections. One thing I also do is remove unused codepoints, which can reduce the size quite a bit. In my case, it reduced the size from ~150k to ~50k. I have a little script that just scans all text files in a directory and removes and codepoints that don't exist: https://github.com/arp242/ttftrim
历次讨论
同类还值得读
贝塞尔曲线入门
A Primer on Bézier Curves
Pomax 编写的贝塞尔曲线在线教程，从基础概念一路讲到曲线求交、投影、曲率等进阶内容，并配有可交互的示例和配套的 bezier.js 库。
设计与产品上首页 7 次 · 2014–2022pomax.github.io编辑精选WebGL 水面模拟
WebGL Water
Evan Wallace 制作的 WebGL Water 演示：在浏览器里实时渲染一片水面，展示折射、反射和焦散等 GPU 图形效果。
设计与产品上首页 6 次 · 2011–2025madebyevan.com设计建议：永远不要使用黑色
Design Tip: Never Use Black
设计随笔提出“永远不要用纯黑”的建议，主张在界面和绘画中改用深灰或带色相的暗色，并借阴影与色彩关系来论证。
设计与产品上首页 5 次 · 2012–2021ianstormtaylor.com用于思考不可想象之物的媒介
Media for Thinking the Unthinkable
Bret Victor 的这个页面围绕《Media for Thinking the Unthinkable》展开，探讨我们用来思考和表达复杂问题的媒介，以及以文字/符号为主的传…
设计与产品上首页 5 次 · 2013–2020worrydream.com编辑精选页面重量很重要
Page Weight Matters
博文讲 YouTube 工程师 Chris Zacharias 的一次页面瘦身实验：团队做了一个更轻量的页面版本，起初从整体平均加载时间看反而更慢；按地理区域分层后才发现，轻量版…
设计与产品上首页 4 次 · 2012–2022blog.chriszacharias.com