題 為什麼網站最近沒有立即顯示他們的文字?


我注意到最近許多網站顯示文字很慢。通常,背景,圖像等將被加載,但沒有文本。一段時間後,文本開始出現在那裡(並不總是同時出現)。

它基本上與以往相反,當文本首先顯示時,然後圖像和其餘部分隨後加載。什麼新技術正在創造這個問題?任何的想法?

請注意,我的連接速度很慢,這可能會突出問題。

請參閱下面的示例 - 所有內容都已加載但在文本最終顯示之前需要幾秒鐘:

enter image description here


439
2018-02-07 06:22


起源


在這種特殊情況下,PortableApps.com使用“Ubuntu”字體。 John首先嘗試了OpenSans,但我們很快就轉向了Ubuntu。我是切換的主要支持者...你可以通過自己安裝字體系列來解決問題的一種方法。如果您安裝它 font.ubuntu.com 它會立即起作用。 - Chris Morgan
丹尼爾的回答令人大開眼界。我認為這是故意這樣做的,以便我們可以查看頁面上的所有廣告。 - Manoj R
正如幾位人士在此指出的那樣,文本以意想不到的方式呈現有無限的原因,因為渲染頁面僅受開發人員/設計人員的想像力的限制,至少自從ANSI位置代碼允許80年代公告以來用於實現具有重疊窗口和陰影的多用戶聊天和UI的電路板。 Meebo是第一個在沒有Applet的瀏覽器中重現其中一些效果的人之一。 “與以往相反的做法”極大地過度簡化了互聯網,甚至沒有涉及特定的時間段。 - PJ Brunet
那麼為什麼要根據Alexa排名較低的網站上的一個隨機屏幕上限對互聯網進行全面的概括?最好的答案也提出了一個大膽的主張:“現在設計師做XYZ”應該備有一些實際數字,比如“截至2012年,5%的網站使用谷歌網絡字體”或其他任何內容。 - PJ Brunet
但是字體文件保存在緩存中,這個站點等待加載m.aspx他們可能會檢查該部分 - user613326


答案:


一個原因是網頁設計師現在喜歡使用網頁字體(通常是在 WOFF 格式),例如通過 Google Web字體

以前,能夠在站點上顯示的唯一字體是用戶在本地安裝的字體。從例如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;

這是非常流行的能夠使用自定義字體,但它也導致在瀏覽器加載資源之前不顯示文本的問題,包括下載時間,字體加載時間和渲染時間。我希望這是你正在經歷的神器。

舉個例子:我的一份全國性報紙, Dagens Nyheter,使用網頁字體作為標題,但不是他們的潛在客戶,因此當加載該網站時,我通常會首先看到潛在客戶,半秒後,上面的所有空白區都會填充標題(這在Chrome和Opera上都是如此,至少。沒有嘗試別人)。

(此外,設計師們現在絕對無處不在地使用JavaScript,所以也許有人試圖用文字做一些聰明的事情,這就是它被推遲的原因。但這將是非常特定於網站的:這些文本在這些方面有延遲的一般趨勢我相信時間是上面描述的網絡字體問題。)


加成

這個答案變得非常受歡迎,儘管我沒有詳細介紹,或者也許 因為 這個的。問題線程中有很多評論,所以我會嘗試擴展一下(很多評論似乎在主題受到保護後短時間內消失了 - 一些主持人可能會手動清理它們)。另外,請閱讀此主題中的其他答案,因為它們都以自己的方式展開。

這種現像一般被稱為“無格式內容的閃現”,特別是“無格式文本的閃現”。搜索“FOUC”和“FOUT”可提供更多信息。

我可以推薦 網頁設計師Paul Irish在FOUT上關於網絡字體的帖子

可以注意到的是,不同的瀏覽器處理不同的方式。我在上面寫道,我測試了Opera和Chrome,兩者的表現相似。所有基於WebKit的(Chrome,Safari等)選擇避免使用FOUT  在Web字體加載期間呈現帶有後備字體的Web字體文本。 即使 那裡有web字體緩存  是渲染延遲。在這個問題線程中有很多評論說不然,並且緩存字體表現得像這樣是錯誤的,但是例如從以上鍊接:

在什麼情況下你會得到一個FOUT

  • 將: 下載並顯示遠程ttf / otf / woff
  • 將: 顯示緩存的ttf / otf / woff
  • 將: 下載並顯示數據-uri ttf / otf / woff
  • 將: 顯示緩存的數據-uri ttf / otf / woff
  • 將不會: 顯示已在傳統字體堆棧中安裝和命名的字體
  • 將不會: 顯示使用local()位置安裝和命名的字體

由於Chrome會在渲染之前等待FOUT風險消失,因此會產生延遲。到哪 程度 效果是可見的(特別是從緩存加載時)似乎取決於需要渲染的文本量以及其他因素,但緩存並不能完全消除效果。

截至2011-04-14,愛爾蘭還有一些關於瀏覽器行為的更新,位於帖子的底部:

  • 火狐 (截至FFb11和FF4 Final) 不再有FOUT! Wooohoo! http://bugzil.la/499292 基本上文本是不可見的3秒,然後它帶回後備字體。 webfont可能會在這三秒內加載...希望...
  • IE9支持WOFF,TTF和OTF(雖然它需要 一個嵌入位  設置的東西 - 如果你使用WOFF,大多沒有實際意義。 然而!!! IE9有一個FOUT。 :(
  • Webkit有 等待著陸的補丁 在0.5秒後顯示後備文本。與FF相同但0.5s而不是3s。
  • 加成:Blink有 這也是為此註冊的錯誤,但似乎尚未達成關於如何處理它的最終共識 - 目前與WebKit相同的實現。

如果這是一個針對設計師的問題,那麼可以採取措施避免這類問題,例如 webfontloader,但這將是另一個問題。 Paul Irish鏈接進一步詳細說明了這個問題。


483
2018-02-07 07:54



是否有任何瀏覽器嘗試首先以可用字體呈現文本,並在下載首選字體後重新呈現它? - Steve Bennett
哦,呃,評論下一個答案: paulirish.com/2009/fighting-the-font-face-fout - Steve Bennett
@ratchetfreak讓頁面重新格式化會令人不安,因為字體可能沒有相同的指標 - Samuel Edwin Ward
有些人寧願進入瀏覽網頁的閱讀部分而不是等待字體加載的年齡 - ratchet freak
@SteveBennett我很確定這正是Internet Explorer 10正在做的事情。我以後從未見過文字彈出。對我來說,它總是以某種“標準字體”出現的文字,幾秒鐘之後它就會變成風格/下載的文字。我不確定它是選擇下一個CSS還是只是系統的默認值。編輯:啊,很好,所以它只是帶有隱藏文字的Webikit?我會考慮這種煩人和不好的行為。是否有任何瀏覽器忽略/隱藏漸進式圖像加載? - Mario


原因是你正在閱讀的文字正在被渲染 網絡字體 它仍然在通往瀏覽器的管道上。

此外,由於您的瀏覽器是Google Chrome,它使用WebKit呈現頁面, 這是由他們決定的 (WebKit即),在下載Web字體之前,最好不要看到任何文本。但是,如果你是一個開發人員,希望文本在合適的後備系統字體中可讀,那麼你可以使用像 谷歌的WebFont Loader 為達到這個。


117
2018-02-07 11:46



可悲的是,這是一個錯誤的答案,如果您訪問此頁面一次,字體文件將駐留在您的網上現金;對於本網站或使用此字體的其他網站上的其他頁面,它將從現金中檢索。 - user613326


簡短回答: AJAX 要么 WOFF

幾個原因 的網站 “顯示文字的速度很慢”。緩慢 portableapps.com 是下載造成的 WOFF 字體。但是,你所描述的是什麼 “文字開始出現在這里和那裡” 更常見的原因是 AJAX

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

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

傳統上的網站:

傳統上,開發人員通常將文本內容放入 初始HTML頁面 並顯示它 一旦可用。 HTML將引用幾個隨後將下載的資源。然後瀏覽器會 逐步重繪 屏幕包括可用的樣式和圖像。 AJAX和WOFF不可用。


WOFF網站:

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


AJAX網站:

一些開發人員選擇不在初始HTML頁面中包含文本內容。相反,他們選擇使用AJAX下載文本內容。有時候是這樣的 加載基本頁面後。根據我的經驗,這種方法獲得了很多 更廣泛的採用 而不是WOFF字體,通常是你描述的緩慢的原因。


確定原因

要確定特定站點的原因,需要使用類似的工具進行分析 螢火 要么 Chrome開發者工具。或者,您也可以使用打開網站 Internet Explorer 8,它支持AJAX但不支持WOFF。如果網站仍然很慢,問題是AJAX而不是WOFF。


19
2018-02-08 13:40





我經常故意選擇避免“無格式內容的閃現”。如果加載CSS之前顯示的文本,你會看到它看起來是原始的,然後在瀏覽器重繪它時閃爍。通過添加一些基本的內聯樣式來初始隱藏內容,在實際樣式表中重寫或使用JS,開發人員避免使用此閃存。


14
2018-02-07 08:26



十分之九不會是故意的,它只是以最簡單的方式嵌入網絡字體的副作用。實際上,當Web字體從管道中下來時,需要花費一些額外的努力來呈現可見的替代方案。看到 developers.google.com/webfonts/docs/webfont_loader - Marcel
@Marcel - 這可能是由慢速樣式表和慢速字體引起的,請參閱 phpied.com/css-and-the-critical-path - r3m0t
防止“有用內容閃現”的代碼往往會阻止圖像出現以及文本。 - Jon Hanna
我很難理解為什麼沒有樣式的文本比沒有文本更糟糕。我寧願能夠開始閱讀它可能會略微搖擺的接受。當它突然出現時,我發現它更加刺耳,當頁面加載並且你被迫等待字體時,它非常令人沮喪。 - Richard Le Poidevin


正如其他人所說,自定義字體可能會導致延遲。

為了提供更多背景知識,瀏覽器在將頁面內容呈現到屏幕之前大致執行以下操作:

  1. 獲取HTML(DNS,TCP,請求/響應的幾次往返)
  2. 開始解析HTML,發現外部資源,如外部CSS和JS。請注意,CSS阻止佈局,並且JS阻止解析。因此,在文檔的早期(例如在頭部中)加載的諸如CSS和JS之類的外部資源減慢了頁面在屏幕上顯示內容所花費的時間。
  3. 獲取外部CSS和JS(幾次往返:DNS和TCP,如果這些資源位於不同的域上,如CDN,以及請求/響應的RTT)
  4. 一旦外部CSS和JS完成加載,解析/執行JS,解析/應用樣式
  5. 如果CSS引用自定義字體,那麼現在也必須下載這些字體,導致額外的往返延遲,以呈現依賴於自定義字體的頁面的任何部分

雖然它不是專門針對自定義字體造成的延遲,但我最近寫了一篇博文,提供了有關渲染延遲原因的其他信息。它提供了一些建議,以最大限度地縮短首次繪製頁面的時間。希望這對有興趣讓他們的頁面更快地顯示內容的讀者有用,包括那些想要使用自定義字體的頁面: http://calendar.perfplanet.com/2012/make-your-mobile-pages-render-in-under-one-second/


8
2018-02-07 18:26





簡短的回答:開發人員。

當引用外部文檔(如.css或.js文件)的鏈接和腳本標記放在文檔的頭部(流程中比主體及其元素更高)時,首先加載它們。 JavaScript從引用它的標記執行;如果要處理的代碼很多,或者代碼很麻煩,或者更常見的是,如果您希望看到的文本在服務器上呈現並在加載時填充到文檔中 - 並且服務器端代碼也很麻煩,由於處理了多個並發請求而導致大量或阻塞I / O,您可能會在HTML有機會呈現之前發現停機時間。一些開發人員選擇在標記和样式之後(在正文的末尾)加載與視圖無關的JavaScript,並且最好嘗試更加清楚他們的技術決策在實現時將如何影響總體用戶體驗。

互聯網連接速度在數據緩慢下載中發揮了作用,很明顯,但編寫得不好的代碼或設計不良的技術堆棧(對於網站類型)在動態內容的緩慢加載中扮演越來越重要的角色,因為網絡連接速度更快接近無處不在。


4
2018-02-07 10:04



不 - 你描述的東西可以阻止DOM的元素顯示而不僅僅是文本。答案是與字體替換有關 設計師的錯而不是開發者。 - Toby
+1 @Toby因為它確實是設計師的錯。如果你處於慢速鏈接(例如,我不知道,我的手機或家裡的固定電話),這也是非常惱人的。像這樣的東西只會使網站變得更慢,並激怒用戶,沒有任何好處。 - Magnus
答案很長:開發人員,開發人員,開發人員,開發人員 - iono
@Toby設計師指定使用哪些字體,是的,但是每個優秀開發人員的工作都是在技術實現過程中做出正確的選擇。優秀的開發人員也會理解為什麼會發生這種情況(在上面的答案中解釋),可以做出哪些選擇來避免問題(Google Webfont Loader),以及這會如何影響體驗。 - arbales


簡而言之,需要在顯示頁面之前從單獨的HTTP GET加載太多可加載對象,並且過度依賴平均延遲作為站點運行狀況的度量。

第一個引用頁面加載的所有那些.css,.js和webfonts,更不用說許多站點還需要檢索JSON對象,查看XHR請求,然後使用某種模板生成HTML。

但他們為什麼不注意到網站很慢?

可能是因為他們在那裡有memecache來加速(或者僅僅依賴於文件系統緩存)並且使用平均延遲來測量他們的站點健康狀況。因此,緩存的對像以6微秒的延遲返回,並掩蓋了許多GET請求需要5000毫秒才能完成的事實。平均值必須死亡。 RTT的計數超過可接受的最大閾值!該數字應為0,或者根據定義,RTT是不可接受的。


3
2018-02-13 04:25





那麼有多種原因。 一個原因還在於定義背景或在html頁面頂部的命令 或者在首先加載的單獨CSS中檢索。在加載包含文本的文檔正文之前。

另一個原因是,雖然在大多數情況下可以輸入圖像的大小,但網頁設計師卻沒有使用它。因此,brouwser必須首先在頁面上加載整個圖像,以便它知道如何在其周圍包裝文本。

一些設計師,也想展示第一張圖片和下一篇文章,他們通過一些javascript實現了這一點,所以例如一個簡單的頁面將首先顯示橫幅,然後是其他所有內容。

但是如果你想知道為什麼我的網頁上有如此多的垃圾郵件商業資料而我只想閱讀新聞,那麼有一個解決方案。如果你使用firefox,你可以使用垃圾郵件攔截器。通過這樣的插件,webrowser知道提供垃圾郵件的網站,並且只是阻止它們,從而加快頁面加載速度,同時您仍然能夠看到與您閱讀的文章相關的重要圖像。

我會建議所有處理慢頁加載的人嘗試fidler。 fidler可以與IEexplorer一起使用或與FireFox一起使用(使用其代理功能) Fidler實際上會向您顯示實際需要多長時間以及何時加載網頁的各個部分。它是一個HTML調試工具。


-1
2018-02-07 11:41



所以,你試圖幫助人們,並投下來投票不是那麼有趣嗎?好的,我會再次三思,然後在這裡解釋人們的技術問題。 - user613326
你解釋了錯誤的事情,這就是你投降的原因。正如您在屏幕截圖中看到的那樣,頁面已完全加載,只顯示文本。這與圖像無關。 - Femaref
文檔的主體幾乎總是在外部CSS之前加載。瀏覽器不會僅僅為了加載外部內容而停止解析頁面。嘗試提供幫助僅在您真正有用時才有用。錯誤信息比沒有信息更糟糕。 - raylu
@raylu我不知道那個錯誤的信息。看到有很多downvotes的答案有時候非常有用。 :-) - LarsTech
嗨@ user613326:我們鼓勵在這裡誠實的downvoting,因為我們主要是為社區提供有用的答案。不要親自接受! - Flimm