When using web fonts we must carefully avoid its hidden pitfalls. To do this designers, frontend developers, DevOps, and authors each have a role to play in creating a great end-user experience.

使用網絡字體時，必須小心避免其隱藏的陷阱。 為此，設計師，前端開發人員，DevOps和作者在創造出色的最終用戶體驗中均應發揮作用。

• Designers need to establish font stacks that can realistically be delivered to users over restricted bandwidths.
  設計人員需要建立字體棧，以便可以在有限的帶寬上實際交付給用戶。
• Frontend developers need to pay attention to CSS rules that can speed things up.
  前端開發人員需要注意加快速度CSS規則。
• DevOps needs to make sure font files are fetched at the right time, and cached aggressively once downloaded.
  DevOps需要確保在正確的時間獲取字體文件，并在下載后積極緩存。
• Content authors need to let everyone else on the team know about special glyphs and foreign language character sets that they use.
  內容作者需要讓團隊中的其他所有人知道他們使用的特殊字形和外語字符集。

Here are some practical tips and strategies for getting fast accurate typography using real-world network bandwidths.

這里有一些實用的技巧和策略，可以使用實際的網絡帶寬來獲得快速準確的排版。

@ font-face規則 (The @font-face rule)

Let’s begin with a typical example. The designer chooses a typeface for their website articles with a careful eye for readability. The designer then declares the typeface, size, leading, white space, and color using CSS like this:

讓我們從一個典型的例子開始。 設計師為網站文章選擇字體時要特別注意可讀性。 然后，設計人員使用CSS聲明字體，大小，前導，空格和顏色，如下所示：

article {
    font-family: 'Source Serif Pro', serif;
    font-size: 12pt;
    line-height: 1.4;
    margin: 1rem;
    color: hsl(0,0%,15%);
    background-color: hsl(0,0%,85%);
}

In order to implement this, the frontend developer specifies @font-face rules like this:

為了實現這一點，前端開發人員指定了@ font-face規則，如下所示：

@font-face {
  font-family: 'Source Serif Pro';
  font-weight:  400;
  font-style:   normal;
  font-display: block;
  src: local('SourceSerifPro-Regular'),
       url('/fonts/source-serif-pro-400-latin.woff2')
       format('woff2');
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC,
                 U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074,
                 U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215,
                 U+FEFF, U+FFFD;
}
@font-face {
  font-family: 'Source Serif Pro';
  font-weight:   400;
  font-style:   italic;
  font-display: swap;
  src: local('SourceSerifPro-It'),
       url('/fonts/source-serif-pro-400-italic-latin.woff2')
       format('woff2');
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC,
                 U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074,
                 U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215,
                 U+FEFF, U+FFFD;
}
@font-face {
  font-family: 'Source Serif Pro';
  font-weight:  600;
  font-style:   normal;
  font-display: swap;
  src: local('SourceSerifPro-Semibold'),
       url('/fonts/source-serif-pro-600-latin.woff2')
       format('woff2');
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC,
                 U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074,
                 U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215,
                 U+FEFF, U+FFFD;
}

At first glance, this looks like an excessive ruleset just for a simple CSS declaration. So let’s examine each property to understand what’s possible.

乍一看，這看起來像一個過多的規則集，僅用于簡單CSS聲明。 因此，讓我們檢查每個屬性以了解可能的情況。

For all three rules, the font-family is the same. It matches the name specified in the CSS declaration.

對于所有三個規則， font-family是相同的。 它與CSS聲明中指定的名稱匹配。

It’s the font-weight and font-style properties that are the telling difference.

區別在于font-weight和font-style屬性。

• The first rule is used for plain text, it specifies a regular font weight (400) and a normal font style.
  第一條規則用于純文本，它指定常規字體粗細(400)和常規字體樣式。

• The second rule specifies an italic font style. It will be used by the browser for HTML text marked with the <i> or <em> tags, or with the font-style: italic CSS property.

  第二條規則指定斜體字體樣式。 瀏覽器將使用它來標記帶有<i>或<em>標記或帶有font-style: italic CSS屬性HTML文本。

• The third rule specifies a heavier font weight (600). It will be used by the browser for HTML text marked with the <b> or <strong> tags, or with the font-weight: bold CSS property.

  第三條規則指定較重的字體粗細(600)。 瀏覽器將使用它來標記帶有<b>或<strong>標簽或帶有font-weight: bold CSS屬性HTML文本。

When the italic and bold typefaces don’t need to be precise, and download times need to be optimized, the second and third rules can be dropped. In that case, the browser will attempt to render its own approximation of italic and bold by simply distorting the outline of the true font. In some cases this may be good enough.

當斜體和粗體字不需要精確且下載時間需要優化時，可以刪除第二和第三條規則。 在這種情況下，瀏覽器將通過簡單地扭曲真實字體的輪廓來嘗試呈現其自己的斜體和粗體近似值。 在某些情況下，這可能已經足夠了。

But when the typeface can’t be suitably rendered that way, the frontend developer can still optimize the website for fast downloads by using the font-display property. A value of swap instructs the browser to prerender the text the best it can, then rerender it correctly when the font file becomes available. This makes the text visible to the user sooner, but may cause a small "flash of unstyled text" (FOUT). In the example, the italic and bold rules use this approach.

但是，當無法以這種方式正確顯示字體時，前端開發人員仍然可以使用font-display屬性來優化網站以進行快速下載。 swap的值指示瀏覽器以最佳的方式呈現文本，然后在字體文件可用時正確地呈現文本。 這樣可以使用戶更早地看到文本，但是可能會引起小的“未樣式化文本閃爍”(FOUT)。 在示例中，斜體和粗體規則使用此方法。

By way of contrast, a value of block instructs the browser to temporarily hold off rendering the text until the font file becomes available. When this happens within a reasonable amount of time it's rendered in its precise form without any FOUT. But if the font file download is delayed too long the browser is supposed to temporarily do the best it can, rerendering if and when the actual font becomes available. In the example, the first rule, for regular plain text, uses this approach.

相比之下， block值指示瀏覽器暫時推遲渲染文本，直到字體文件可用為止。 當這種情況在合理的時間內發生時，將以其精確的形式呈現而沒有任何FOUT。 但是，如果字體文件下載延遲太長時間，則瀏覽器應該暫時盡其所能，并在實際字體可用以及何時可用時重新呈現。 在示例中，對于常規純文本，第一個規則使用此方法。

Two other font-display values are possible (but not shown in the example). First, a value of fallback instructs the browser to briefly render the text with a fallback font, waiting just a short time to obtain the actual font. If it can be obtained quickly enough (within 3 seconds), the text is rerendered with the actual font. But if it can not be obtained within that time-frame, it must simply give up trying and stick with the fallback.

其他兩個font-display值也是可能的(但示例中未顯示)。 首先， fallback值指示瀏覽器使用后備字體簡短地呈現文本，僅等待一小段時間即可獲取實際字體。 如果可以足夠快地(在3秒鐘之內)獲得它，則將使用實際字體重新渲染文本。 但是，如果無法在該時間范圍內獲得，則必須放棄嘗試并堅持使用后備。

Finally, a value of optional instructs the browser to give up immediately if the font isn't available when first needed, and permanently render the text with a fallback of its choice.

最后， optional的值指示瀏覽器在首次需要該字體時如果不可用，則立即放棄，并使用其后備選項永久呈現該文本。

The next part of each @font-face rule — the src property — specifies where to look for the font file. One or more locations may be provided. If there is any chance that it might be preinstalled on the user's device, use the local() keyword to tell the browser to look for it by name.

每個@ font-face規則的下一部分src屬性-指定在哪里尋找字體文件。 可以提供一個或多個位置。 如果有可能將其預安裝在用戶的設備上，請使用local()關鍵字告訴瀏覽器按名稱查找。

The more typical scenario though, is to use the url() keyword. This syntax will trigger a network request to fetch the specified file (but only if and when it's needed).

但是，更典型的情況是使用url()關鍵字。 該語法將觸發網絡請求以獲取指定的文件(但僅在需要和何時需要時)。

It is perfectly acceptable to specify a URL that points to a third party provider like https://fonts.gstatic.com (Google Fonts). But this approach can sometimes lead to unexpected delays, causing your website to compete with every other website using that service. For more predictable behavior, that is under your control, consider hosting these files on your own servers.

完全可以指定一個指向第三方提供程序的URL，例如https://fonts.gstatic.com (Google字體)。 但是這種方法有時會導致意外的延遲，從而導致您的網站與使用該服務的所有其他網站競爭。 對于更可預測的行為，這在您的控制之下，請考慮將這些文件托管在您自己的服務器上。

The format() keyword specifies the encoding and compression of the font file. All modern browsers support the new Web Open Font Format, so there's very little reason to use older TTF or EOT formats anymore. And be sure to specify WOFF2 which optimizes glyph compression using the new brotli compression scheme.

format()關鍵字指定字體文件的編碼和壓縮。 所有現代瀏覽器都支持新的Web開放字體格式，因此，幾乎沒有理由再使用舊的TTF或EOT格式。 并確保指定WOFF2，它可以使用新的brotli壓縮方案優化字形壓縮。

The last part of each @font-face rule — the unicode-range property — specifies which Unicode code points have actual glyph definitions within the font file. This is a natural language optimization that some font foundries provide for typefaces that cover more than just the ASCII character set.

每個@ font-face規則的最后一部分( unicode-range屬性)指定字體文件中哪些Unicode代碼點具有實際的字形定義。 這是一種自然語言優化，某些字體代工廠提供的字體不僅僅包含ASCII字符集。

For example, if your font file has Greek characters it might only have glyphs defined for code points U+0370-03FF. Or for example, Cyrillic might only have glyphs defined for code points U+0400-045F, U+0490-0491, U+04B0-04B1, U+2116.

例如，如果您的字體文件包含希臘字符，則它可能僅具有為代碼點U+0370-03FF定義的字形。 例如，西里爾字母可能只為代碼點U+0400-045F, U+0490-0491, U+04B0-04B1, U+2116定義了字形。

By providing separate font-face rules with unicode-range this way, you can leave it up to the browser to decide which font files to fetch based on the actual text on each web page.

通過以這種方式為unicode-range提供單獨的字體規則，您可以將其留給瀏覽器，以根據每個網頁上的實際文本來決定要提取的字體文件。

One final note about @font-face rules. Because font files are only fetched by the browser when needed, it is quite common to have one set of @font-face rules that cover every possible need for an entire website. There is no need to hand-craft different rules for each page.

關于@ font-face規則的最后一點說明。 因為僅在需要時才由瀏覽器獲取字體文件，所以使用一組@ font-face規則來覆蓋整個網站的所有可能需求是很常見的。 無需為每個頁面手工制定不同的規則。

預加載字體 (Preloading fonts)

Web font files need to be fetched before being used. The browser does this automatically, as needed, using its internal algorithm for matching the glyphs on a page and the CSS rules for those glyphs. This algorithm is not exposed to the developer, so there is no direct way of tweaking it.

使用Web字體文件之前，需要先將其提取。 瀏覽器會根據需要使用其內部算法來自動執行此操作，以將頁面上的字形與這些字形CSS規則進行匹配。 該算法未向開發人員公開，因此沒有直接的方法來進行調整。

But oftentimes this on-demand fetching mechanism isn’t quick enough to prevent the annoying flash of unstyled text. One strategy to deal with this is HTML’s preload protocol. Here's how the frontend developer can instruct the browser to preload the three fonts of the previous example:

但是通常，這種按需獲取機制不夠快，無法阻止煩人的未樣式化文本閃爍。 解決此問題的一種策略是HTML的preload協議。 這是前端開發人員如何指示瀏覽器預加載上一個示例的三種字體的方法：

<head>    
    <link href='/fonts/source-serif-pro-400-latin.woff2'
                rel=preload as=font type=font/woff2 crossorigin />
    <link href='/fonts/source-serif-pro-400-italic-latin.woff2'
                rel=preload as=font type=font/woff2 crossorigin />
    <link href='/fonts/source-serif-pro-600-latin.woff2'
                rel=preload as=font type=font/woff2 crossorigin />
</head>

In this code snippet, the rel=preload attribute instructs the browser to prioritize the download of these files over all others. So these three will be requested before any scripts, stylesheets or images. This is the most important secret for preventing the flash of unstyled text.

在此代碼段中， rel=preload屬性指示瀏覽器優先于所有其他文件下載這些文件。 因此，將在任何腳本，樣式表或圖像之前請求這三個文件。 這是防止閃爍未樣式的文本的最重要的秘密。

HTML’s link tag can be used for many other things, but the as=font attribute is to be used only for @font-face rules. It instructs the browser to follow the content security policy for fonts and to send an accept request header that servers will correctly interpret.

HTML的link標記可以用于許多其他用途，但是as=font屬性僅用于@ font-face規則。 它指示瀏覽器遵循字體的內容安全策略，并發送服務器將正確解釋的accept請求標頭。

The type=font/woff2 attribute is the corresponding content-type response header that the browser expects to see on the file it obtains. Together with as=font these two prevent accidental and malicious misuse of the preload instruction.

type=font/woff2屬性是瀏覽器希望在獲取的文件上看到的相應的content-type響應標頭。 這兩個與as=font一起可以防止意外和惡意濫用預加載指令。

Finally, the crossorigin attribute is required when preloading fonts, regardless of whether it comes from the website's host itself or a third-party host.

最后，在預加載字體時，必須使用crossorigin屬性，而不管它是來自網站的宿主本身還是第三方宿主。

Two important points about this strategy. First, don’t overdo it — not every @font-face rule needs this priority treatment. Consider using it only for titling and places where large blocks of text are a significant part of the web page experience. And remember that the browser will still load all others in due course. When italicized and heavyweight font variants only serve to emphasize words and short phrases, a short delay in their final rendering will often be unnoticeable.

關于此策略的兩個要點。 首先，不要過度使用它-不是每個@ font-face規則都需要這種優先處理。 考慮僅將其用于標題和大塊文本是網頁體驗重要組成部分的地方。 請記住，瀏覽器仍會在適當時候加載所有其他瀏覽器。 當斜體和重量級字體變體僅用于強調單詞和短短語時，其最終渲染中的短暫延遲通常不會引起注意。

Second, double-check to make sure that any preloaded font files are actually used. It’s counterproductive to have users wait for a font file that is not going to be used. When putting this strategy in place be sure to examine the Chrome DevTools Console for warnings similar to this:

其次，仔細檢查以確保實際使用了任何預加載的字體文件。 讓用戶等待將不使用的字體文件會適得其反。 采取這種策略時，請務必檢查Chrome DevTools控制臺是否存在類似以下的警告：

The resource /fonts/source-serif-pro-400-latin.woff2 was preloaded using link preload but not used within a few seconds from the window's load event. Please make sure it wasn't preloaded for nothing.

字形子集 (Glyph subsets)

Web fonts can be used for special purposes other than general text content and titling. For example, the well-known Font Awesome project contains a collection of popular icons that are packaged as a font file. Typically, most web pages that use Font Awesome only need a small subset of the approximately 1600 icons that each font file contains, so downloading a large file just to get a couple of icons is inefficient.

Web字體可用于特殊目的，而不是常規文本內容和標題。 例如，著名的Font Awesome項目包含打包為字體文件的流行圖標的集合。 通常，大多數使用Font Awesome的網頁只需要每個字體文件包含的大約1600個圖標中的一小部分，因此僅下載大文件以獲取幾個圖標效率低下。

This is where font subsetting is useful. The idea is to create a font file that only contains the glyphs that are needed. To accomplish this, a tool like pyftsubset is used. It opens an existing font file, copies the SVG outlines of the chosen glyphs, and repackages the result in a brand new font file.

這是字體子設置有用的地方。 這個想法是創建一個僅包含所需字形的字體文件。 為此，使用了pyftsubset之類的工具。 它會打開一個現有的字體文件，復制所選字形的SVG輪廓，然后將結果重新打包為一個全新的字體文件。

This same technique can be used with any appropriately licensed font file. For example, the splash page for Я?A? WЯ?T? TΘΘL? chose to render its title font in graffiti-style lettering to match its crazy/cool skateboarder theme. But instead of using an alternate typographic face, the website stuck with the designer’s choice (Source Sans Pro) and simply swapped in non-latin glyphs for R, E, D, I, O and S. The final font subset contains just 20 glyphs packed into a 5Kb file.

相同的技術可以與任何適當許可的字體文件一起使用。 例如， Я?A?WЯ?T?TΘΘL?的初始頁面選擇以涂鴉樣式的字體呈現其標題字體，以使其瘋狂/酷酷的滑板手主題與其匹配。 但是，該網站沒有使用替代的印刷字體，而是停留在設計師的選擇之下(Source Sans Pro)，只是將非拉丁字形替換為R，E，D，I，O和S。最終的字體子集僅包含20個字形。打包成5Kb文件。

Yes, this type of optimization is a lot of extra work. Still, it can be worth it when trying to deliver a resource-heavy website over constrained networks such as mobile cell-towers.

是的，這種優化是很多額外的工作。 盡管如此，試圖過約束網絡，如移動蜂窩塔提供一個資源型重網站時，它可以是值得的。

快取 (Caching)

Once a font file has been obtained, it should be cached on the client’s device. Since font files change rarely, if ever, they should be treated as a static resource. DevOps should configure the server to cache these files for a maximum amount of time. One year is a good rule to follow. Configure the server to set the response header like this:

獲取字體文件后，應將其緩存在客戶端設備上。 由于字體文件很少更改(如果有的話)，因此應將它們視為靜態資源。 DevOps應將服務器配置為在最大時間內緩存這些文件。 遵循一年是一個好規則。 配置服務器以設置響應標頭，如下所示：

cache-control: max-age=31536000

If the font foundry issues an updated version within that period, use any of the traditional cache-busting techniques that are available. But of course, only if the new file contains new glyphs that your content authors need.

如果字體代工廠在此期間發布更新版本，請使用任何可用的傳統緩存清除技術。 但是，當然，只有當新文件包含內容作者需要的新字形時，才可以。

服務器推送 (Server push)

DevOps may be tempted to help things along by using speculative push. This new protocol is available with HTTP/2. It works by sending targeted resources to the browser before the browser requests them.

DevOps可能會嘗試使用推測性推送來幫助解決問題。 此新協議可用于HTTP / 2。 它通過在瀏覽器請求目標資源之前向其發送目標資源來工作 。

Speculative push was a much hyped solution to the problem of resource optimization. The reality is that it fares no better than the link rel=preload solution outlined above. Benchmark tests prove the point. Read all about it here.

投機推送是對資源優化問題的大肆宣傳解決方案。 現實情況是，它的性能并不比上面概述的link rel=preload解決方案好。 基準測試證明了這一點。 在這里閱讀所有內容。

替換字形 (Replacement glyphs)

Content authors may be blissfully unaware of all the details just covered, and may inadvertently run into trouble. Remember, every font file contains a limited set of glyphs. So when the author uses a glyph that is not in the chosen font family the browser tries its best to find an alternative. This often leads to unsightly replacements.

內容作者可能非常高興地沒有意識到剛剛涵蓋的所有細節，并且可能會無意中遇到麻煩。 請記住，每個字體文件都包含一組有限的字形。 因此，當作者使用不在所選字體系列中的字形時，瀏覽器將盡最大努力尋找替代字形。 這通常導致難看的替換。

For example, if the author is writing about Bosnian politician ?efik D?aferovi?, then the rules we’ve defined above won’t work. Instead, the browser will obligingly use ?, ?, and ? from some other serif font that it has access to. That replacement might be good enough on the author’s computer, but may be completely different on a random reader’s computer.

例如，如果作者正在撰寫有關波斯尼亞政治人物?efikD?aferovi?的文章，那么我們上面定義的規則將行不通。 取而代之的是，瀏覽器將強制使用它可以訪問的其他襯線字體中的?，?和?。 這種替換在作者的計算機上可能足夠好，但在隨機讀者的計算機上可能完全不同。

If the designer has chosen a “pro” font family that has an extended set of glyphs, the solution is simple: specify an additional @font-face rule with a unicode-range that covers U+0160, U+017E and U+0107. Thus, extending the original example we might add the "latin-ext" font file to our ruleset like this:

如果設計人員選擇了具有擴展字形集的“ pro”字體家族，則解決方案很簡單：指定一個附加的@ font-face規則，其unicode-range覆蓋U + 0160，U + 017E和U + 0107 。 因此，擴展原始示例，我們可以將“ latin-ext”字體文件添加到規則集中，如下所示：

@font-face {
  font-family: 'Source Serif Pro';
  font-weight:  400;
  font-style:   normal;
  font-display: block;
  src: local('SourceSerifPro-Regular'),
       url('/fonts/source-serif-pro-400-latin-ext.woff2')
       format('woff2');
  unicode-range: U+0100-024F, U+0259, U+1E00-1EFF, U+2020,
                 U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F,
                 U+A720-A7FF;
}

豆腐和后備字體 (Tofu and fallback fonts)

Sometimes an author may use esoteric glyphs that render reasonably well on their own computer, but that completely fail on the reader’s computer. This may happen for example when the author is writing on a computer with the newest hardware and operating system, but the reader is on a different hardware or older software that knows nothing about those glyphs.

有時，作者可能會使用深奧的字形，這些字形在他們自己的計算機上可以很好地呈現，但是在讀者的計算機上完全無法使用。 例如，當作者在具有最新硬件和操作系統的計算機上進行書寫，而閱讀器在對這些字形一無所知的其他硬件或較舊的軟件上書寫時，可能會發生這種情況。

We sometimes mistakenly think of Unicode as being the miraculous solution to these types of problems, but remember that Unicode is a living standard. New versions with additional code points are added on a regular basis.

有時我們會錯誤地認為Unicode是解決這些類型問題的奇跡，但請記住Unicode是生活標準。 帶有附加代碼點的新版本會定期添加。

When this unfortunate circumstance occurs, the reader may discover “tofu” characters sprinkled into the text. The solution to this is to refine the CSS font stack, adding a fallback font that is guaranteed to have the widest possible set of glyphs.

當發生這種不幸的情況時，讀者可能會發現“豆腐”字符散落在文本中。 解決方案是優化CSS字體堆棧，添加一個后備字體，以確保它具有盡可能廣泛的字形集。

Google developed the Noto font just for this purpose. As of this writing, it spans 30 distinct writing scripts. It has glyphs in serif, sans-serif and monospaced styles.

Google為此開發了Noto字體。 在撰寫本文時，它涵蓋了30種不同的編寫腳本。 它具有襯線，無襯線和等距樣式的字形。

Because it is so comprehensive, it’s too big to use as a web font without splitting it up. Use of the unicode-range rule should be considered mandatory when using Google Noto as a web font.

由于它非常全面，因此太大了，無法拆分成網絡字體。 將Google Noto用作網絡字體時，應認為必須使用unicode-range規則。

特定語言的字體 (Language-specific fonts)

Unicode has steadily increased support for more of the world’s ancient and modern languages. Each year new code points are added to the spec. But because of the time and expense involved, only a few font foundries have created glyph sets for these new code points.

Unicode穩定地增加了對世界上更多的古代和現代語言的支持。 每年，新的代碼點都會添加到規范中。 但是由于所涉及的時間和費用，只有很少的字體鑄造廠為這些新代碼點創建了字形集。

When attempting to use any of these newer code points for authoring web pages, it is imperative that the author and frontend developer work closely to make sure that the reader can see what the author has written.

嘗試使用這些更新的代碼點中的任何一個來創作Web頁面時，必須與作者和前端開發人員密切合作以確保讀者可以看到作者所寫的內容。

For example, if the author is writing about Egyptian archeology and wants to use hieroglyphs within the body of the text, the CSS from our original working example might be adjusted to look like this:

例如，如果作者正在撰寫有關埃及考古學的文章，并希望在文本正文中使用象形文字，則可以將原始工作示例中CSS調整為如下所示：

article {
    font-family: 'Source Sans Pro',
                 'Noto Sans Egyptian Hieroglyphs',
                 sans-serif;
    font-size: 12pt;
    line-height: 1.4;
    margin: 1rem;
}

And an extra @font-face rule would be added like this:

并且將添加一個額外的@ font-face規則，如下所示：

@font-face {
  font-family: 'Noto Sans Egyptian Hieroglyphs';
  font-style: normal;
  font-weight: 400;
  src: url(https://fonts.gstatic.com/ea/notosansegyptianhieroglyphs
                 /v1/NotoSansEgyptianHieroglyphs-Regular.woff2)
                 format('woff2');
  unicode-range: U+13000-1342E;
}

With this in place, the article’s principal text will be rendered in Source Sans Pro, and the hieroglyphs will appear correctly, without tofu, using Noto Sans.

完成此操作后，文章的主要文本將在Source Sans Pro中呈現，并且使用Noto Sans將在沒有豆腐的情況下正確顯示象形文字。

表情符號 (Emojis)

There is no font file, with cross platform support, that contains all of the Unicode-defined emojis. This limitation is largely because fonts have been a black-and-white affair up until now. Four different competing schemes have been developed to make use of color in fonts (SBIX, COLR, SVG-in-OpenType, and CBDT/CBLC). None of these enjoys universal support across all operating systems.

沒有帶有跨平臺支持的字體文件，該文件包含所有Unicode定義的表情符號。 該限制主要是因為到目前為止，字體一直是黑白事務。 已經開發出四種不同的競爭方案來利用字體中的顏色(SBIX，COLR，SVG-in-OpenType和CBDT / CBLC)。 這些都無法在所有操作系統上獲得通用支持。

In the mean time, we are left with:

同時，我們還有：

• Google Noto Color Emoji for Android and Linux

  適用于Android和Linux的Google Noto Color Emoji

• Apple Color Emoji for iOS, macOS, watchOS and tvOs

  適用于iOS，macOS，watchOS和tvO的Apple Color Emoji

• Microsoft Segoe Color Emoji for Windows 10

  適用于Windows 10的Microsoft Segoe Color Emoji

• Twitter Emoji for Everyone for SVGinOT

  適用于SVGinOT的所有人的 Twitter 表情符號

Unfortunately the rendering of each emoji is open to artistic interpretation. As a result, the author and reader will often see something slightly different. Sometimes the difference is so great that it is open to misinterpretation. For example ‘FACE WITH ROLLING EYES’ (U+1F644) looks exasperated with Google, confused with Apple, and amused with Samsung.

不幸的是，每個表情符號的渲染都可以進行藝術性的解釋。 結果，作者和讀者經常會看到稍微不同的東西。 有時差異如此之大，以至于容易引起誤解。 例如，“臉蛋滾動的臉”(U + 1F644)看起來對Google感到憤怒，對Apple感到困惑，而對Samsung感到很有趣。

As of this writing, a cross-platform web font solution to this problem remains elusive. Of course this doesn’t mean we can’t use emojis. But it does mean that designers can’t expect to have their designs faithfully rendered on every platform readers use. Because of this, a web font solution to the problem is simply not worth pursuing at this time.

在撰寫本文時，針對此問題的跨平臺Web字體解決方案仍然難以捉摸。 當然，這并不意味著我們不能使用表情符號。 但這確實意味著設計師不能期望將設計真實地呈現在讀者使用的每個平臺上。 因此，目前根本不值得解決該問題的Web字體解決方案 。

Follow these six golden rules to ensure a great end-user experience with web fonts:

請遵循以下六個黃金法則，以確保最終的用戶體驗Web字體：

1. Define @font-face rules for normal, italic and bold variants for each font family used.
   為使用的每個字體系列的正常，斜體和粗體定義@ font-face規則。

2. Use the font-display property to specify an appropriate FOUT strategy.

   使用font-display屬性可以指定適當的FOUT策略。

3. Add HTML <link rel=preload> statements to prioritize the delivery of critical fonts.

   添加HTML <link rel=preload>語句以優先分配關鍵字體。

4. Create font subsets for company-specific lettering needs.
   創建字體子集以滿足公司特定的刻字需求。
5. Cache aggressively.
   主動緩存。
6. Watch for tofu and respond by specifying fallback fonts when necessary.
   注意豆腐，并在必要時通過指定后備字體進行響應。

Web fonts can be a part of every website’s design. Avoiding the hidden gotchas requires diligence, but getting it right is worth the trouble.

Web字體可以成為每個網站設計的一部分。 避免隱藏的陷阱需要勤奮工作，但正確解決問題卻值得。