根據(jù)BuiltWith.com網(wǎng)站收集到的數(shù)據(jù)，排名前10000位的高流量站點中有6%的網(wǎng)站是從Facebook服務器上加載內(nèi)容的。對于它們中的絕大多數(shù)來說，加載的內(nèi)容可能是Facebook的JavaScript SDK,這一大段代碼用來顯示類似Like按鈕（就像在許多媒體網(wǎng)站上看到的那樣）和Facebook評論小插件（也用在許多大的媒體網(wǎng)站，Buzzfeed網(wǎng)站也在其中）。SDK代碼如此之大，它占了一般站點頁面上所有JavaScript總大小的16%。
下載需要花費如此長的時間是現(xiàn)代網(wǎng)站背后的罪魁禍首之一。
作為一個大規(guī)模的被廣泛應用的軟件庫，F(xiàn)acebook SDK是一個很好的方式，來說明一些問題的答案：為何今天的一般站點這么大？網(wǎng)站大小到底有多重要？
為什么這么大？
Facebook SDK功能非常齊全，涵蓋了一般站點的許多工具，它很可能已經(jīng)包含了可供開發(fā)人員使用的工具： 從其它站點檢索數(shù)據(jù)的方法，用于確定用戶使用的瀏覽器和設備，以便針對它們特定的特性，顯示UI元素（像確認對話框和按鈕一樣）。如果我們對SDK所有的部分進行分類，分解看起來像這樣：
SDK中每一組特征的數(shù)量對總文件大小的貢獻。（請注意，這是文件在壓縮前的大小，后的包會變小。）【數(shù)據(jù)源、方法論和更多屏幕閱讀器兼容的數(shù)據(jù)表】
在這些特征集之中，三個是突出的：
SDK中的這三組特征集與大多數(shù)站點上的絕大多數(shù)用戶完全無關。去掉它們—如果有可能這樣做—將會減掉大約SDK文件大小的20%。【數(shù)據(jù)源、方法論和更多屏幕閱讀器兼容的數(shù)據(jù)表】
“Canvas”是Facebook系統(tǒng)為那些打算載入到Facebook網(wǎng)站的應用程序準備的（Facebook在過去曾經(jīng)大力鼓勵開發(fā)人員開發(fā)Facebook網(wǎng)站內(nèi)部的應用程序；我不完全確定今天這類應用程序有多廣泛的應用，但無論哪種方式，常規(guī)網(wǎng)站不使用任何與Canvas相關的特性）將它們包含在SDK中的成本相當?shù)停簝H占SDK總大小的1.5%。
之后是Legacy特性支持。這反映了一個事實，一個API會隨著時間的推移累積多個接口來處理相同的功能。例如，開發(fā)人員編寫的代碼既可以調(diào)用FB.getLoginStatus()（legacy的方法去請求用戶當前的Facebook登錄狀態(tài)），也可以調(diào)用Auth.getLoginStatus()。（新的，鼓勵使用的方法）繞過需要包含這兩套方法的方式是將它們分別發(fā)布在SDK的不同版本中，但是Facebook選擇不這么做，這可能會簡化開發(fā)人員的體驗，并大化使用相同文件的站點數(shù)量（為了增加一般用戶已經(jīng)下載SDK的可能性）。這個決定的代價很小：大約有3.5%的SDK代碼是用來處理顯示標記為“l(fā)egacy”特性的（而且很有可能還有很多“l(fā)egacy”特性，只是沒有明確地標記為這樣而已）。
重要的是，SDK包含了一些polyfill和一些像polyfill類似的工具，它占代碼的15%以上。Polyfill用來提供特性，無論是新瀏覽器還是舊瀏覽器中都可以找到該特性，有時還提供即將發(fā)布但尚未添加到任何瀏覽器的新的特性。Facebook SDK中的大多數(shù)polyfill提供的特性是已經(jīng)包含在那些供絕大多數(shù)互聯(lián)網(wǎng)用戶使用的瀏覽器中的。它們使得Facebook SDK可以為<1%的全球互聯(lián)網(wǎng)用戶提供服務，這些用戶使用諸如IE8這樣的低版本瀏覽器。許多（如果不是絕大多數(shù)的話）主要網(wǎng)站已不提供該支持。
剩下的~80%的SDK,哪個特性被哪個作用所需要的問題更難解開。這是因為SDK是這樣寫的，要使用像Like按鈕這樣的簡單功能，還必須包含用于評論，視頻嵌入，登錄按鈕和其它不相關功能的代碼。Facebook本來可以選擇分發(fā)更小的文件，只包含像Like按鈕這樣的單一特性，但它的商業(yè)目標是鼓勵網(wǎng)站盡可能多地使用Facebook提供的特性。
網(wǎng)站大小重要嗎？
由于Facebook SDK的廣泛應用，以及它變化相對較少的事實，許多用戶在加載站點前可能已經(jīng)下載了它。事實上，這是Facebook為什么要發(fā)布這樣一個大文件，而不是發(fā)布像Like按鈕這樣特定特性的小文件的主要原因。大多數(shù)用戶的網(wǎng)絡連接—至少那些發(fā)達國家的用戶—下載Facebook SDK文件所需要的時間很短。
但是不管用戶的瀏覽器是否已經(jīng)下載了SDK,運行一個大的JavaScript腳本塊還是有資源開銷，尤其是在移動設備上。在相對較新的蘋果筆記本電腦上，我寫這篇文章，F(xiàn)acebook SDK運行在一個類似Buzzfeed網(wǎng)站上大約需要50ms（二十分之一秒）。不算太壞—尤其是當與其余的JS代碼相比較時，包含AD相關的代碼，需要更長的時間來執(zhí)行—但對于只在頁面底部顯示評論來說，仍然是微不足道的資源開銷。
在一個蘋果筆記本上的Chrome瀏覽器中的腳本評估
在一個非常新的智能手機上（Google Pixel），JS腳本執(zhí)行時間倍增，超過十分之一秒：
在Google Pixel智能手機上的腳本評估
當關聯(lián)起來看時，這只是頁面總代碼執(zhí)行時間上的一小部分。但在滾動頁面或者頁面交互時增加了時間，這可能會是一次非常不愉快的體驗。很重要的一點：這個特定的SDK有很小的成本，但是現(xiàn)代的網(wǎng)站—尤其是媒體網(wǎng)站—通常包含來自大量第三方的類似代碼（這個例子從Gawker網(wǎng)站取得，在它被一個億萬富翁敲詐勒索搞破產(chǎn)之前，顯示可以有多少這樣的請求）。
即使拋開向這些第三方發(fā)送一些用戶信息的隱私影響，所有這些特性的成本也會迅速增加。站點添加的每一個第三方腳步都是有代價的，無論是在性能方面，還是在幫助合理化添加下一個“相對無害”的第三方代碼塊方面。除了所有這些代碼的附加成本帶來的即時性能影響外，這還會影響開發(fā)人員的士氣：想象一下，工作幾天只為降低自己代碼加載時間的10%，卻看到增加的巨大的第三方代碼塊，這就削弱了那項艱苦努力的影響。然后（如果你在一家媒體網(wǎng)站工作）,看到這種模式每隔幾個月就會一遍又一遍的重復。
應該包含它嗎？
如果你需要用到諸如Facebook評論之類的特性，就沒有必要加載Facebook的SDK。但這取決于你的網(wǎng)站是如何構建的，你可以通過只在需要時加載SDK來限制SDK的性能影響（例如，一旦用戶向下滾動標點，評論控件就該變得可見）。
如果你想使用Like按鈕，停止并重新考量。Facebook在用戶的時間表上不再顯示醒目的（或，在大多數(shù)案例中，完全）Like按鈕。好使用一個簡單的自定義共享按鈕或鏈接，作為一個額外的好處，這樣做將阻止Facebook追蹤所有到您頁面的訪問，避免侵犯到用戶的隱私。刪除了Like按鈕的站點，在涉及到Facebook流量推薦時，沒有發(fā)現(xiàn)這樣做會帶來什么負面影響。
本站文章版權歸原作者及原出處所有 。內(nèi)容為作者個人觀點， 并不代表本站贊同其觀點和對其真實性負責，本站只提供參考并不構成任何投資及應用建議。本站是一個個人學習交流的平臺，網(wǎng)站上部分文章為轉載，并不用于任何商業(yè)目的，我們已經(jīng)盡可能的對作者和來源進行了通告，但是能力有限或疏忽，造成漏登，請及時聯(lián)系我們，我們將根據(jù)著作權人的要求，立即更正或者刪除有關內(nèi)容。本站擁有對此聲明的最終解釋權。
