惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

J
Java Code Geeks
GbyAI
GbyAI
Google DeepMind News
Google DeepMind News
Jina AI
Jina AI
B
Blog
aimingoo的专栏
aimingoo的专栏
酷 壳 – CoolShell
酷 壳 – CoolShell
T
The Blog of Author Tim Ferriss
Last Week in AI
Last Week in AI
月光博客
月光博客
H
Help Net Security
V
Visual Studio Blog
量子位
A
About on SuperTechFans
博客园 - Franky
人人都是产品经理
人人都是产品经理
N
Netflix TechBlog - Medium
云风的 BLOG
云风的 BLOG
雷峰网
雷峰网
Martin Fowler
Martin Fowler
Microsoft Security Blog
Microsoft Security Blog
博客园 - 叶小钗
P
Proofpoint News Feed
MongoDB | Blog
MongoDB | Blog

CloudCannon Blog

Building with AI: Git-based vs headless vs traditional CMS CloudCannon + Astro: performance meets powerful content management Introducing the Astro Component Starter Introducing Jetstream — built on the Astro Component Starter Redesigning CloudCannon’s docs with Diátaxis, Lume, and Pagefind Make content editing more visual: upgraded Editable Regions How Configuration Mode makes building editing interfaces easy Your hosting just got an upgrade (and a price cut) Custom testing domains for professional branding Keep your content consistent with input validation Managing multilingual content in CloudCannon Simplify team publishing with conflict resolution and domain tools Open Beta: Publishing Conflict Resolution Getting started with CloudCannon and Astro: Bookshop, components, and live editing Welcome to the CloudCannon Community! Omnichannel delivery is just marketing spin from API-based CMS companies Getting started with CloudCannon and Astro: Snippets and Collections Managing digital assets in CloudCannon: a guide to smart asset storage Understanding CloudCannon's branching workflows and Projects: a complete guide What is a static website? CloudCannon’s 2024 wrapped Getting started with CloudCannon and Astro: WYSIWYG blogging Jamstack vs. WordPress: reasons to make the change The top five static site generators for 2025 (and when to use them!) Free Jekyll themes for 2025: ten great community options Eleventy (11ty) vs. Hugo How to set up WYSIWYG editing with MkDocs Material The rise of static-first websites: why major brands are making the switch Watching your Core Web Vitals on Jamstack Understanding the difference between static, dynamic, and hybrid websites
Why we switched to the system font stack
2026-03-08 · via CloudCannon Blog

A couple of weeks ago, a small bug report turned into a typography upgrade we’d been meaning to make for a while.

Our support team received an issue flagging that bold and normal text were indistinguishable inside headers within CloudCannon. The fix was straightforward in theory — either install an additional weight of our custom font or switch to the system font stack. We’d been leaning toward the system font stack for some time, and this felt like the right moment to make the move.

All the font weights, out of the box Direct link to this section

Custom web fonts require deliberate choices about which weights to load. Load too few and you end up with exactly the kind of bold-vs-normal ambiguity we ran into. Load them all and you’re shipping a lot of font data your users may never need. System fonts sidestep this entirely — every weight is already there, ready to use, with no decisions required on our end.

Better performance, fewer loading artefacts Direct link to this section

Web fonts mean HTTP requests, waiting, and a flash of unstyled content that appears while a font file travels over the network and gets parsed by the browser. On a fast connection, this is a minor annoyance. On a slow or metered connection — the kind common in many parts of the world — it’s a real friction point.

With system fonts, there's nothing to download. The font is already on the device. Pages render immediately, in the right typeface, every time.

And this wasn’t entirely new territory for us. We switched our monospace font to a system stack a while ago, and the result was fewer rendering issues overall. That experience gave us confidence that extending the same approach to the rest of the UI was the right call.

Broader Unicode coverage for international users Direct link to this section

Custom fonts often have incomplete Unicode coverage. For users working with non-Latin scripts — Arabic, Chinese, Japanese, Korean, Devanagari, and many others — gaps in a custom font can mean garbled or missing characters. System fonts, maintained by OS vendors with global user bases in mind, typically offer far more comprehensive Unicode support. For our international customers, this is a meaningful improvement.

A more accessible, readable experience Direct link to this section

System fonts carry accessibility advantages that are difficult to replicate with custom typefaces.

Many users rely on OS-level font settings to manage reading difficulties — increasing text size, enabling high contrast modes, or substituting fonts that work better for conditions like dyslexia. Custom web fonts can interfere with these adjustments, either by overriding user preferences or by rendering in ways that conflict with assistive technologies. System fonts, being native to the OS, tend to respect these settings naturally.

There's also the matter of rendering quality. System fonts are hinted and optimised by the OS vendor specifically for screen rendering on that platform — meaning they render with maximum clarity at every size, on every display, for every user. Custom fonts, however well-designed, can't match that level of platform-specific tuning across every device and screen density your users might have.

For users with low vision, the difference between a font that renders crisply at small sizes and one that doesn't can determine whether an interface is usable at all.

Because system fonts are the typefaces people read in their email client, their file manager, their operating system's own dialogs. When an app uses them too, it feels like it belongs on the device rather than being layered on top of it. There’s something meaningful about seeing an interface rendered in a font you already know.

That familiarity has practical implications for readability. People read faster and more accurately in typefaces they encounter regularly: a font that feels native is a font that gets out of the way.

In good company Direct link to this section

The trend toward system fonts has been building for years. GitHub made the switch. Notion made the switch. The reasoning is the same across the board: system fonts perform better, render more reliably, and feel more at home on the devices people use every day.

For us, what started as a fix for a single header bug turned into a cleaner, faster, more accessible UI.