☰

為什麼現在網站不立即顯示其文字？

tag-icon • tag-icon performance browser display webkit
為什麼現在網站不立即顯示其文字？

我注意到最近許多網站顯示文字的速度很慢。通常，會載入背景、圖像等，但不會載入文字。一段時間後，文字開始到處出現（並不總是同時出現）。

它的工作原理基本上與以前相反，首先顯示文本，然後加載圖像和其餘部分。是什麼新技術造成了這個問題？任何想法？

請注意，我的連線速度很慢，這可能會加劇問題。

請參閱下面的範例 - 一切都已加載，但在最終顯示文字之前還需要幾秒鐘：

在此輸入影像描述

答案1

原因之一是現在的網頁設計師喜歡使用網頁字體（通常在沃夫格式），例如透過谷歌網頁字體。

以前，能夠在網站上顯示的唯一字體是用戶本地安裝的字體。例如，由於 Mac 和 Windows 使用者不一定具有相同的字體，因此設計者本能地總是將規則定義為

font-family: Arial, Helvetica, sans-serif;

如果系統上找不到第一種字體，瀏覽器會尋找第二種字體，最後是後備「sans-serif」字體。

現在，可以將字體 URL 作為 CSS 規則來讓瀏覽器下載字體，如下所示：

@import url(http://fonts.googleapis.com/css?family=Droid+Serif:400,700);

然後透過以下方式載入特定元素的字體：

font-family: 'Droid Serif',sans-serif;

能夠使用自訂字體是很受歡迎的，但它也導致了一個問題，即在瀏覽器加載資源之前不會顯示任何文本，其中包括下載時間、字體加載時間和渲染時間。我希望這就是您正在體驗的神器。

舉個例子：我的一份全國性報紙，新聞日報，使用網頁字體作為標題，但不使用引導語，因此當加載網站時，我通常會首先看到引導語，半秒後，上面的所有空白區域都會填充標題（這在Chrome 和Opera 上正確的，位於至少沒有嘗試過其他）。

（另外，現在設計者將JavaScript 撒在了各處，所以也許有人試圖對文本做一些巧妙的事情，這就是它被延遲的原因。不過，這將是非常特定於站點的：在這些文本中文本被延遲的一般趨勢我相信，times 就是上面描述的網頁字體問題。

添加

這個答案得到了非常高的支持，儘管我沒有詳細說明，或者也許因為這個的。問題線索中有很多評論，所以我會嘗試擴展一下（很多評論似乎在主題受到保護後不久就消失了 - 某些版主可能手動清理了它們）。另外，請閱讀該線程中的其他答案，因為它們都以自己的方式擴展。

這種現象通常被稱為“無樣式內容的閃現”，特別是“無樣式文字的閃現”。搜尋“FOUC”和“FOUT”可提供更多資訊。

我可以推薦網頁設計師 Paul Irish 在 FOUT 上發表的與網頁字體相關的帖子。

值得注意的是，不同的瀏覽器對此的處理方式有所不同。我在上面寫道，我測試了 Opera 和 Chrome，它們的行為都很相似。所有基於 WebKit 的瀏覽器（Chrome、Safari 等）都選擇透過以下方式避免 FOUT：不是在網頁字體載入期間使用後備字體渲染網頁字體文字。即使網頁字體已緩存，在那裡將要是渲染延遲。在這個問題線程中有很多評論說否則，並且緩存字體的行為像這樣是完全錯誤的，但是例如從上面的鏈接：

在什麼情況下您會收到 FOUT

  • 將要：下載並顯示遠端 ttf/otf/woff
  • 將要：顯示快取的 ttf/otf/woff
  • 將要：下載並顯示 data-uri ttf/otf/woff
  • 將要：顯示快取的 data-uri ttf/otf/woff
  • 將不會：顯示傳統字體堆疊中已安裝並命名的字體
  • 將不會：顯示使用 local() 位置安裝和命名的字體

由於 Chrome 會等到 FOUT 風險消失才進行渲染，因此會產生延遲。到哪程度效果是可見的（尤其是從快取加載時）似乎取決於需要渲染的文字量以及其他因素，但快取並不能完全消除效果。

Irish 在帖子底部還提供了一些有關截至 2011 年 4 月 14 日瀏覽器行為的更新：

  • 火狐瀏覽器（截至 FFb11 和 FF4 Final）不再有 FOUT！嗚呼！http://bugzil.la/499292基本上，文字在 3 秒內不可見，然後恢復後備字體。不過，網頁字體可能會在這三秒內載入…希望如此…
  • IE9 支援 WOFF 和 TTF 和 OTF（儘管它需要一個嵌入位 設定的東西– 如果您使用 WOFF，則幾乎沒有意義）。然而！ IE9有一個FOUT。:(
  • Webkit 有等待著陸的補丁0.5 秒後顯示備用文字。與 FF 的行為相同，但時間為 0.5 秒而不是 3 秒。
  • 添加: 眨眼有也為此註冊了一個錯誤，但似乎尚未就如何處理它達成最終共識 - 目前與 WebKit 的實現相同。

如果這是一個針對設計師的問題，那麼人們可以想辦法避免這類問題，例如webfontloader，但這將是另一個問題。 Paul Irish 連結對此事進行了更詳細的介紹。

答案2

原因是您無法閱讀的文字正在被渲染網路字體它仍在透過管道傳輸到您的瀏覽器中。

另外，由於您的瀏覽器是 Google Chrome，它使用 WebKit 來呈現頁面，這是他們決定的（即 WebKit）在下載網頁字體之前，最好不要看到任何文字。但是，如果您是開發人員，希望文字以合適的後備系統字體可讀，那麼您可以使用類似Google 的 WebFont 載入器為了達成這個。

答案3

簡短回答：阿賈克斯或者沃夫

有有幾個原因的網站是“顯示文字的速度很慢”。緩慢的便攜式應用程式.com是下載引起的沃夫字體。然而，你所描述的“文字開始出現在這裡和那裡”更常見的原因是阿賈克斯。

網站由許多部分組成。如何下載和組裝這些部件是一個設計選擇在控制下網站設計者。速度緩慢是由開發人員選擇組裝以下構建塊的方式造成的：

  • 初始 HTML 頁面
  • CSS
  • JS
  • 圖片
  • WOFF字體
  • AJAX 請求
  • DOM 操作

傳統網站：

傳統上，開發人員通常將文字內容放在初始 HTML 頁面並顯示它一旦可用。 HTML 會引用多個資源，然後下載這些資源。然後瀏覽器會逐步重畫螢幕上包含可用的樣式和圖像。 AJAX 和 WOFF 不可用。

WOFF 網站：

WOFF 字體允許網站使用瀏覽器通常無法使用的字體，方法是透過網站下載字體。一些開發人員指示瀏覽器在下載所有 WOFF 字型之前不要顯示文字內容。根據我的經驗，這種方法尚未被廣泛使用。

AJAX 網站：

有些開發人員選擇不在初始 HTML 頁面中包含文字內容。相反，他們選擇使用 AJAX 下載文字內容。有時候是這樣的基本頁面載入完成後。根據我的經驗，這個方法收穫很大更廣泛的採用比 WOFF 字體更常見，這通常是您所描述的速度緩慢的原因。

確定原因

要確定特定站點的原因，需要使用以下工具進行分析螢火蟲或者Chrome 開發者工具。或者，您也可以使用以下命令開啟該網站網際網路瀏覽器 8，支援 AJAX 但不支援 WOFF。如果網站仍然很慢，則問題出在 AJAX 而不是 WOFF。

答案4

正如其他人指出的那樣，自訂字體可能會導致延遲。

為了提供更多背景信息，瀏覽器在將頁面內容呈現到螢幕上之前大致執行以下操作：

  1. 取得 HTML（DNS、TCP、請求/回應的多次往返）
  2. 開始解析HTML，發現外部資源，例如外部CSS和JS。請注意，CSS 會阻止佈局，而 JS 會阻止解析。因此，在文件早期（例如在頭部）載入 CSS 和 JS 等外部資源會減慢頁面在螢幕上顯示內容所需的時間。
  3. 取得外部 CSS 和 JS（多次往返：如果這些資源位於不同的網域（例如 CDN）上，則為 DNS 和 TCP，以及請求/回應的 RTT）
  4. 一旦外部CSS和JS完成加載，解析/執行JS，解析/應用樣式
  5. 如果 CSS 引用自訂字體，那麼現在也必須下載這些字體，從而導致渲染依賴自訂字體的頁面任何部分時產生額外的往返延遲

雖然這與自訂字體引起的延遲無關，但我最近寫了一篇部落格文章，提供了有關渲染延遲原因的更多資訊。它提供了一些建議，以最大限度地減少首次繪製頁面的時間。希望這對於有興趣使頁面更快顯示內容的讀者有用，包括那些想要使用自訂字體的頁面：http://calendar.perfplanet.com/2012/make-your-mobile-pages-render-in-under-one-second/

相關內容