我對rel="preload"屬性感到興奮，因爲它看起來可以幫助加快頁面渲染時間。我應該預先加載一個大的圖像嗎？
用例是一個網頁，上面有一個大圖像。現在，直到獲取jQuery（一個相當重的文件）之後，Chrome纔會開始下載圖像。啓用預加載後，它們將並行下載。
但是我正在閱讀衝突的報告，關於是否應將preload用於其他地方可見HTML元素（與用戶交互可見的內容相比，如下拉菜單）。
This post似乎建議不要預加載：
當不使用預壓：
- 當資產被稱爲別處在同一頁上。
- 如果您不確定用戶是否真的需要該資產。就像在一個頁面上，訪問者只有3％的時間。
雖然this one似乎表明它是金融時報的網站上有類似的情況非常有幫助：
當金融時報推出了鏈接預壓頭到他們的網站，他們剃光1秒關閉顯示標頭圖像所用的時間...
那麼這是哪一個？我應該提供一個早期的「提示」來顯示始終顯示的上面的圖像嗎？或者我應該讓瀏覽器按照通常的順序進行操作？
我認爲，在涉及性能優化的情況下，您真的需要create an A/B test來確定您應該執行哪一個。作爲最佳實踐，圖像預加載並不適用於所有人。
我最喜歡的一本書Lean Enterprise的最大原則之一是用於A/B測試來證明或反駁HIPPO（高薪的人的觀點）。某些意見在你的組織和互聯網上都有很大的影響力。由於他們的重要性和聲譽，他們的意見轉向事實的領域，儘管事實並非如此。
另一本我喜歡的關於性能調優的書也吹捧了我測試性能的做法 - Code Complete 2nd Ed.在這本書中，McConnell給出了幾個代碼示例，您可能希望一段代碼是最優的，但事實上，它表現不佳（見第25和26章）。他的一個關鍵點是你應該總是測試性能優化。 如果它不值得測試，那麼不值得在第一個地方編寫「高性能」代碼。麥康奈爾的前提不僅適用於他的低級別編碼示例，還適用於高級別決策，例如在圖像上預加載圖像。
我也可以證明專業級別的A/B測試的重要性。我曾經在亞馬遜的搜索引擎優化團隊工作，我們A/B測試了一切。事實是你永遠不知道顧客會如何迴應。沒有人能夠預測顧客的行爲 - 甚至連傑夫貝佐斯也沒有 - 你真的需要用真實數據來支持你的假設，以證明或反駁你正在做的事情的有效性。
儘管您可以找到多篇博客文章和在線資源，討論預加載是否更好，但在完成之前，您並不知道它是否適用於您。不同的人有不同的服務器，具有不同的性能特徵和不同的網絡拓撲結構等等，直到獲得數據爲止，您只是不知道哪種方式更好。如果您啓動A/B測試並發現在預加載時您的排斥率升高，那麼您知道必須回撥您的治療並返回到您的控制。但是，如果您發現客戶不會感到無聊的等待並以比以前更高的速率點擊，那麼您將獲得勝利者並撥打治療 - 在一段時間後完全刪除控制代碼。
我希望有幫助。
我只會在圖像中使用rel =「preload」，因爲如果用戶驅動的事件會請求圖像，那麼javascript會在稍後時間渲染頁面時出現瓶頸並且會對用戶體驗造成不利影響，或者如果您在呈現頁面時遇到由此大圖像引起的任何流量。
我知道你的圖像是最重要的，如果它在源代碼中從一開始就能找到，我會讓瀏覽器優先考慮首先下載的內容。 另一方面，你可以隨時A/B這種變化，看看它是否適合你。
這篇文章對這些陳述是錯誤的。開發人員使用預加載，因爲他已經知道頁面上需要這些資源。預加載不是一個「提示」。預取更符合他陳述的內容，即你告訴瀏覽器可能需要資產。
如果圖像超出了摺疊範圍，那麼您就知道這將是需要的，而這正是預取的目的。
預緊力是一種聲明獲取，讓你強制瀏覽器 使一個資源的請求，而不會阻塞文檔的onload事件 。
很多時候，感知加載時間比真實感更重要。根據內容的不同，有時您會希望儘快準備好文字，或者儘早提供相互交流，有時還會提供圖片......您應該嘗試一下，看看它的感覺如何。我記得一個具體的例子：6-7秒的白色加載屏幕是不可接受的，但9-10秒有一個小徽標和加載動畫是完全沒問題的。 – 2017-10-23 23:45:16
什麼是頁面結構？包括js腳本在內，是頁眉/頁腳？這些腳本是否包含在同步/異步模式中？我認爲你的問題歸結爲特定的頁面優化問題，所以最好能看到具有類似結構的URL或頁面草圖，以檢查Chrome如何調度資源加載 – ffeast