根據(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)容。本站擁有對此聲明的最終解釋權。