整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
前言
之中，哪個部分是現在的盲點呢？今日早讀文章由@翻譯分享。
正文從這開始~
你會在你的項目中使用 AMP 和 Instant 么？
依賴于你的組織優先性和戰略性，你可能想考慮使用谷歌的AMP和 的Instant 或者蘋果的Apple News。沒有它們，你可以實現很好的性能，但是 AMP 確實提供了一個免費的內容分發網絡（CDN）的性能框架，而 Instant 將提高你在 上的知名度和表現。
對于用戶而言，這些技術主要的優勢是確保性能，但是有時他們寧愿喜歡 AMP-/Apple News/Instant Pages 鏈路，也不愿是“常規”和潛在的臃腫頁面。對于以內容為主的網站，主要處理很多第三方法內容，這些選擇極大地加速渲染的時間。
對于網站的所有者而言優勢是明顯的：在各個平臺規范的可發現性和增加搜索引擎的可見性。你也可以通過把 AMP 作為你的 PWA 數據源來構建漸進增強的 Web 體驗。缺點？顯然，在一個有圍墻的區域里，開發者可以創造并維持其內容的單獨版本，防止 Instant 和 Apple News沒有實際的URLs。（謝謝Addy，Jeremy）
明智地選擇你的 CDN
根據你擁有的動態數據量，你可以將部分內容外包給靜態站點生成器，將其放在 CDN 中并從中提供一個靜態版本。因此可以避免數據的請求。你甚至可以選擇一個基于 CDN 的靜態主機平臺，將交互組件作為增強來充實你的頁面 ()。
注意，CDN 也可以服務（卸載）動態內容。因此，限制你的 CDN 到靜態資源是不必要的。仔細檢查你的 CDN 是否進行壓縮和轉換（比如：圖像優化方面的格式，壓縮和調整邊緣的大小），智能 HTTP/2 交付，邊側包含，在 CDN 邊緣組裝頁面的靜態和動態部分（比如：離用戶最近的服務端），和其他任務。
構建優化
分清輕重緩急
知道你應該優先處理什么是個好主意。管理你所有資產的清單（，圖片，字體，第三方腳本和頁面中“昂貴的”模塊，比如：輪播圖，復雜的圖表和多媒體內容），并將它們劃分成組。
建立電子表格。針對傳統的瀏覽器，定義基本的核心體驗（比如：完全可訪問的核心內容），針對多功能瀏覽器提升體驗（比如：豐富多彩的，完美的體驗）和其他的（不是絕對需要而且可以被延遲加載的資源，如 Web 字體、不必要的樣式、旋轉木馬腳本、視頻播放器、社交媒體按鈕、大型圖像。）。我們在“ ’s ”發布了一篇文章，上面詳細描述了該方法。
考慮使用“cutting-the-mustard”模式
雖然很老，但我們仍然可以使用cutting-the-mustard 技術將核心經驗帶到傳統瀏覽器并增強對現代瀏覽器的體驗。嚴格要求加載的資源：優先加載核心傳統的，然后是提升的，最后是其他的。該技術從瀏覽器版本中演變成了設備功能，這已經不是我們現在能做的事了。
例如：在發展中國家，廉價的安卓手機主要運行 Chrome，盡管他們的內存和 CPU 有限。這就是PRPL 模式可以作為一個好的選擇。因此，使用設備內存客戶端提示頭，我們將能夠更可靠地針對低端設備。在寫作的過程中，只有在 Blink 中才支持 header(Blink 支持客戶端提示)。因為設備存儲也有一個在Chrome 中可以調用的 API，一種選擇是基于 API 的特性檢測，只在不支持的情況下回退到 “符合標準”技術（謝謝，Yoav?。?/p>
解析 的代價很大，應保持其較小
但我們處理單頁面應用時，在你可以渲染頁面時，你需要一些時間來初始化 app。尋找模塊和技術加快初始化渲染時間（例如：這里是如何調試 React 性能，以及如何提高 Angular 性能），因為大多數性能問題來自于啟動應用程序的初始解析時間。
有成本，但不一定是文件大小會影響性能。解析和執行時間的不同很大程度依賴設備的硬件。在一個普通的手機上（Moto G4），僅解析 1MB （未壓縮的）的 大概需要 1.3-1.4 秒，會有 15 - 20% 的時間耗費在手機的解析上。在執行編譯過程中，只是用在準備平均需要 4 秒，在手機上繪排需要 11 秒。解釋：在低端移動設備上，解析和執行時間可以輕松提高 2 至 5 倍。
Ember 最近推出了一個實驗，一種使用二進制模板巧妙的避免解析開銷的方式。這些模板不需要解析。（感謝，！）
這就是檢查每個 依賴性的關鍵，工具像webpack-bundle-，Source Map 和Bundle Buddy可以幫助你完成這些。度量 解析和編譯時間。Etsy 的，一個小工具允許您指示 在任何設備或瀏覽器上測量解析和執行時間。重要的是，雖然大小重要，但它不是一切。解析和編譯時間并不是隨著腳本大小增加而線性增加。
<iframe src="[https://player.vimeo.com/video/249525818](https://player.vimeo.com/video/249525818)" width="640" height="384" frameborder="0" webkitallowfullscreen="" mozallowfullscreen="" allowfullscreen=""></iframe>Webpack Bundle .
你使用預編譯器么？
使用預編譯器來減輕從客戶端到服務端的渲染的開銷，因此快速輸出有用的結果。最后，考慮使用.js更快的加載,用快速地調用的函數（盡管，它可能不需要）。
你使用 tree-shaking，scope ，code- 么
Tree-shaking 是一種通過只加載生產中確實被使用的代碼和在 Webpack 中清除無用部分，來整理你構建過程的方法。使用 Webpack 3 和 Rollup，我們還可以提升作用域允許工具檢測import鏈接以及可以轉換成一個內聯函數，不影響代碼。有了 Webpack 4，你現在可以使用JSON Tree Shaking。可以幫助你去刪除未使用 CSS 樣式。
而且，你想考慮學習如何編寫有效的 CSS 選擇器以及如何避免臃腫和開銷浪費的樣式。感覺好像超越了這個？你也可以使用 Webpack 縮短類名和在編譯時使用作用域孤立來動態地重命名 CSS 類名
Code-是另一種 Webpack 特性，可以基于“chunks”分割你的代碼然后按需加載這些代碼塊。并不是所有的 必須下載，解析和編譯的。一旦在你的代碼中確定了分割點，Webpack 會全權負責這些依賴關系和輸出文件。在應用發送請求的時候，這樣基本上確保初始的下載足夠小并且實現按需加載。另外，考慮使用preload-webpack-plugin獲取代碼拆分的路徑，然后使用or提示瀏覽器預加載它們。
在哪里定義分離點？通過追蹤使用哪些 CSS/ 塊和哪些沒有使用。Umar Hansa解釋了你如何可以使用 代碼覆蓋率來實現。
如果你沒有使用 Webpack，值得注意的是相比于 輸出結果Rollup展現的更加優秀。當使用 Rollup 時，我們會想要查看，它可以轉化 2015 modules 為一個大的 module ——因為取決于打包工具和模塊加載系統的選擇，小的模塊會有令人驚訝的高性能開銷。
Addy Osmani 的'默認快速：現代負載最佳實踐
Addy Osmani 的從[快速默認：現代加載的最佳實踐]（）?；脽羝?6。
最后，隨著現代瀏覽器對 ES2015 支持越來越好，考慮使用babel-preset-env只有 ES2015+ 特色不支持現代瀏覽器的目標。然后設置兩個構建，一個在 ES6 一個在 ES5。我們可以使用script type="module"讓具有 ES 模塊瀏覽器支持加載文件，而老的瀏覽器可以加載傳統的建立script 。
對于 loadsh，使用babel-plugin-lodash將會加載你僅僅在源碼中使用的。這樣將會很大程度減輕 的負載。
利用目標 引擎的優化。
研究 引擎在用戶基礎中占主導地位，然后探索優化它們的方法。例如，當優化的 V8 引擎是用在 Blink 瀏覽器，Node.js 運行和電子，對每個腳本充分利用腳本流。一旦下載開始，它允許async或defer scripts在一個單獨的后臺線程進行解析，因此在某些情況下，提高頁面加載時間達 10%。實際上，在中使用，以致于瀏覽器更早地可以發現資源，然后在后臺線程中解析它。
Caveat：Opera Mini不支持 腳本，如果你正在為印度和非洲開發，defer將會被忽略，導致阻塞渲染直到腳本已經評估了（感謝 Jeremy）!_。
漸進引導
漸進引導：使用服務器端呈現獲得第一個快速的有意義的繪排，而且還要包含一些最小必要的 來保持實時交互來接近第一次的繪排。
客戶端渲染或者服務端渲染？
在兩種場景下，我們的目標應該是建立漸進引導：使用服務器端呈現獲得第一個快速的有意義的繪排，而且還要包含一些最小必要的 來保持實時交互來接近第一次的繪排。如果 在第一次繪排沒有獲取到，那么瀏覽器可能會在解析時鎖住主線程，編譯和執行最新發現的 ，因此限制互動的網站或應用程序。
為了避免這樣做，總是將執行函數分離成一個個，異步任務和可能用到的地方。考慮 UI 的懶加載部分使用 WebPack動態import支持，避免加載，解析，和編譯開銷直到用戶真的需要他們（感謝Addy!）。
在本質上，交互時間（TTI）告訴我們導航和交互之間的時間長度。度量是通過在初始內容呈現后的第一個五秒窗口來定義的，在這個過程中， 任務沒有操作 50ms 的。如果發生超過 50ms 的任務，尋找一個五秒的窗口重新開始。因此，瀏覽器首先會假定它達到了交互式，只是切換到凍結狀態，最終切換回交互式。
一旦我們達到交互式，然后，我們可以按需或隨時間所允許的，啟動應用程序的非必需部分。不幸的是，隨著Paul Lewis 提到的，框架通常沒有優先出現的概念可以向開發人員展示，因此漸進式引導很難用大多數庫和框架實現。如果你有時間和資源，使用該策略可以極大地改善前端性能。
你限制第三方腳本的影響么？
盡管所有的性能得到很好地優化，我們不能控制來自商業需求的第三方腳本。第三方腳本度量不受終端用戶體驗的影響，所以，一個單一的腳本常常會以調用令人討厭的，長長的第三方腳本為結尾，因此，破壞了為性能專門作出的努力。為了控制和減輕這些腳本帶來的性能損失，僅異步加載（可能通過 defer）和通過資源提示，如：dns-或者加速他們是不足夠的。
正如 Yoav Weiss 在他的必須關注第三方腳本的通信中解釋的，在很多情況下，下載資源的這些腳本是動態的。頁面負載之間的資源是變化的，因此我們不必知道主機是從哪下載的資源以及這些資源是什么。
這時，我們有什么選擇？考慮通過間隔下載資源來使用 service workers，如果在特定的時間間隔內資源沒有響應，返回一個空的響應告知瀏覽器執行解析頁面。你可以記錄或者限制那些失敗的第三方請求和沒有執行特定標準請求。
另一個選擇是建立一個內容安全策略（CSP）來限制第三方腳本的影響，比如：不允許下載音頻和視頻。最好的選擇是通過嵌入腳本以致于腳本運行在 iframe 環境中，因此如果沒有接入頁面 DOM 的權限，在你的域下不能運行任何代碼。Iframe 可以 使用sandbox屬性進一步限制，因此你可以禁止 iframe 的任何功能，比如阻止腳本運行，阻止警告、表單提交、插件、訪問頂部導航等等。
例如，它可能需要允許腳本運行。每一個限制都可以通過’允許’值在 ‘sandbox’ 屬性中（幾乎處處支持）解除，所以把他們限制在最低限度的允許他們去做的事情上。考慮使用和交叉觀察；這將使廣告嵌入 iframe 的同時仍然調度事件或需要從 DOM 獲取信息（例如廣告知名度）。注意新的策略如特征策略），資源的大小限制，CPU 和帶寬優先級限制損害的網絡功能和會減慢瀏覽器的腳本，例如：同步腳本，同步 XHR 請求，.write 和超時的實現。
為了壓測第三方，在 上自底向上概要地檢查頁面的性能，測試如果一個請求被阻塞了會發生什么或者對于后面的請求有超時限制，你可以使用 ’s 服務器72.66.115.13，同時可以在你的hosts文件中指定特定的域名。最好是自我主機和使用一個單一的主機名，但是同時生成一個請求映射，當腳本變化時，暴露給第四方調用和檢測。
請求塊
圖片信用：Harry Roberts
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
