Чому кнопки Facebook Like складають 16% середнього коду веб-сайту

За даними, зібраними BuiltWith.com, 6% із 10 000 найбільш відвідуваних сайтів завантажують вміст із серверів Facebook. Для переважної більшості з них цей вміст, ймовірно, є Javascript SDK від Facebook, величезним блоком коду, який необхідний для відображення таких функцій, як кнопка «Подобається» (як це видно на багатьох медіа-сайтах) та віджети коментарів Facebook (також використовуються на багатьох великих медіа сайтів, серед них Buzzfeed).

Цей код SDK настільки великий, що становить близько 16% від загального розміру всього JavaScript на середній веб-сторінці.

Як значна та широко використовувана бібліотека програмного забезпечення, Facebook SDK є приємним способом проілюструвати деякі відповіді на запитання: чому середній веб-сайт сьогодні такий великий? А скільки насправді має значення розмір?

Чому такий великий?

Facebook SDK є повнофункціональним, що дублює багато інструментів, які середній веб-сайт, ймовірно, вже включає для використання власними розробниками: методи отримання даних з інших сайтів, визначення браузера та пристрою, які використовує користувач, щоб націлюйте на них конкретні функції, а також для відображення елементів інтерфейсу користувача (наприклад, діалогові вікна підтвердження та кнопки). Якщо ми класифікуємо всі частини SDK, розбивка виглядає так:

З набору функцій найбільше виділяються три:

“Canvas” - це система Facebook для додатків, які передбачається завантажувати у Facebook (Facebook зробив великий поштовх у минулому, щоб заохотити розробників створювати програми, які жили у Facebook; я не зовсім впевнений, наскільки широко такі програми використовуються сьогодні, але в будь-якому випадку звичайний веб-сайт не використовує жодної функції, пов’язаної з Canvas.) Вартість включення їх до SDK є досить незначною: лише 1,5% від загального розміру.

Після цього ми маємо підтримку застарілих функцій. Це відображає той факт, що API буде накопичувати кілька інтерфейсів для обробки одних і тих самих функцій з часом. Наприклад, розробники можуть написати код, який викликає або FB.getLoginStatus () (застарілий підхід до запиту поточного статусу користувача для входу в Facebook), або Auth.getLoginStatus ()(новий, заохочуваний підхід). Спосіб обійти необхідність включати обидва набори методів - це випуск їх в окремих версіях SDK, але Facebook вирішив не робити цього, швидше за все, спростивши досвід для розробників та максимізуючи кількість сайтів, використовуючи точно той самий файл ( щоб збільшити ймовірність того, що середній користувач уже завантажив його). Це рішення приймається за невелику ціну: приблизно 3,5% коду SDK призначено для обробки функцій, які явно позначені як "застарілі" (і цілком можливо, що існує набагато більше "застарілих" функцій, які просто явно не позначені як такі ).

Найголовніше, що SDK включає низку поліфілів та подібних до поліфілів утиліт, які становлять понад 15% його коду. Polyfills використовуються для надання функцій, які знаходяться в нових браузерах, для старих браузерів, а іноді і для надання нових функцій, які мають надійти, але ще не були додані до жодного браузера. Більшість поліфілів, включених у Facebook SDK, стосуються функцій, які вже включені до браузерів, що використовуються переважною більшістю користувачів Інтернету. Вони служать лише для того, щоб SDK працював для <1% глобальних користувачів Інтернету, які використовують старі браузери, такі як Internet Explorer 8, який багато (якщо не переважна більшість) основних сайтів відмовились від підтримки.

З решти ~ 80% SDK дещо складніше розплутати, які функції потрібні для якої мети. Це тому, що написано так, що для використання такої простої функції, як кнопка «Подобається», потрібно також включити код, який використовується лише для коментарів, вбудовування відео, кнопок входу та інших не пов’язаних між собою функцій. Facebook міг би поширювати набагато менші файли, включаючи лише окремі функції, такі як кнопки Like, але бізнес-метою є заохочення сайтів використовувати якомога більше функцій, наданих FB.

Чи має значення розмір?

Через широке використання SDK Facebook та той факт, що він змінюється відносно рідко, багато користувачів, швидше за все, вже завантажили його до завантаження сайту. Насправді, це велика частина обгрунтування того, чому Facebook поширював би такий величезний файл, а не менші для конкретних функцій, таких як кнопки подобається. І для більшості мережевих з’єднань користувачів - принаймні у розвинених країнах - час, необхідний для завантаження файлу, є незначним.

Але незалежно від того, чи браузер користувача вже завантажив SDK, у запуску великого блоку Javascript, особливо на мобільних пристроях, все ще є накладні витрати. На відносно новому MacBook Pro, про який я пишу це, SDK Facebook займає близько 50 мс (1/20 секунди) для запуску на такому веб-сайті, як Buzzfeed. Непогано - особливо якщо брати його в контексті з рештою коду JS, включаючи рекламний код, який виконується набагато довше, - але все-таки нетривіальна вартість того, що використовується лише для відображення коментарів у самому низу сторінки.

На абсолютно новому смартфоні (Google Pixel) час виконання JS подвоюється, зараз займаючи 1/10 секунди:

Якщо дивитись у контексті, це невелика частка загального часу виконання коду на сторінці. Але це додає часу, протягом якого прокрутка сторінки або інший взаємодія зі сторінкою може бути неприємним та неприємним досвідом. І це стає важливим моментом: цей конкретний SDK має граничні витрати, але сучасні веб-сайти - особливо медіа-сайти - часто включають подібний код від великої кількості третіх сторін (цей приклад я захопив у Gawker до того, як його вбив вампір-мільярдер показує, скільки таких запитів може бути).

Навіть якщо не враховувати вплив конфіденційності через надсилання певної інформації про користувача кожній із цих третіх сторін, вартість усіх цих функцій швидко зростає. Кожен сторонній сценарій, який додає сайт, має свої витрати як з точки зору продуктивності, так і для раціоналізації додавання наступного “відносно нешкідливого” шматка стороннього коду. Окрім негайного впливу додаткової вартості всього цього коду на ефективність, це впливає на моральний дух розробників: уявіть, що ви працюєте днями, щоб збрити 10% часу завантаження власного коду, лише щоб побачити гігантський блок стороннього коду, який додав, що карлики вплив цих копітких зусиль. А потім (якщо ви працюєте на медіа-сайті), бачачи, як цей самий шаблон повторюється знову і знову кожні кілька місяців.

Чи варто це включати?

Якщо вам потрібно використовувати таку функцію, як коментарі Facebook, немає потреби обійти необхідність завантажувати Facebook SDK. Але залежно від структури вашого сайту, ви можете обмежити вплив продуктивності SDK, завантажуючи його лише тоді, коли це потрібно (наприклад, коли користувач прокрутить сторінку до точки, де коментарі повинні стати видимими).

Якщо ви хочете скористатися кнопкою «Подобається», зупиніться та перегляньте. Facebook більше не відображає лайки сторінки на видному місці (або, в більшості випадків, взагалі) на графіках користувачів. Краще скористатися простою користувацькою кнопкою або посиланням, і як побічна перевага це запобіжить відстеженню Facebook відстеження всіх відвідувань вашої сторінки та втручанню в конфіденційність ваших користувачів. Сайти, які усунули кнопку "Подобається", не змогли виявити жодного негативного впливу цього, коли мова йде про перенаправлення трафіку на Facebook.

ВИПРАВЛЕННЯ до назви: Спочатку я назвав це "Чому 16% коду на середньому сайті належить Facebook, і що це означає". Як деякі слушно зазначають, це означає, що цілих 16% Javascript на всіх веб-сайтах в Інтернеті (або принаймні з усіх найкращих сайтів) складається з Facebook Javascript SDK. Це був не мій намір, і я бачу, як це виявилося надмірно сенсаційним.

Сподіваємось, новий заголовок стає зрозумілішим, що розмір Facebook SDK становить 16% від розміру середнього Javascript веб-сайту, і більше не означає, що він становить 16% від загальної кількості Javascript сайту в Інтернеті. Як зазначає тут Девід Гілбертсон, фактичне глобальне число було б набагато меншим - 0,96%. Він також піднімає хороший момент щодо: кешування: Facebook Javascript SDK взагалі не кешований оптимально, він кешується лише в найбільш ідеальному режимі до 20 хвилин, після чого браузер користувача перевіряє сервер Facebook, щоб перевірити, чи він вже має останню версію.