Hvorfor Facebook Like-knapper tegner sig for 16% af et gennemsnitligt websteds kode

Ifølge data indsamlet af BuiltWith.com indlæser 6% af de 10.000 mest websteder med høj trafik indhold fra Facebooks servere. For langt størstedelen af ​​dem er dette indhold sandsynligvis Facebooks Javascript SDK, en enorm blok kode, der er nødvendig for at få vist sådanne funktioner som Like-knappen (som set på mange mediesider) og Facebook-kommentarwidgets (også brugt på mange store medier websteder, Buzzfeed blandt dem).

Denne SDK-kode er så stor, at den repræsenterer ca. 16% af den samlede størrelse af al JavaScript på den gennemsnitlige webside.

Som et stort og meget anvendt softwarebibliotek er Facebook SDK en god måde at illustrere nogle af svarene på spørgsmålene: Hvorfor er det gennemsnitlige websted i dag så stort? Og hvor meget betyder størrelse faktisk noget?

Hvorfor så stor?

Facebook SDK er meget fuldt udstyret og duplikerer mange af de værktøjer, som det gennemsnitlige websted sandsynligvis allerede inkluderer til sine egne udviklers brug: metoder til at hente data fra andre websteder, til at bestemme hvilken browser og enhed brugeren bruger for at målrette specifikke funktioner til dem og til visning af UI-elementer (som bekræftelsesdialogbokse og knapper). Hvis vi kategoriserer alle brikkerne i SDK, ser fordelingen sådan ud:

Af sæt af funktioner skiller tre sig mest ud:

"Canvas" er Facebooks system til apps, der er beregnet til at blive indlæst i Facebook (Facebook gjorde et stort skub i fortiden for at tilskynde udviklere til at opbygge apps, der levede inden for Facebook. Jeg er ikke helt sikker på, hvor bredt sådanne apps bruges i dag, men uanset hvad, bruger et almindeligt websted ikke nogen af ​​Canvas-relaterede funktioner.) Omkostningerne ved at inkludere dem i SDK er ret marginale: kun 1,5% af den samlede størrelse.

Derefter har vi understøttelse af ældre funktioner. Dette afspejler det faktum, at en API vil akkumulere flere grænseflader til håndtering af de samme funktioner over tid. For eksempel kan udviklere skrive kode, der kalder enten FB.getLoginStatus () (den ældre tilgang til at anmode om brugerens aktuelle Facebook-loginstatus) eller Auth.getLoginStatus ()(den nye, opmuntrede tilgang). Måden at omgå behovet for at inkludere begge sæt metoder frigiver dem i separate versioner af SDK, men Facebook valgte ikke at gøre dette, hvilket sandsynligvis vil forenkle oplevelsen for udviklere og maksimere antallet af sider ved hjælp af nøjagtig den samme fil ( for at øge sandsynligheden for, at den gennemsnitlige bruger allerede har downloadet den). Denne beslutning koster en lille pris: ca. 3,5% af SDK-koden er til håndtering af funktioner, der udtrykkeligt er markeret som "arv" (og det er meget muligt, at der er mange flere "arv" -funktioner, der bare ikke udtrykkeligt er markeret som sådan) ).

Mest markant inkluderer SDK et antal polyfills og polyfill-lignende hjælpeprogrammer, der udgør over 15% af dets kode. Polyfills bruges til at levere funktioner, der findes i nyere browsere til ældre browsere, og nogle gange også til at levere nyere funktioner, der er kommende, men som endnu ikke er føjet til nogen browsere. De fleste af polyfills inkluderet i Facebook SDK er til funktioner, der allerede er inkluderet i browsere, der bruges af langt de fleste internetbrugere. De tjener kun til at få SDK til at fungere for <1% af de globale internetbrugere, der bruger gamle browsere som Internet Explorer 8, som mange (hvis ikke langt størstedelen af) større websteder har givet op med at støtte.

Af de resterende ~ 80% af SDK er det lidt sværere at fjerne hvilke funktioner der er nødvendige til hvilket formål. Dette skyldes, at det er skrevet således, at man for at bruge en simpel funktion som Like-knappen også skal indeholde kode, der kun bruges til kommentarer, videoindlejringer, login-knapper og andre ikke-relaterede funktioner. Facebook kunne have valgt at distribuere meget mindre filer for kun at inkludere enkeltfunktioner som Like-knapper, men har et forretningsmål om at tilskynde websteder til at bruge så mange FB-leverede funktioner som muligt.

Betyder størrelse noget?

På grund af den udbredte brug af Facebooks SDK og det faktum, at det ændres relativt sjældent, er det sandsynligt, at mange brugere allerede har downloadet det, før de indlæser et websted. Faktisk er dette en stor del af begrundelsen for, hvorfor Facebook ville distribuere en så stor fil, snarere end mindre til specifikke funktioner såsom Like-knapper. Og på de fleste brugeres netværksforbindelser - i det mindste i udviklede lande - er tiden, det tager at downloade filen, marginal.

Men uanset om brugerens browser allerede har downloadet SDK, er der stadig overhead involveret i at køre en stor blok Javascript, især på mobile enheder. På den relativt nye MacBook Pro, jeg skriver dette på, tager Facebooks SDK omkring 50 ms (1/20 sekund) for at køre på et sted som Buzzfeed. Ikke dårligt - især når det tages i sammenhæng med resten af ​​JS-koden, inklusive annoncerelateret kode, der tager meget længere tid at udføre - men stadig en ikke-triviel pris for noget, der kun bruges til at vise kommentarer i bunden af side.

På en meget ny smartphone (Google Pixel) fordobles JS-udførelsestiden nu og tager nu over 1/10 sekund:

Når man ser på det i sammenhæng, er dette en lille brøkdel af den samlede kodeudførelsestid på siden. Men det føjer til den tid, hvor rulle eller på anden måde interagere med siden kan være en hakket og ubehagelig oplevelse. Og dette kommer på et vigtigt punkt: denne særlige SDK har marginale omkostninger, men moderne websteder - især mediesider - indeholder ofte lignende kode fra et stort antal tredjeparter (dette eksempel fangede jeg fra Gawker, før den blev dræbt af en milliardærvampyr viser, hvor mange sådanne anmodninger der kan være).

Selv udeladelse af privatlivets indvirkning ved at sende nogle brugeroplysninger til hver af disse tredjeparter tilføjes omkostningerne ved alle disse funktioner hurtigt. Hvert tredjeparts script, som et websted tilføjer, koster en pris, både med hensyn til ydeevne og med til at rationalisere tilføjelsen af ​​det næste "relativt harmløse" stykke tredjepartskode senere. Udover den øjeblikkelige ydeevneeffekt af additivomkostningerne for al denne kode, påvirker dette udviklermoral: Forestil dig at arbejde i dage for at barbere 10% af din egen kodes indlæsningstid, kun for at se en kæmpe blok med tredjepartskode tilføjet, der dværger virkningen af ​​den omhyggelige indsats. Og så (hvis du arbejder for et medieside), hvis du ser det samme mønster gentage sig igen og igen hvert par måneder.

Skal du medtage det?

Hvis du har brug for en funktion som Facebook-kommentarer, er der ikke behov for at indlæse Facebook SDK. Men afhængigt af hvordan dit websted er struktureret, kan du muligvis begrænse SDK's præstationspåvirkning ved kun at indlæse det, når det er nødvendigt (f.eks. Når brugeren har rullet ned til det punkt, hvor kommentarer skal blive synlige).

Hvis du vil bruge Like-knappen, skal du stoppe og genoverveje. Facebook viser ikke længere Synes godt om en side (eller i de fleste tilfælde overhovedet) på brugerens tidslinjer. Det er bedre at bruge en simpel brugerdefineret Share-knap eller et link, og som en sidefordel forhindrer Facebook det i at spore alle besøg på din side og forstyrre dine brugeres privatliv. Websteder, der har fjernet Like-knappen, har ikke identificeret nogen negativ indvirkning på at gøre det, når det kommer til Facebook-trafikhenvisninger.

KORREKTION til titel: Oprindeligt titlerede jeg dette “Hvorfor 16% af koden på det gennemsnitlige websted tilhører Facebook, og hvad det betyder”. Som nogle med rette påpegede, indebærer dette, at hele 16% af Javascript på alle websteder på Internettet (eller i det mindste alle topsider) består af Facebook Javascript SDK. Dette var ikke min hensigt, og jeg kan se, hvordan det kom ud for alt for sensationelt.

Forhåbentlig gør den nye titel klarere, at Facebook SDK måler 16% af størrelsen på det gennemsnitlige websteds Javascript og ikke længere betyder, at det repræsenterer 16% af det samlede websteds Javascript over internettet. Som David Gilbertson bemærker her, ville det faktiske globale antal være meget mindre - 0,96%. Han rejser også et godt punkt re: caching: Facebook Javascript SDK er slet ikke cachelagret optimalt, det caches kun på den mest ideelle måde i op til 20 minutter, hvorefter brugerens browser tjekker tilbage med Facebooks servere for at kontrollere, at det har allerede den nyeste version.