用第三方庫帶來的剛性成本

我以前一直在思考，在項目中引入第三方庫會給咱們帶來什麼，在你爲何用或不用框架？這篇文章中wo說了使用框架（庫）帶給咱們的好處和不使用給咱們的好處是什麼，可是並未詳細說明使用第三方庫，它自己又會帶來什麼問題。

經過查找資料，我在Hard Costs of Third-Party Scripts 這篇文章中找到了答案。第三方庫帶來的影響就是它下降了用戶體驗效果，增長了 用戶成本。這篇文章從7個方面說明了使用第三方庫可能帶來的問題，文中說的問題你大多數也都遇到過。

譯文以下：

我對第三方庫與用戶體驗成本之間的關係感興趣。我作的每一個客戶端，平均大約使用30個第三方庫。但開發者卻由於 若是咱們將 *async* 它們所有加載呢？ 減小了對它們的爭論。雖然這是一個很好的反駁，可是仍然存在將它傳遞給用戶的成本。這就是我要講的主題。

用戶成本 是什麼？最多見答案多是隱私。但就隱私被侵犯這事兒來講，歷來沒有明確界限。人們對我的數據暴露也有不一樣的容忍度。在討論第三庫的時，隱私就變得有點兒笨拙黨的感受。雖然討論它們頗有必要，但我但願將隱私與第三份庫分開，並專一於應用程序帶來的成本。

爲了更好地瞭解 用戶成本，我在Twitter上發了一個話題：假設咱們有一個包含約300個第三方庫的站點，全部庫都負責加載爲異步，用戶體驗將面臨什麼？

1. aync代碼在你本身編寫的代碼以前到達

若是異步代碼在你本身編寫的代碼完成下載以前到達，將阻止HTML，CSS和JS解析。

2. DNS查詢成本

今年早些時候，我看到 webhint 的 AntónMolleda 作的 一些數字統計 ，它代表即便3次DNS查詢，也會在3G渲染預算上下降~5s/170kb，額外須要10kb。有一些HTTP存檔數據代表更多的第三方庫會增長加載時間，這彷佛證明了這個數字。

3. CPU佔用

第三方庫可能會阻止你本身編寫的代碼的性能。它佔用了大量的可用的CPU週期，你本身編寫的代碼處於明顯的 下風。

4. 網絡佔用

Paul Irish提到了相似於CPU佔用的網絡佔用，他說：「你的更重要的本身編寫的代碼的網絡請求會佔用較少的帶寬。」 雖然你的瀏覽器有~5個鏈接線程可用於網絡請求，但你本身編寫的代碼的任何部分或單個頁面須要另外一個文件或者懶加載的圖像，它可能須要排隊等一段時間。

5. 用戶數據和電池成本

手機的數據須要成本，HTTP請求也會消耗手機電池的電量。我認爲不管是用戶有意識地，仍是由市場的無形大手的引導，最終將追求非數據消費和電池電量消耗的替代方案（例如，使用FB Messenger的微信）

6. 重載事件

它和CPU佔用相似，但大多使用scroll，resize，或click的庫可能會下降頁面在瀏覽器中的自適應性，在極端狀況下可能會致使佈局的崩潰。

7. 調試覆蓋範圍增長

雖然這會增長組織代碼的成本，但它可能會變成影響用戶體驗的成本。更多庫會增長調試的覆蓋範圍。若是出現問題，你是喜歡檢查5個地方的問題仍是300個？我最近遇到了由第三方庫的問題而致使的錯誤，找出致使問題的庫，花費了我一成天的時間，但我仍然不知道該如何將該庫引入構建，而不產生錯誤。

雖然300個第三方庫，這聽起來有點誇張，可是有約50或者約150個第三方請求呢？我如今有幾個應用就是這個樣子。Alexa Top 50的統計結果是平均約爲18個第三方庫。我堅信即便有了第三方提供的解決方案，你也可能會遇到部分或所有上述的問題。

總結

我想這裏咱們能夠獲得這樣一個結論，那就是單頁應用程序和它每一個路由的JS構建包可能最有可能被網絡和CPU爭用所扼殺。你的初始有效負載可能會得到100％的CPU，但後續頁面可能會爭奪其中的一小部分。但這取決於你的構建策略，若是構建策略是完美的，那麼構建包會很好的加載並及時執行。不只是SPA可能會遇到這樣的問題，其它任何資源均可能延遲加載，並緩慢的執行。特別是網絡不靠譜的狀況下，因此這不該該讓你感到很是驚訝的。

若是你想到我遺漏的任何東西，請告訴我。我想咱們都在這艘沉沒的第三方船上，咱們彼此都須要擺脫它。

我在gihub[article 中開闢了一個想法模塊]，我會陸續添加一些類似的文章，但願獲得你們的支持。