de Ben Regenspan

De ce butoanele Facebook Like reprezintă 16% din codul mediu al unui site web

Conform datele colectate de BuiltWith.com, 6% din primele 10.000 de site-uri cu cel mai mare trafic încărcă conținut de pe serverele Facebook. Pentru marea majoritate a acestora, conținutul este probabil Javascript SDK-ul Facebook, un bloc imens de cod necesar pentru a afișa caracteristici precum butonul Apreciază (așa cum se vede pe multe site-uri media) și widget-uri pentru comentarii Facebook (de asemenea, utilizat pe multe medii mari) site-uri, Buzzfeed printre ele).

Acest cod SDK este atât de mare încât reprezintă aproximativ 16% din dimensiunea totală a tuturor JavaScript-urilor de pe pagină web medie.

De ce butoanele Facebook Like reprezinta 16 din codul mediu
Unul dintre vinovații din spatele site-urilor web moderne care durează atât de mult timp pentru descărcare

Fiind o bibliotecă de software considerabilă și utilizată pe scară largă, SDK-ul Facebook este un mod frumos de a ilustra câteva dintre răspunsurile la întrebări: de ce este site-ul mediu astăzi atât de mare? Și cât de mult contează dimensiunea?

De ce atât de mare?

SDK-ul Facebook are foarte multe funcții, duplicând multe dintre instrumentele pe care site-ul mediu este probabil să le includă deja pentru utilizarea propriilor dezvoltatori: metode de recuperare a datelor de pe alte site-uri, pentru a determina ce browser și dispozitiv utilizează utilizatorul, astfel încât să vizați caracteristici specifice către acestea și pentru afișarea elementelor de interfață (cum ar fi dialoguri și butoane de confirmare). Dacă noi clasificați toate piesele din SDK, defalcarea arată astfel:

ad-banner
1611531907 598 De ce butoanele Facebook Like reprezinta 16 din codul mediu
Cantitatea pe care fiecare set de caracteristici din SDK contribuie la dimensiunea totală a fișierului. (Rețineți că aceasta este dimensiunea fișierului înainte de a fi comprimat; pachetul final va fi mai mic.) [Source data, methodology, and more screen-reader-compatible data table]

Dintre seturile de caracteristici, trei se remarcă cel mai mult:

1611531908 126 De ce butoanele Facebook Like reprezinta 16 din codul mediu
Cele trei seturi de caracteristici din SDK care sunt complet irelevante pentru marea majoritate a utilizatorilor de pe majoritatea site-urilor. Eliminarea acestora – dacă ar fi posibil să se facă acest lucru – ar elimina aproximativ 20% din dimensiunea fișierului SDK. [Source data, methodology, and more screen-reader-compatible data table]

„Canvas” este sistemul Facebook pentru aplicații care sunt destinate să fie încărcate în Facebook (Facebook a făcut în trecut o presiune majoră pentru a încuraja dezvoltatorii să construiască aplicații care trăiau în Facebook; nu sunt pe deplin sigur cât de larg sunt utilizate aceste aplicații astăzi, dar oricum, un site web obișnuit nu folosește niciuna dintre caracteristicile legate de Canvas.) Costul includerii acestora în SDK este destul de marginal: doar 1,5% din dimensiunea totală.

După aceea, avem suport pentru funcțiile vechi. Acest lucru reflectă faptul că un API va acumula mai multe interfețe pentru a gestiona aceleași caracteristici în timp. De exemplu, dezvoltatorii pot scrie cod care apelează FB.getLoginStatus () (abordarea moștenită de a solicita starea actuală de conectare Facebook a utilizatorului) sau Auth.getLoginStatus () (noua abordare încurajată). Modul de a vă deplasa, care trebuie să includă ambele seturi de metode, este eliberarea acestora în versiuni separate ale SDK-ului, dar Facebook a optat să nu facă acest lucru, probabil să simplifice experiența pentru dezvoltatori și să maximizeze numărul de site-uri care utilizează exact același fișier ( pentru a crește probabilitatea ca utilizatorul mediu să îl descarce deja). Această decizie are un cost mic: aproximativ 3,5% din codul SDK este pentru gestionarea caracteristicilor care sunt marcate în mod explicit ca „moștenire” (și este foarte posibil să existe mai multe funcții „moștenite” care pur și simplu nu sunt marcate în mod explicit ca atare ).

Cel mai semnificativ, kitul SDK include o serie de poliumplere și utilități asemănătoare poliampletelor, care reprezintă peste 15% din codul său. Polyfills sunt folosite pentru a furniza caracteristici care se găsesc în browsere mai noi către browsere mai vechi și, uneori, și pentru a furniza caracteristici mai noi care sunt viitoare, dar care nu au fost adăugate încă la niciun browser. Majoritatea polifuncțiilor incluse în SDK-ul Facebook sunt pentru funcții care sunt deja incluse în browserele utilizate de marea majoritate a utilizatorilor de internet. Acestea servesc numai pentru ca SDK să funcționeze pentru < 1% dintre utilizatorii de internet la nivel mondial care utilizează browsere vechi precum Internet Explorer 8, la care multe (dacă nu chiar marea majoritate) dintre site-urile majore au renunțat la suport.

Din restul de ~ 80% din SDK, este puțin mai dificil să dezlegați caracteristicile necesare în acest scop. Acest lucru se datorează faptului că este scris astfel încât, pentru a utiliza o caracteristică simplă precum butonul Apreciază, trebuie să se includă și cod care este utilizat numai pentru comentarii, încorporări video, butoane de conectare și alte caracteristici fără legătură. Facebook ar fi putut alege să distribuie fișiere mult mai mici pentru a include doar caracteristici unice, cum ar fi butoanele Like, dar are ca scop comercial să încurajeze site-urile să utilizeze cât mai multe funcții furnizate de FB.

Contează dimensiunea?

Datorită utilizării pe scară largă a SDK-ului Facebook și a faptului că se schimbă relativ rar, este posibil ca mulți utilizatori să îl fi descărcat deja înainte de a încărca un site. De fapt, aceasta este o mare parte din motivul pentru care Facebook ar distribui un fișier atât de mare, mai degrabă decât cele mai mici pentru caracteristici specifice, cum ar fi butoanele Like. Și pe conexiunile de rețea ale majorității utilizatorilor – cel puțin pe cele din țările dezvoltate – timpul necesar descărcării fișierului este marginal.

Dar, indiferent dacă browserul utilizatorului are deja SDK-ul descărcat, există încă cheltuieli generale implicate în rularea unui bloc mare de Javascript, în special pe dispozitive mobile. Pe noul MacBook Pro pe care scriu acest lucru, SDK-ul Facebook durează aproximativ 50 ms (1/20 de secundă) pentru a rula pe un site precum Buzzfeed. Nu este rău – mai ales atunci când este luat în context cu restul codului JS, inclusiv codul publicitar care durează mult mai mult pentru a fi executat – dar totuși un cost non-banal pentru ceva care este folosit doar pentru a afișa comentarii chiar în partea de jos a pagină.

1611531908 673 De ce butoanele Facebook Like reprezinta 16 din codul mediu
Evaluarea scriptului în Chrome pe un MacBook Pro recent

Pe un smartphone foarte nou (Google Pixel), timpul de execuție JS este dublat, preluând acum 1/10 dintr-o secundă:

1611531908 616 De ce butoanele Facebook Like reprezinta 16 din codul mediu
Evaluarea scriptului pe un smartphone Google Pixel

Privit în context, aceasta este o mică parte din timpul total de executare a codului de pe pagină. Dar se adaugă la cantitatea de timp în care derularea sau interacțiunea cu pagina poate fi o experiență agitată și neplăcută. Și acest lucru ajunge într-un moment important: acest SDK are un cost marginal, dar site-urile web moderne – în special site-urile media – includ adesea coduri similare de la un număr mare de terți (acest exemplu l-am capturat de la Gawker înainte de a fi ucis de un vampir miliardar arată cât de multe astfel de cereri pot exista).

Chiar și lăsând deoparte impactul asupra confidențialității al trimiterii unor informații despre utilizatori către fiecare dintre aceste terțe părți, costul tuturor acestor funcții se adaugă rapid. Fiecare script al unei terțe părți pe care un site îl adaugă are un cost, atât în ​​ceea ce privește performanța, cât și pentru a ajuta la raționalizarea adăugării ulterioare a unei bucăți „relativ inofensive” de cod terță parte. Pe lângă impactul imediat asupra performanței costului aditiv al tuturor acestui cod, acest lucru afectează moralul dezvoltatorului: imaginați-vă că lucrați zile întregi pentru a rade 10% din timpul de încărcare al propriului cod, doar pentru a vedea un bloc gigantic de cod terță parte adăugat că piticii impactul acestui efort minuțios. Și apoi (dacă lucrați pentru un site media), văzând că același tipar se repetă din nou și din nou la fiecare câteva luni.

Ar trebui să o includeți?

Dacă trebuie să utilizați o caracteristică precum Facebook Comments, nu este nevoie să încărcați SDK-ul Facebook. Dar, în funcție de modul în care este structurat site-ul dvs., este posibil să puteți limita impactul performanței SDK-ului încărcându-l doar atunci când este necesar (de exemplu, odată ce utilizatorul a parcurs în jos până la punctul în care comentariile ar trebui să devină vizibile).

Dacă doriți să utilizați butonul Apreciază, opriți și reconsiderați. Facebook nu mai afișează aprecierile unei pagini în mod vizibil (sau, în majoritatea cazurilor, deloc) pe cronologiile utilizatorilor. Este mai bine să utilizați un buton sau link partajat personalizat simpluși, ca avantaj secundar, acest lucru va împiedica Facebook să urmărească toate vizitele pe pagina dvs. și să interfereze cu confidențialitatea utilizatorilor dvs. Site-urile care au eliminat butonul Apreciază nu au reușit să identifice niciun impact negativ al acestui lucru atunci când vine vorba de recomandări de trafic Facebook.

CORECTARE la titlu: Inițial am intitulat acest „De ce 16% din codul de pe site-ul mediu aparține Facebook și ce înseamnă asta”. După cum unii au subliniat pe bună dreptate, acest lucru implică faptul că 16% din Javascript de pe toate site-urile de pe Internet (sau cel puțin din toate site-urile de top) este format din SDK-ul Facebook Javascript. Aceasta nu a fost intenția mea și pot vedea cum a ajuns să fie excesiv de senzaționalist.

Sperăm că noul titlu clarifică faptul că SDK-ul Facebook măsoară 16% din dimensiunea Javascript-ului mediu al site-ului și nu mai implică faptul că acesta reprezintă 16% din totalul Javascript-ului de pe internet. La fel de David Gilbertson notează aici, numărul global real ar fi mult mai mic – 0,96%. El ridică, de asemenea, un punct bun referitor la: stocarea în cache: Facebook Javascript SDK nu este deloc optim în cache, este stocat în cache în modul cel mai ideal timp de până la 20 de minute, după care browserul utilizatorului verifică din nou cu serverele Facebook pentru a verifica dacă acesta este are deja cea mai recentă versiune.