Dlaczego Like Button zajmuje 16% całego kodu każdej strony?

D

Zgodnie z BuiltWith.com, 6% największych 10.000 stron stron internetowych względem ruchu ładuje treści z serwerów Facebooka. Dla większości z nich, tą treścią niewątpliwie jest Facebook SDK Javascript – ogromny blok kodu, który potrzebny jest do wyświetlania takich funkcjonalności jak Like Button czy widżet komentarzy. Kod tego SDK jest tak duży, że stanowi średnio 16% całej wielkości kodu javascript przeciętnej strony.

Jeden z winowajców tak długiego ładowania się większości stron internetowych

Obszerna i powszechnie używana biblioteka-SDK Facebooka, to świetny sposób na zilustrowanie odpowiedzi na pytania: dlaczego przeciętna strona internetowa jest tak ciężka i długo się ładuje? I jak dużo, to za dużo?

Dlaczego tak dużo?

SDK Facebooka jest przerośnięte, duplikuje wiele narzędzi, które przeciętna witryna zapewne już zawiera dla własnego użytku. Dane analityczne, metody pobierania danych z innych stron, do określania, która przeglądarka i urządzenie użytkownik używa w celu kierowania go na określone funkcje i wyświetlanie mu konkretnego UI(np. pop-upy i reklamy). Jeśli mielibyśmy zgrupować wszystkie elementy pakietu SDK, to podział wyglądałby następująco:

 

Źródło

Wśród tych grup, trzy są całkowicie nieistotne dla większości użytkowników. Wyeliminowanie ich, zmniejszyłoby o 20% całe SDK.

Canvas to facebookowy system dla aplikacji, które mają być ładowane na Facebooku(Facebook kładł kiedyś na to duży nacisk, by zachęcić developerów do budowania aplikacji, które żyłyby na Facebooku. Nie znam żadnej, która byłaby wykorzystywana w pełni, niemniej, dziś, praktycznie żadna strona nie używa funkcji Canvasa). Koszt dołączenia Canvasa do SDK jest marginalny, raptem 1,5% rozmiaru całości.

Idąc dalej, mamy szereg wsparcia dla starszych funkcji. Odzwierciedla to fakt, że API gromadzi wiele interfejsów w celu obsługi tych samych funkcji w różnym czasie. Dla zobrazowania, programiści kiedyś mogli pisać FB.getLoginStatus() – metoda do żądania bieżącego stanu logowania użytkownika na Facebooku), lub obecnie Auth.getLoginStatus(). Jedno SDK, dwie metody, jedna funkcjonalność. Facebook mógłby to wydzielić do różnych wersji SDK ale z jakiegoś powodu tego nie robi. Przypuszczam, że w ten sposób chcą uprościć doświadczenie użytkownika, by nie musiał czekać na pobranie konkretnej wersji SDK. Jeśli istnieje jedna, to pewnie chodząc po internecie już kiedyś ją pobrał. Ta decyzja przynosi niewielkie koszty, około 3,5% kodu SDK służy do obsługi starszych funkcji, które oznaczono jako „legacy”. Całkiem możliwe, że jest ich o wiele więcej, tylko że nie zostały wyraźnie opisane.

Co najważniejsze, SDK zawiera wiele polyfilli i podobnych narzędzi, które stanowią ponad 15% jego kodu. Polyfille są wykorzystywane do obsługi starszych przeglądarek, które tłumaczą im, jak ma się zachować niewspierana natywnie funkcjonalność. Zazwyczaj na okrętkę udaje się uzyskać ten sam efekt. Większość plików wielofunkcyjnych zawartych w SDK przeznaczona jest dla funkcji, które są już zawarte w przeglądarkach używanych przez większość użytkowników internetu. Polyfille tak naprawdę służą dla <1% użytkowników, którzy korzystają ze starszych przeglądarek takich jak Internet Explorer 8 – pamięta ktoś to jeszcze? 😉

Z pozostałych 80% SDK trudniej jest wywnioskować, które funkcje są rzeczywiście potrzebne. Dzieje się tak dlatego, że SDK jest napisane w taki sposób, że użycie prostego elementu, takiego jak np przycisk Like, musi obejmować również kod służący tylko do komentowania, osadzania wideo, przycisków logowania i innych niezwiązanych ze sobą funkcji. Facebook mógłby się zdecydować na dystrybucję znacznie mniejszych plików, zawierających tylko pojedyncze funkcje, takie jak przycisk Like. Tylko, że jest tu pewien haczyk. Facebook w ten sposób chce zachęcić nas, do korzystania z wielu funkcji przez nich dostarczonych.

Czy rozmiar ma znaczenie?

Ze względu na powszechne korzystanie z SDK na Facebooku i faktu, że zmienia się on stosunkowo rzadko, wiele przeglądarek użytkowników pobiera SDK z cache przeglądarki. Prawdopodobnie to jest argumentem, dlaczego Facebook rozprowadza tak ogromny plik, a nie mniejszy tylko z dedykowaną funkcją. W przypadku większości połączeń z siecią – przynajmniej w krajach rozwiniętych – czas pobierania pliku jest marginalny.

Niezależnie jednak od tego, czy przeglądarka użytkownika ma już pobrany SDK, nadal istnieje jego spory udział w uruchamianiu dużej liczby bloków JavaScript, zwłaszcza na urządzeniach przenośnych. Na stosunkowo nowym komputerze MacBook Air, SDK zajmuje około 50ms (1/20 sekundy). Nie jest źle – zwłaszcza gdy jest to związane z resztą kodu JS. Kod związany z reklamą, który trwa dłużej, wciąż jest to koszt nietypowy na coś, co jest używane tylko do wyświetlania komentarzy na samym dole strony.

Uwzględniając kontekst, jest to niewielka część całkowitego czasu wykonania kodu na stronie. Niemniej, trzeba pamiętać, że zwiększa on czas, podczas którego przewijanie lub inne interakcje ze stroną mogą być bardzo nieprzyjemne. I to jest bardzo ważny punkt. Te, konkretne SDK ma niewielki koszt, ale nowoczesne strony – zwłaszcza serwisy kontentowe – często zawierają podobny kod pochodzący od dużej liczby osób trzecich. Najlepszym przykładem niech będzie dla was Gawker i ta, krótka prezentacja interaktywna, która pokazuje jak działał zanim jeszcze został ubity.

Nawet pomijając wpływ prywatności na wysyłanie informacji o użytkowniku do każdej z tych stron trzecich. Koszt tych wszystkich funkcji zwiększa się bardzo szybko. Każdy dodany skrypt do strony to koszt. Zarówno pod względem wydajności jak i racjonalizowania dodania następnego, „stosunkowo nieszkodliwego” fragmentu kodu. Oprócz bezpośredniego kosztu, dochodzi do tego jeszcze koszt moralny. Wyobraź sobie, że jesteś developerem w firmie, która tworzy serwisy kontentowe. Twoim zadaniem jest zmniejszenie o 10% czasu ładowania strony. Zmóżdżasz się dniami wyrywając sobie włosy z głowy. Sukces! Udało się. Kilka dni później przychodzi biznes, który dodaje sobie kolejny „niegroźny kawałek kodu”, cały Twój wysiłek jak piaskiem po oczach. I wiesz co? To się dzieje naprawdę. Średnio co kilka miesięcy.

Czy powinienem to w takim razie umieszczać?

Jeśli potrzebujesz komentarzy Facebooka na stronie, nie musisz tego ładować od razu. Szanuj user experience. Możesz przecież zastosować lazy loading i zacząć ładować Facebook SDK dopiero w momencie, kiedy użytkownik scrollnie stronę w miejsce, gdzie komentarze faktycznie powinny być – zazwyczaj jest to dół artykułu, więc zanim użytkownik tam dojdzie, nie ładuj. Nie ma sensu.

Jeżeli chcesz użyć przycisku „Lubię to” , nie rób tego i się zastanów. Facebook nie pokazuje dokładnego licznika lajków na stronie. Zamiast tego polecam użyć prostego przycisku udostępniania, który działa bez Facebook SDK. Przykład masz u mnie na blogu, na samym dole tego artykułu. Taki przycisk możesz także wygenerować za pomocą tego, prostego narzędzia. Korzyści są trzy: strona działa szybciej, szanujesz prywatność użytkownika i nie sprzedajesz jego danych facebookowi oraz poprawiasz jego doświadczenie związane z Twoją stroną. Serwisy, które wyeliminowały przycisk „Lubię to”, w żaden sposób nie zanotowały spadku ruchu na Facebooku.

O autorze

Filip Nowacki

Swoją przygodę z IT rozpoczął mając 13 lat, kiedy to stworzył swoją pierwszą stronę internetową. Obecnie pracuje jako backend & mobile developer, rozwijając kilka ogólnopolskich produktów o zasięgu blisko 15 milionów użytkowników. Prywatnie maniak optymalizacji, testów A/B, motoryzacji i architektury aplikacji.

Dodaj komentarz

Your sidebar area is currently empty. Hurry up and add some widgets.